Design Patterns Java™ Workbook - Part5

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 (9-10).

1) Clients ordinarily gather information from an interesting object by calling its methods. But when an interesting object changes, a problem arises: How do clients that depend on the object's information know that the information has changed?

You may encounter designs that make an object responsible for informing clients when an interesting aspect of the object changes. The problem with this is that the knowledge of which attributes about an object are interesting lies with the client. The interesting object shouldn't accept responsibility for updating the client.

One solution is to arrange for clients to be informed when the object changes and leave it to the clients to follow up with interrogations about the object's new state. The intent of the OBSERVER pattern is to define a one-to-many dependency such that when one object changes state, all its dependents are notified and updated automatically.

2) Model/View/Controller

As applications and systems grow, it is important to divide and redivide responsibility so that classes and packages stay small enough to maintain. The phrase model/view/controller (MVC) refers to separating an interesting object—the model—from GUI elements that portray it—the view and the controller. Java supports this separation of responsibility with its OBSERVER mechanics.

3) Whether you use Observer, PropertyChangeSupport, or another class to establish the OBSERVER pattern, the point is to define a one-to-many dependency among objects. When one object changes state, all its dependents are notified and updated automatically. This limits the responsibility and eases maintenance of both interesting objects and their interested observers.

4) Ordinary object-oriented development distributes responsibility as far as it will go, with each object doing its own work independently. The OBSERVER pattern supports this distribution by minimizing the responsibility of an object that other objects find interesting. The SINGLETON pattern resists the distribution of responsibility to let you centralize respon-sibility in particular objects that clients locate and reuse. The MEDIATOR pattern too centralizes responsibility but for a particular set of objects rather than for all the clients in a system.

5) Providing a central authority for a group of objects is useful when the interactions the objects gravitate toward the complex condition in which every object is aware of every other object in the group. Centralization of responsibility is also useful when the logic surrounding the interactions of the related objects is independent of the other behavior of the objects.The MEDIATOR pattern defines an object that encapsulates how a set of objects interact. This promotes loose coupling, keeping the objects from referring to one another explicitly, and lets you vary their interaction independently.

6) Whenever the interaction of a set of objects is complex, you can centralize the responsibility for this interaction in a mediator object that stands outside the interacting group. This promotes loose coupling—a reduction in the responsibility that the interacting objects bear to one another. Managing the interaction of objects in an independent class also has the advantage of simplifying and standardizing the interaction rules.

7) Summary

The MEDIATOR pattern promotes loose coupling, keeping related objects from referring to one another explicitly. MEDIATOR shows up most often in GUI application development, in which you don't want to manage the complexity of individual widgets' updating one another.The architecture of Swing guides you in this direction, encouraging you to define objects that register for GUI events. If you are developing with Swing, you are probably applying MEDIATOR.

Swing nudges you into using MEDIATOR, but Swing does not force you to move this mediation outside an application class. Doing so can simplify your code. You can let a mediator class concentrate on the interaction between objects and let an application class concentrate on component construction.

There are other cases in which you can benefit from introducing a mediator object. For example, you might need a mediator to centralize responsibility for maintaining the relational integrity in an object model. You can apply MEDIATOR whenever you need to define an object that encapsulates how a set of objects interact.

Glossary

MONITOR

A lockable object aspect that represents possession of the object by a thread.

N-TIER

A type of system that assigns layers of responsibility to objects running on different computers.

OPERATION

A specification of a service that can be requested from an instance of a class.

PARALLEL HIERARCHY

A pair of class hierarchies in which each class in one hierarchy has a corresponding class in the other hierarchy.

PARSER

An object that can recognize elements of a language and decompose their structure,according to a set of rules, into a form suitable for further processing.

PATH

In an object model, a series of objects such that each object in the series has a reference to the next object in the series.

PATTERN

A way of doing something; a way of pursuing an intent.

POLYMORPHISM

The principle that method invocation depends on both the operation invoked and the class of the invocation receiver.

REFACTOR

To change code to improve its internal structure without changing its external behavior.

RELATION

The way in which objects stand with regard to one another. In an object model, the subset of all possible references from objects of one type to objects of a second type.

REMOTE METHOD INVOCATION

A Java facility that lets objects on different computers communicate.