Systematic Reuse Needs Extensibility

February 3, 2013

Accidental complexity is a real risk with trying to pursue systematic reuse . In trying to get reuse, you don’t want developers to jump through layers of indirection and complexity before they can write any useful code. Accounting for extensibility is a pragmatic approach when striving to design for systematic reuse.

Extensibility needs to be supported at various points in the design – it could be in user interface, integration, data contracts/definitions, system flows, services, and many other points. There are a plethora of choices and the question then becomes – how does one know what needs to be extensible? The answer lies in “finding what varies and encapsulating it”[1].

If a reusable component provides an extensibility hook – the consumer of the component can extend / replace default behaviour. Extensibility can be provided in a variety of ways – there ins’t a magic bullet here and each tactic needs to be considered in context. Here are various examples:

Spring Framework provides application context loader listeners that a developer can use to plugin custom logic. The listener doesn’t allow customization of how Spring constructs the beans or injects dependencies. However, it does provide a convenient mechanism for the developer to provide logic after container startup and before shutdown – place logic specific to a legacy/proprietary API that doesn’t support dependency injection. Alternatively, if there is a specific way to guarantee cleaning up resources prior to destroying context – that logic can be placed here as well.

Another extensibility strategy is from SLF4J – it is a logging facade and provides logging API methods that can be wired with concrete providers such as Log4J. Here, the idea is to free up individual classes from coupling with a specific provider. It provides much more points of extensibility than the above example.

Finally, the nature and number of extension points needs to be carefully weighed in the context of real applications. Not enough extension points hurts reusability. Similarly, too many increases learning curve, complexity, and possibly investment prior to making it usable in an application.

1. Alan Shalloway, James Trott, Design patterns explained: a new perspective on object-oriented design

What I’m Reading

May 26, 2012

Reading a couple of patterns books:

Service Design Patterns

Patterns for Fault Tolerant Software

Agile Software Reuse Design Practices Primer

March 5, 2011

Pursuing systematic reuse the agile way? This primer will cover a variety of design practices to help your development teams. It covers:

  • Building reusable assets from existing applications
  • Designing new reusable components and services
  • Design patterns, product line practices, and more!

Using Design Patterns To Build Reusable Assets

October 2, 2009

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 also 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 detached 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.

There are additional patterns that help you organize your application code better (such as Model, View, Controller (MVC) and avoid point to point coupling between applications (publish/subscribe) fostering reuse.

what patterns have you used?

Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! : :

Software Reuse Podcast New Episode

May 18, 2009

Want to listen using iTunes?

Using iTunes?

podcastJust posted the fourth episode of the software reuse podcast series covering the template method design pattern.

enjoy and would be great to hear your feedback!

Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! : :

Podcast Series Episode 3…

May 3, 2009

Want to listen using iTunes?

Using iTunes?

podcastThis week’s episode is up and talks about design patterns and specifically using the adapter pattern for reusing legacy components and services.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! :

%d bloggers like this: