In a hurry to decide if something is reusable?

August 15, 2010

I have heard some variation of the following line from developers, technical leads, and architects – “we want to make things more reusable, but we don’t have the time.”

There is always a deadline (or many deadlines) to meet and technical debt to accumulate. Since we are always in a hurry, it helps to be aware of what should be reusable – even if we won’t get to it in this iteration . So here are some ideas that can help you decide whether or not a capability should be developed for reuse:

  • is the capability unique to your enterprise? i.e. it captures logic and/or process variations that provide competitive differentiation.
  • is the capability making something incredibly hard/defect prone simpler and/or easier?
  • is there a desire for customers to have a capability across business channels? i.e. from the web, from a mobile device etc.
  • is it specific to your domain and potentially relevant to multiple applications in the domain? this may or may not be obvious – if it isn’t, delay commitment.
  • is the capability only available in a particular technical platform but is solving  an often needed problem?
  • is it automating boiler plate code generation or preventing defects?
  • is there an in-house/external alternative that achieves your functional requirements? if so, seriously consider stopping investment in the asset.

This is a starter list – the idea that we keep coming back to is this – treat a reusable asset like a real investment. Every iteration and release is an opportunity to review and update the investment. When you make a decision, continuously refactor to make the capabilities less app specific and reusable.


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 del.icio.us: Digg it : post to facebook: Stumble It! : :


Refactoring To Reuse #1

August 9, 2009

#1 Decouple connectivity from business logic

Often times you have a class that has a mixture of logic that is core or central to it and extraneous ones. A classic case is when you have a class that does calculations and also connects to a file or database. This isn’t bad per se because it probably works. But it inhibits reuse of both the calculation logic and the connectivity logic. One way to refactor the original class is to split it into 3 classes: a controller class, a connectivity class, and a calculation class. The controller is lightweight and co-ordinates the work across the other two classes. The connectivity class encapsulates file or database connectivity, and the calculation class executes a specific algorithm.

Here is an example – say you have a class named DiscountCalculator that accesses customer data from a database, and finds the ones that qualify for a particular promotional discount. You introduce a class named DBUtility that gets/closes a database connection, executes queries etc. I would advise against building such a class since good ones already exist. For example, if you use java, a better idea would be use Spring’s JDBCSupport and JDBCTemplate classes to achieve this. Now you can create a simple object (e.g. a plain old java object – POJO) that is returned from the database queries. The DiscountCalculator class can encapsulate the business logic within it or if you need to support multiple types of discountss you can consider introducing the Strategy design pattern. Whatever you decide, you can remove the database related logic from DiscountCalculator and keep it flexible for new types of discount calculations. In the same vein, the POJO is reusable as well for additional classes.

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

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


%d bloggers like this: