Design Patterns Java™ Workbook - Part16

Couple of Days back 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 (Appendix B).

1) An abstract class with no nonabstract methods is similar to an interface in terms of its utility.However, note the following.

• A class can implement any number of interfaces but can subclass at most one abstract class.

• An abstract class can have nonabstract methods, which are usually instances of the TEMPLATE METHOD pattern. All the methods of an interface are abstract, whether or not this declaration is explicit.

• An abstract class can declare instance variables that its subclasses inherit. An interface cannot declare instance variables, although it can establish static final fields.

• An abstract class can define constructors; an interface cannot.

• An abstract class's visibility can be public, protected, private, or none (package); an interface's visibility must be public or none (package).

• An abstract class can have methods whose visibility is protected, private, or none (package); every method in an interface must be public.

• An abstract class inherits from Object, including such methods as clone() and equals().

2) Interface methods are always abstract, whether or not they declare it.

Interface methods are also always public, whether or not they declare it.

An interface with no methods is a marker interface. Sometimes, a method high in a class hierarchy, such as Object.clone(), is not appropriate for every subclass. You can create a marker interface that requires subclasses to opt in or to opt out of participation in such a method. The clone() method on Object requires subclasses to opt in, declaring that they implement the Cloneable marker interface.

An interface cannot declare instance fields, although it can create constants by declaring fields that are static and final.

An interface does not define a contract between the caller and the implementing class when the interface is used to register for notification. In this case, the implementing class may need to take an action in response to a method call, but it is generally not performing a service for
the caller.

3) A class that implements WindowListener must implement all the methods the interface declares, even if the class will ignore these methods when called. The WindowAdapter class ignores all the methods in Window-Listener.

4) The FACADE pattern may help to refactor a large application.

• The BRIDGE pattern moves abstract operations to an interface.

• The OBSERVER pattern may appear as you refactor code to support an MVC architecture.

• The FLYWEIGHT pattern extricates the immutable part of an object so that this part can be shared.

• The BUILDER pattern moves the construction logic for an object outside the class to instantiate.

• The FACTORY METHOD pattern lets you reduce the amount of responsibility in a class hierarchy by moving an aspect of behavior to a parallel hierarchy.

• The STATE and STRATEGY patterns let you move state-specific and strategy-specific behavior into separate classes.

5) Special rules regarding constructors include the following.

• You must use new to invoke a constructor.

• Constructor names must match the class name. This results in the oddity that, unlike most methods, constructor names normally begin with an uppercase letter.

• If you do not supply a constructor for a class, Java will provide a default.

• You can invoke other constructors with this() and super() so long as this invocation is the first statement in a constructor.

6) Storing a memento as an object assumes that the application will still be running when the user wants to restore the original object. Reasons that will force you to save a memento to persistent storage follow.

• The ability to restore an object's state has to survive a system crash.
• You anticipate that the user will exit the system and will want to resume work later.
• You need to reconstruct an object on another computer.

7) Is a reusable sort routine an example of TEMPLATE METHOD or an example of STRATEGY?

• For STRATEGY: According to Design Patterns, TEMPLATE METHOD lets "subclasses" redefine certain steps of an algorithm. But the Collections.sort() method doesn't work with subclasses; it requires a Comparator instance. Each instance of Comparator provides a new method and thus a new algorithm and a new strategy. The sort() method is a good example of STRATEGY.

• For TEMPLATE METHOD: There are many sorting algorithms, but Collections.sort() uses only one, a merge sort. Changing the algorithm would mean changing to, say, a heap sort or a bubble sort. The intent of STRATEGY is to let you plug in different algorithms. That doesn't happen here. The intent of TEMPLATE METHOD is to let you plug a step into an algorithm. That is precisely how the sort() method works.