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

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

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
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.



/ 111