18 Design Patterns18.1 Definitions and General OO Principles18.1.1 Definitions18.2 General OO Principles18.3 Patterns18.3.1 GRASP: General Responsibility Assignment Software Patterns 18.4 More Complex Design PatternsChapter 18: Design PatternsDesign patterns are elegant, adaptable, and reusable solutions to everyday software development problems.Each pattern includes a description of a commonly occuring type of problem, a design for a set of classes andclass relationships that solve that problem, and reasons why the given solution is wise.18.1 Definitions and General OO Principles18.1.1 Definitions1. Subclass: X is a subclass of Y if X is derived from Y directly or indirectly.2. Collaboration: two or more objects that participate in a client/server relationship in order to provide aservice.3. Coupling: A dependency between program elements (such as classes) typically resulting from collaborationbetween them to provide a service. Classes X and Y are coupled if. . .• X has a function with parameter or local variable of class Y.• X has a data member that points at something of class Y.• X is a subclass of Y.• X implements an interface for class Y (Y gives friendship to X).[Example:] If the Key class calculates the hash-table index, it must know the length of the hash table.But this couples two classes that would not otherwise be coupled.4. Cohesion: This is a measure of how strongly related and focused the responsibilities of a class are. A classwith high cohesion is a “specialist” with narrow power.5. System event: A high-level event generated by an external actor; an external input event. For each systemevent, there is a corresponding operation. For example, when a word-processor user hits the “spell check”button, he is generating a system event indication “perform spell check”.6. Use case: The sequence of events and actions that occur when a user participates in a dialog with a systemduring a meaningful process.18.2 General OO Principles1. Encapsulation. Data members should be private. Public accessing functions should be defined only whenabsolutely necessary. [Why] This minimizes the possibility of getting inconsistent data in an object andminimizes the ways in which one class can depend on the representation of another.2. Narrow interface. Keep the interface (set of public functions) as simple as possible; include only thosefunctions that are of direct interest to client classes. Utility functions that are used only to implement theinterface should be kept private. [Why] This minimizes the chance for information to leak out of the classor for a function to be used inappropriately.3. Delegation: a class that is called upon to perform a task often delegates that task (or part of it) to oneof its members who is an expert. [Example:] HashTable::find selects one list and delegates the searchingtask to List::find.217218 CHAPTER 18. DESIGN PATTERNS18.3 PatternsA pattern is a design issue or communication problem... with a solution based on class structure... and guidanceon how to apply the solution in a variety of contexts.18.3.1 GRASP: General Responsibility Assignment Software Patterns• High cohesion is desirable. [Why?] It makes a class easier to comprehend, easier to maintain, and easierto reuse. The class will also be less affected by change in other classes. [Example:] Cohesion is low ifa HashTable class contains code to extract fields from a data record. Cohesion is low if the data classcomputes a hash index. Cohesion is high if each class does part of the process.• Low coupling is desirable. Which class should be given responsibility for a task? [A] Assign a responsibilityso that its placement does not increase coupling. [Why?] High coupling makes a class harder to understand,harder to reuse, and harder to maintain because changes in related classes force local changes.• Expert. Who should do what? [A] Each class should do for itself actions that involve its data members.Each class should “take care of” itself and handle its own emergencies. [Why] This minimizes coupling.• Creator. Who should create (allocate) an object? [A] The class that composes, aggregates or contains it.[Why] This minimizes coupling.Who should delete (deallocate) an object? [A] The class that created it. [Why] To minimize confusion,and because, often, nothing else is possible.• Don’t Talk to Strangers. That is, don’t “send messages” to objects that are not close to you. Non-strangersare:– your own data members.– elements of a collection which is one of your own data members.– a parameter of the current function.– a locally-created object.– this (but using this is rarely the right thing to do).Delegate the operation [Why] This is a generalization of the old rule, don’t use globals. It maximizes thelocality of every reference and avoids unnecessary coupling between classes.[Example] Don’t deal directly with a component of one of your own members. Suppose a hardware storeclass composes an object of class Inventory, and the Inventory is a flex-array of Item pointers, as shownbelow. The retail store would be talking to a stranger if its sell function called the sell function in theItem class directly, like this: Inv.find(currentKey)->sell(5); The preferred design is to work throughthe intermediate class. That is, Inventory should provide a function such as sell(key, int) that canbe called by RetailStore, and Inventory::sell(key, int) should call Inventory::find(key) followedby Item::sell(int). Evaluation: In the first design, a change in the Item class might force a change inboth RetailStore and Inventory. Using the second design, only Inventory is affected.RetailStore Inventory Item- Inv : Inventory - L : Itemlist+ order(int)+ sell(int)+ find(key) : Item*+ sell(key, int): void*+ sell(key, int) : voidFigure 18.1: Don’t talk to strangers.18.4 More Complex Design Patterns• Adapter. Sometimes a toolkit class is not reusable because its interface does not match the domain-specificinterface an application requires. [Solution:] Define an adapter class that can add, subtract, or overridefunctionality, where necessary. There are two ways to do this; on the left is a class adapter, on the rightan object adapter.18.4. MORE COMPLEX DESIGN PATTERNS 219TargetClassAdaptorrequest()request()AdapteerightAction_wrongName()ClassAdaptor::request() { rightAction_wrongName();} ClientObjectAdaptor::request() { a->rightAction_wrongName(); }