News

The Road to Nirvana—Component Re-use

• By Gary Barnett
• March 19, 2001

Component based development is touted as many things.

We are told that it will lead to better software; that the software we create will be flexible and adaptable and that we'll soon be able to 'compose' applications from a menu of pre-built components in half the time.

Indeed given all of these obvious benefits, it seems mystifying when component based development turns out to be fabulously difficult, results in poor software that is almost impossible to change and any thoughts of re-use dissolve into frustration at never seeming to be able to get your hands on that great component you know exists but just can't find.

The truth is that component based development is hard—and the benefits of component use and re-use only come after you've stumped the price for a ticket to Component Nirvana.

Begin by looking at those areas where component re-use really does work, start with all those 'widgets' on the menu bar of your favorite development tool. What is it about these 'text boxes' and 'option buttons' that makes you use them rather than writing your own?

Firstly, they are easy to find; they're there—right in front of you. Secondly, it's relatively easy to figure out what they do; you don't need to spend hours figuring out what impact changing the 'FontSize' attribute is going to have on the contents of your text box. Thirdly, and rather obviously, every application needs a text box or two.

These three attributes—accessibility, simplicity and utility are the cornerstones of re-use in component-based development. And no matter how well crafted your component, if these qualities aren't present, your component is likely to remain a very well kept secret.

Accessibility—is the ability to find the component

Simplicity—is the ability to understand what it does

Utility—is a measure of how readily 're-usable' the component is—if it is too generic it isn't particularly valuable, but if it's too specific you might have to wait a decade for another identical requirement to emerge.

The first of these attributes is actually external to the component, as it relates to providing a component yellow pages—a directory that describes the components it can 'see', and what they can do in a manner that makes it easy to discover a component that meets a given requirement.

The final two attributes are entirely down to you—It is up to you to make sure that it doesn't take a genius (or the source code) to figure out what your component does. The whole point of a component is that its purpose should be unambiguous, and you shouldn't have to pry it open in order to figure out how to use it.

Utility is the most difficult quality to get right—In component based development 'Size Does Matter', but there is no hard and fast rule about which size is optimal. Aside from the basic rule 'make it cohesive' and 'loosely coupled' the process of defining a component that is big enough to be valuable, and small enough to be applicable frequently comes down to 'Component Zen', and may the force be with you.