Design Patterns Java™ Workbook - Part2

Yesterday i started reading Design Patterns Java™ Workbook By Steven John Metsker.

Nice book written by Steven John Metsker.

I wanted to share few quotations found the book from the next 2 chapters (3-4).

1) Class and Object Adapters

When you need to apply ADAPTER, you may not be able to subclass the class whose methods you need to adapt. In some cases, you may need to create an adapter that adapts information from more than one object. You may also find that the interface you need to adapt to is not a Java interface but rather an abstract class that you must subclass. In such cases, you need to create an object adapter—an adapter that uses delegation rather than subclassing.

2) Recognizing Adapter

Adapters are healthier when a Java interface narrows the responsibility that the adapter class bears to the client. The JTable class, for example, specifies the exact interface it needs with the TableModel interface. By comparison, the MessageAdapter class has no contract with the application it plugs into that the application won't expand its use of a PrintStream object's behavior. In fact, although the word adapter appears in the name of the MessageAdapter class, you might question whether MessageAdapter is an instance of the ADAPTER pattern.

3) A class adapter produces a single object that is the adapter. This avoids forwarding calls from an adapter object to instance(s) of the class that it adapts. A class adapter object simply translates method names, forwarding calls to itself.

The relative advantages of class and object adapters are small in comparison to the advantage of having a Java interface that defines the client's needs. In the absence of such an interface,your adapter object poses as an instance of the client's required type, with no contract defining the client's needs. In a situation like this you should, if possible, ask the client developers to build in an interface to which you can adapt.

4) A great advantage of object-oriented (OO) programming is that it helps keep applications from becoming monolithic programs with hopelessly interwoven pieces. An "application" in an OO system is a minimal class that knits together the behaviors from reusable toolkits of other classes. A toolkit or subsystem developer often creates packages of well-designed classes without providing any applications that tie the classes together. The packages in the JDK are generally like this; they are toolkits from which you can weave an endless variety of domain-specific applications.

The reusability of toolkits comes with a problem: The diverse applicability of classes in an OO subsystem may offer an oppressive variety of options. A developer who wants to use the toolkit may not know where to begin. This is especially a problem when a developer wants to apply a normal, no-frills, vanilla usage of the classes in a package. The FACADE pattern addresses this need. A facade is a class with a level of functionality that lies between a toolkit and a complete application, offering a vanilla usage of the classes in a package or a subsystem. The intent of the FACADE pattern is to provide an interface that makes a subsystem easy to use.

5) Ordinarily, you should refactor the classes in a subsystem until each class has a well-defined purpose. This will make your code easier to maintain, but it can also make it difficult for a user of your subsystem to know where to begin. To help the developer who is using your code, you can supply demos or facades that go with your subsystem. A demo is usually a stand-alone, nonreusable application that shows one way to apply a subsystem. A facade is usually a configurable, reusable class with a higher-level interface that makes the subsystem easier to use.


Glossary

CLASS DIAGRAM

A drawing that shows definitions of and relationships among classes and interfaces.

COMPOSITE

A group of objects in which some objects may contain others, so that some objects represent groups and others represent individual items, or leaves.

CONCRETE CLASS

A class that can be instantiated; unlike an abstract class.

CONSTANT

A field that is static and thus widely accessible and final, with a fixed value.

CYCLE

A path in which a node, or object, appears twice.

DEEP COPY

A complete copy of an object in which the new object's attributes are complete copies of the original object's attributes.

DESIGN PATTERN

A pattern—a way to pursue an intent—that operates at about a class level.