Monday, March 25, 2013

Design Pattern Reference

Here are some of the best articles on design patterns on the internet. Once you review the examples and discussions, its best to do some comparisons next.

Facade.
Flyweight
Adapter
Chain of Responsibility
Singleton
Observer
Composite
Command
Strategy
Proxy.
Decorator
Broker
Builder
Dependency Injection
State
Bridge
Interface
Prototype

Interesting comparisons to do:

Facade, Adapter: Facade works on an entire subsystem (multiple classes) to make usability simpler and Adapter generally does not target simplicity as much as mapping one set of calls to another.

Proxy, Decorator: Proxy pattern binds the class being proxied with the proxy class at compile time. Decorator does this at runtime. Decorator typically intends to add or remove functionality while Proxy typically exposes full functionality. In most cases, proxy always uses lazy instantiation for the class which is being proxied and decorator will typically instantiate the containing class in the constructor.

Chain of Responsibility, Decorator: Think linked lists vs wrappers. Linked lists can kill the flow at any time w/o visiting all elements. In addition wrappers implement both pre and post processors.

Decorator, Inheritance: If each operation implemented by a decorator is instead implemented as a subclass, you will have to create multiple combination subclasses for each combination which can be produced using a decorator sequence. Think m+n vs m 'times' n for the total number of classes.

Strategy, Dependency Injection: DI is a refinement of Strategy pattern.

Strategy, Command: Strategy pattern can be used when implementations change for a task amongst different classes (which implement the same interface). Command on the other hand is much simpler. It makes sense when the caller does not want to get involved in the details of how a handler implements a certain command.

About Tukeys

Tukeys provides consulting and software services to companies in healthcare and communications that are dealing with technical or scaling challenges. Please reach out to me on LinkedIn.

An interesting quote from John Tukey, who was an American mathematician (1915-2000) -

An approximate answer to the right problem is worth a good deal more than an exact answer to an approximate problem.

Today maths and statistics form the basis of how software is developed and used around us.

About Me

Medhavi: I have over 20 years of experience in healthcare, communications and AI.
I have a passion for defining innovative applications, creating product/technology strategy and solving challenging problems. My product mindset is helpful to any company to find patterns, reduce costs, and gain efficiencies.

I was the VP of Engineering at Vibrent Health, where I led the web, mobile, API, and data products that supported one of the largest NIH programs - All of Us Research Program. Our system enrolled almost a million users and collected data from EHRs, surveys, and wearables. Before that, I worked at hCentive, a pioneer in health exchanges.

As the CTO of 3CLogic, I helped create the first PC and web-only contact center solution that implemented PBX and CRM functionality as an affordable SaaS solution. As the Chief Architect of NexTone, I was instrumental in the development of SIP and SIP based products. SIP and associated protocols form the basis of modern WebRTC APIs.

If you are a growth company or invest in growing companies that are facing technical or scaling challenges, I can be a tremendous help. Contact me on LinkedIn.