Design Patterns Java™ Workbook - Part4

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 (7-8).

1) The responsibility of an object is comparable to the responsibility of a representative in the Oozinoz call center. When you order fireworks from Oozinoz, the person you speak to is a representative for the company—a proxy. He or she performs foreseeable tasks, usually by delegating tasks to other systems and people. Sometimes, the representative will delegate a request to a single, central authority who will mediate the situation or will escalate problems up a chain of responsibility.

2) Like call center representatives, ordinary objects have the information and methods they need to operate independently. Sometimes, however, you need to centralize responsibility,diverting from the normal independent operation of objects. Several design patterns address this need. Other patterns let objects escalate requests and isolate an object from other objects that depend on it. Responsibility-oriented patterns provide techniques for centralizing,escalating, and limiting ordinary object responsibility.

3) Establishing principles for the proper assignment of responsibility in object-oriented systems seems to be an area ripe for progress in computer science. A system in which every class and method clearly defines its responsibilities and bears them correctly is a strong system,probably stronger than most systems we encounter today.

4) It is common to speak of classes and methods as bearing various responsibilities. In practice,this usually translates into your bearing responsibility for the solid design and proper functioning of your code. Fortunately, Java offers some relief. You can limit the visibility of your classes, fields, and methods and thereby limit your responsibility to developers who use your code.

5) Beyond Ordinary Responsibility

Like developers, objects have certain responsibilities but in a different sense. Objects cannot bear a moral, ethical, or professional responsibility, but we do say that object-oriented development distributes responsibility to individual objects. This is primarily a way of characterizing encapsulation, the idea that an object works on its own data. Object-oriented development ordinarily distributes responsibility as far as it will go, meaning that each object does its own work.

Distributed responsibility is the norm, but several design patterns oppose this and move responsibility to an intermediary or to a particular object. A central figure may absorb certain responsibilities, or you may also need policies for escalating requests to other authorities.And, although objects are normally highly responsible, you may want to observe their behavior without their knowing it. You can think of the intent of the OBSERVER pattern and several other patterns as exceptions to the ordinary rule of distributed responsibility.

6) Objects can usually act responsibly just by performing their own work on their own attributes,without incurring obligations beyond self-consistency. Some objects, though, take on further responsibilities, such as modeling real-world entities, coordinating work, or modeling the overall state of a system. When a particular object in a system bears a responsibility on which other objects rely, you need a way of finding the responsible object. For example, you might need to find an object that represents a particular machine or a customer object that can construct itself from data in a database or an object that initiates system memory recovery.

Glossary ( starting D pg: 389)

LOOSE COUPLING

A comparatively small and well-defined amount of responsibility that interacting objects bear to one another.

MEASURE

A combination of a magnitude (a number) and a dimension.

MESSAGE

Usually, a method call but generally a portrayal of communication between objects, as in a sequence diagram.

METHOD

An implementation of an operation.

METHOD LOOKUP

The algorithm for deciding which definition of a method to use when a client calls an object's method.

MODEL/VIEW/CONTROLLER

A design that separates an interesting object—the model—from user interface elements that portray it—the view and the controller.

MOLALITY

A count of the number of molecules in a batch of a chemical substance.