6.4 Who Is the Customer?
Usually, when a Java developer
talks about extension,
he's referring to ways that programmers can extend
his application. That's only part of the total
equation, though. Building an extensible API only lets your customer
adapt your solution before build time. For some applications, the
most useful extension happens after deployment! Your extension
strategies for different customers will be different (Table 6-2). Understanding your options will allow you to
accept an acceptable risk for your investment.
Customer | Strategy | Pros | Cons |
---|---|---|---|
All | No extension | Low startup costSimplicity | Poor flexibilityExpensive extension |
Developer | Subclassing | Few lines of codeShared behavior | Reduced flexibilityCode time only Can complicate designs |
Developer | Interfaces | High flexibility | More lines of codeCode time only |
Admin | Plug-in | Best flexibilityPost-deploy timeAllows customization | Expensive to code |
Admin | Standards + configuration | Allows replacementPost-deploy time | Limits choice |
extension. Although I haven't said it in this
chapter yet, opting for simplicity over extension is perfectly valid.
If you're coding a one-off solution that will be
quickly replaced or has no possibility of changing in the future,
extension is not a sound investment. Scaffolding code and quick
interim solutions are but two examples of this type of application.You should also understand your end customer. If
you're building a custom application that has a very
short, ongoing maintenance cycle, sophisticated configuration options
have limited value, especially for services that are not likely to
changesuch as your RDBMS or your two million-class tax rules
engine.If your customer is not under your immediate control, or your cycle
time is long enough to make coding changes painful, it pays to invest
in extension. If you place hooks in the right places and think the
configuration strategy through, your customers will surprise you. If
you need evidence, look at projects that customers have extended
well. James Duncan Davidson created the core of the Ant build tool on
a five-hour flight to Europe. The core extension principles still
exist, and now you see many thousands of Ant tasks. Consider your
customers, your application, and the problem domain. Circumstances
directly affect your decisions:The less you control your customer's requirements,
the more you must consider extension.Commercial products usually need better configuration options than
private IT projects.The longer the expected lifespan of a product, the more important
post-deployment flexibility is.The longer your lifecycle, (specifically, the longer it takes you to
respond to requirements), the more you've got to
invest in post-deployment extension options.