Encapsulate Variations Using Patterns

Predicting and designing for systematic reuse is hard – in trying to design for future requirements, team often bake in accidental complexity. One effective way to avoid that trap is to separate your concerns via well designed interfaces. It is important to point out that although separating concerns is essential, which ones to prioritize and plan for is heavily dependent on your problem domain. Additionally, it is not pragmatic to provide for variability across all points in your design.

Design patterns are common solutions to design problems based on a given context. When used appropriately, they help address changing requirements. There are several books on design patterns and I don’t want to repeat that information here. Instead, we will look at design patterns in the context of building and integrating reusable assets. Here is a starter list:

Strategy – Polymorphically bind concrete implementations to execute a flavor of logic. This is useful when encapsulating product variations. If you need to support multiple flavors of a feature at runtime it is applicable. For instance, searching a product catalog feature could use exact text matching for product A while using fuzzy matching for product B. This could also be used to support multiple flavors within the same product and choosing a concrete implementation based on criteria. For this feature, it could be type of user or the nature of input parameter or volume of potential results.

Adapter – Used for translating one interface from another in order to integrate incompatible interfaces. This is useful in a couple of situations. Introduce an adapter when reusing a legacy asset. It is also useful when there are multiple versions of a reusable asset that you need to support in production. A single implementation can be reused to support the new version and the old version. The old version of the asset can be wrapped by an adapter for backward compatibility.

Template method – Used to define a generic set of steps to execute with placeholders for concrete steps that need customization. I tend to use this pattern for reusing business process flows across varying product types. It can also be used when implementing a standard request processing flow for both library components and web services. This is a common pattern when introducing horizontal concerns (such as security, logging, auditing etc.) as part of the processing algorithm.

Abstract factory – Used to build a family of products that need to be created as a cohesive unit. You don’t want your calling code to know the nuances and complexity of constructing domain objects. This pattern is very useful when creating domain objects that require business rules and you want the complex creation in a single place in your codebase. I typically use this pattern with supporting bundling of product features. If you want to reuse a set of product features across bundles you will have several objects that all need to be carefully chosen at runtime for consistent behavior.

Decorator – Used with a core capability that you want to augment at runtime. Decorators are pluggable components that can be attached or detach ed at runtime. The upside is that the decorators and the component being decorated are both reusable but you want to watch out for object proliferation. I use this for pattern when the same data needs to be formatted or rendered differently or when you have a generic set of data fields that needs to be filtered based on some criteria.

Command – Used to encapsulate information that is used to call a piece of code repeatedly. Can also be used to support undo/redo functionality. The commands can be reusable across different product interfaces and act as entry points to invoke backend logic. For instance, I have used this pattern to support invocation of services from a self-service portal and interactive voice response channels.