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.
About the Author
Gary Barnett is IT research director at Ovum Ltd., a United Kingdom-based consulting firm.