There isn’t one right way to build reusable software assets. Your business goals, technical environment, iteration and release plans all contribute to both the timing and nature of design decisions. Refactoring existing code to meet business goals is also context driven. Consider:
- What product features typically go together?
- Do certain features vary more than others across products?
- Is it possible to vary a product feature at runtime or design-time?
All these questions guide design. For instance, if the goal is to support variability at runtime you could support adding new parameters and changing existing ones without code changes or application restarts. As you work on design, keep your domain relevant variations at the back of mind!
Take an example of a widget shop that needs to market its widgets. The user story is to produce different marketing labels based on widget type. There could be several variations to support – frequency of changes to label information, number of words, language, data formatting, mixture of static and dynamic messages that make up a label etc.
Depending on the complexity of your domain, the features could vary simultaneously or in isolation. Consider some of these variations and their impact on design.
#1 Label contents are only static content – you could use a single LabelGenerator using a file configuration.
#2 Label contents are a mixture of static and dynamic content – LabelGenerator now needs two sub-components – a StaticContentGenerator and a DynamicContentGenerator.
#3 Label contents are a mixture of static and dynamic content. Static content is multi-lingual. – In addition to the content generators you need an internationalization component that can support multiple languages
#4 Label contents are a mixture of static and dynamic content. Static content is multi-lingual. Date and currency formatting varies based on country – All components of #3 plus a DateFormatter and CurrencyFormatter based on locale.
Next time you start a project, understand more about the drivers for change in your problem domain. Your domain and the associated context should drive reuse. The more you understand the drivers the easier it is to decide what and how your software assets need to be reusable.