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