Better Faster Lighter Java [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Better Faster Lighter Java [Electronic resources] - نسخه متنی

Justin Gehtland; Bruce A. Tate

نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
تنظیمات قلم


اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
لیست موضوعات
افزودن یادداشت
افزودن یادداشت جدید

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.

Table 6-2. Extension strategies






No extension

Low startup costSimplicity

Poor flexibilityExpensive extension



Few lines of codeShared behavior

Reduced flexibilityCode time only Can complicate designs



High flexibility

More lines of codeCode time only



Best flexibilityPost-deploy timeAllows customization

Expensive to code


Standards + configuration

Allows replacementPost-deploy time

Limits choice

Table 6-2 shows how your customer affects
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

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.

/ 111