Patterns, ABD and Styles of Reuse
PBE is closely related to Asset-Based Development (ABD) – simply put, patterns are a specific kind of reusable asset. However we need to be aware of the different approaches and styles of asset reuse. Understanding the styles of reuse is an important consideration in building a successful reusable asset. Select the wrong style for your asset and you jeopardize the success of your initiative.
As discussed in the IBM Redbook “Strategic Reuse with Asset-Based Development”, there are 4 styles of reuse:
- “Black Box: An asset that is not altered by the Asset Consumer
- Gray Box: An asset that is modified using parameters
- White Box: An asset whose internals are modified by the Asset Consumer
- Glass Box: An asset that exposes internals for evaluation and browsing purposes”
With Black Box reuse we only look at the integration points and external API provided by the reusable asset to integrate it with our other components. We don’t need to modify or fully understand the internals of the asset to integrate it into our application. “White box” reuse it is quite the opposite, we need to modify/adapt and/or understand the internals of the reusable asset to be able to reuse it and integrate it with our application. Gray Box is interesting in that it provides us with a combination of Black and White Box (hence the name). For the most part, the asset is not modified – yet it provides use with the ability to adjust the use of the asset via parameters. In this way, the asset is designed to be customized for the specifics of the situation. The last category, Glass Box, is more of a derivative of Black Box in the sense you cannot modify it, you can only look inside for education purpose. Being able to look inside helps you to understand the asset with the goal of improving the reuse experience.
Let’s take a look at some examples to make these concepts more concrete. First let’s start with Components. White Box or Black Box reusable assets? Components can be both, but usually they are more on the Black Box side of the spectrum. If we plan to integrate a logging component or even a billing component we don’t need to understand how they have been coded or how they work internally (even if sometimes it is better to have this understanding) nor do we need to modify the component’s inner elements. All we need is an understanding of the API to be able to know how to use it and how to integrate it with our other components.
The dividing line between White Box and Glass Box reusable assets is sometimes fuzzy. For example, the majority of open source components are provided with their source code. However, although you can modify the code (that will make it a White Box reusable asset) the code is most often used to help understand how the component works – making it a Glass Box reusable asset.
Next, let’s take a look at frameworks. What type of reuse does a framework provide? White box? Black Box? Frameworks are more on the White Box side. Some parts of the framework are of the Black Box kind, but overall the framework needs to be instantiated, fine-tuned to our specific needs to be of any use to us. And you definitely need to know and understand the internals of the framework to take best advantage of the features it provides.
And where do patterns stand? The answer to the questions is not as simple as it may appear. The part that adds complexity to the discussion is the recognition that patterns can be either a specification or an implementation. So perhaps it is better to restate the question – where do pattern specifcations stand? And, where do pattern implementations stand?
Pattern specifications are an example of the White Box style of reuse. A pattern specification provides a blueprint to help you apply the design proposed by the pattern to your own context. You need to understand the pattern internals and even fine tune them to be able to correctly apply the pattern to your context.
In the case of a pattern implementation, hopefully you’ve guessed that they are Gray Box reuse. As mentioned earlier, Gray Box can be thought of as a combination of Black Box and White Box reuse – providing us with the best of both approaches. We get the “drop-in and use” line of thinking associated with Black Box, but we also get the ability to make the asset fit the specifics of our situation. You don’t necessarily need to fully understand how the pattern implementation works and you definitively don’t want to modify its internal. The parameters defined in the input model allow you to adapt the pattern to your needs. We have a balance between adherence to the best practice\intended solution against customizability.
And as we wrap things up, this idea of a balance between adherence to best practice vs. customizability is key. When deciding about which style of reuse to use in a situation, we need to consider this balance. Our decision will impact the cost of developing the asset, the effort needed to use the asset and also the overall success of the reuse. Providing our users with a Black Box style asset when they need a solutions that require a high degree of customization is a path to failure. Providing an asset that uses a White Box approach to a community that lacks the expertise in the domain is another example of a situation that is unlikely to end well.
As we create reusable assets we need to understand the content that we are packaging, the user community, their skills and how the asset will be used. With this information in hand, we can select a reuse style and take another step forward in a successful reuse program.