This book covers a wide range of topics, with patterns in the areas of object-oriented infrastructure, programming strategies, temporal patterns, security, domain-oriented patterns, human-computer interaction, reviewing, and software management. Among them, the most interesting are:
Intent
Define the interface for a hierarchy of classes while deferring the implementation to subclasses. Abstract Class lets subclasses redefine the implementation of an interface while preserving the polymorphism of those classes.
Structure
The key to the Abstract Class pattern is a superclass that defines the type for its hierarchy and subclasses that provide various implementations of the type. An abstract class can be implemented as pure interface such that its subclasses must implement all of its messages, but it is more useful still if it also provides a partial implementation suitable for all of the subclasses. In this way, a subclass inherits the partial implementation and only needs to complete it.
I don't find any reason for presenting it as a pattern as this is one of the basic concepts of object oriented programming.
Intent
Adapt an object to different client’s needs through transparently attached role objects, each one representing a role the object has to play in that client’s context. The object manages its role set dynamically. By representing roles as individual objects, different contexts are kept separate and system configuration is simplified.
Structure
The Role Object pattern suggests to model context-specific views of an object as separate role objects which are dynamically attached to and removed from the core object.
Intent
Many classes have ‘compulsory’ properties which must be specified in order for an instance to be in a valid state, for example, before having attributes used as keys in a dictionary or database index. We would therefore like to force the clients of such classes to specify the compulsory properties when creating new instances. Sometimes we also need to ensure that these properties cannot be altered at any time after creation.
Structure
Use a separate object (the Essence object) to receive the compulsory properties of the object being created (the CreationTarget) as shown in Figure . Creation of the Essence object should be unrestricted. Assign a separate method for each property in the Essence class and have the method store the parameter value in the Essence. For properties which should not be changed after object creation, provide ‘set’ methods for these only in the Essence class.
This book presents five basic patterns for implementing relationships between objects. The patterns address the most basic kind of relationships where one object needs to be able to refer to another object at runtime. These relationships are often called associations or collaborations, to distinguish them from the more complex aggregation and inheritance. The rest two patterns describe the fundamental ways to model relationships | either using attributes or using objects. The following three patterns describe how one-to-one, one-to-many and two-way relationships can be modeled.
Relationship As Attribute
Simple, one-way, one-to-one relationships are very common in object oriented models. Because these kinds of relationships arise so often, they need to be simple to represent in a program, so that they are easy to write and can be immediately understood by programmers later reading the program. So make an attribute to represent the relationship.
Relationship Object
Relationships between objects can be very complex, involving two-way communication between many participating objects which are essentially peers. In this case make a Relationship Object to represent the relationship. Move any methods or variables associated with the relationship from the participating objects, and place them into the Relationship Object. Change the implementations of the participating objects so that they refer to each other via the Relationship Object. The Relationship Object may need to use internal subordinate objects to implement the relationship, but these should not be visible through the Relationship Object's interface.
Collection Object
One-way one-to-many relationships are almost as common as one-way one-to-one relationships. Because they are so common, one-to-many relationships need to be implemented as easily and as efficiently as possible. So make a Collection Object to model the relationship. Most object oriented libraries provide a variety of container or collection objects which can be used to represent one-to-many relationships. The "one" object simply stores a collection which holds the "many" objects participating in the relationship.
Active Value
Some one-to-one relationships are important in themselves, rather than simply connecting two objects. One-to-one relationships are often important because of their position in the program's architecture. That is, objects in the program which do not participate directly in the relationship may be affected if the relationship changes. Alternatively, one-to-one relationships may be important to a program due to the underlying domain. That is, a change in the relationship represents a change to an important parameter of the domain, which the program must deal with. The importance of the relationship can be judged by the consequences of a change to the relationship. So make an Active Value to model the relationship. An Active Value is essentially an object which represents a single variable. It should have an attribute to hold the variable's value, and should understand two messages - an accessor to retrieve the value of the variable, and a settor to change the value.
Mutual Friends
You have a two-way relationship (also known as a bidirectional or mutual relationship) where all participating objects are equally important. In a two-way relationship, each participating object needs to be easily accessible from every other object. Make a consistent set of one-way relationships. Implementing Mutual Friends has two steps. First, the two-way relationship should be split into a pair of one-way relationships. Second, the one-way relationships must be kept consistent.
Relationship between Relationship Patterns:
Intent
Object-oriented frameworks are structured in terms of client/server relationships between objects; an object’s services are invoked by client objects through the operations of its interface. A common design requirement is for a server object to maintain state for each client that it is serving. Typically this is implemented by returning handles or untyped pointers to the client that are used to identify the per-client data structure holding its state. The lack of strong typing can lead to obscure errors that complicate debugging and maintenance. This paper presents the Abstract Session pattern which allows objects to maintain per-client state with full type safety and no loss of efficiency. Allow a server object with many client objects to maintain per-client state and maintain type safety.
Structure
The Abstract Session pattern provides a way for an object to store per-client state without sacrificing type-safety or efficiency. A service object, rather than providing a client with a handle to be passed as an argument to the operations of its abstract interface instead creates an intermediate "session" object and returns a pointer to the session object back to the client. The session object encapsulates the state information for the client which owns the session and is only exposed to the client as an abstract interface through which the client can access the protocol’s functionality with full type-safety. When the client invokes operations of the session, the session co-operates with the service object to complete the operation. When the client has finished using the service, it "releases" the session, after which any pointers o the session object are invalid.
Intent
The Proactor pattern supports the demultiplexing and dispatching of multiple event handlers, which are triggered by the completion of asynchronous events. This pattern simplifies asynchronous application development by integrating the demultiplexing of completion events and the dispatching of their corresponding event handlers.
Structure
Counted Body Idiom : Manage logical sharing and proper resource deallocation of objects that use dynamically allocated resources
Detached Counted Body : Adding reference counting to an object to which a reference count cannot directly be added
Handle/Body Hierarchy : To separate representation inheritance from subtyping inheritance
Envelope/Letter : To tie together common semantics of handle and body classes
Virtual Constructor : How to build an object of known abstract type, but of unknown concrete type, without violating the encapsulation of the inheritance hierarchy
Concrete Data Type : Determine whether to allocate an object on the heap or in the current scope
Algebraic Hierarchy : Structuring classes whose type relationships follow classic algebraic types
Homogeneous Addition : Simplify the implementation of operations in an Algebraic Hierarchy
Promote and Add : How to add objects of two different types when only Homogeneous Addition is supported
Promotion Ladder : How to assign type promotion responsibility to classes in an Algebraic Hierarchy
Non-Hierarchical Addition : How to deal with arithmetic operations between types when neither can be promoted to the other
Type Promotion : How to use two type conversion mechanisms—operator functions and constructors—to build a consistent type promotion structure