260 likes | 278 Views
BTS430 Systems Analysis and Design using UML. Design Patterns. Patterns. “… a pattern is a named problem/solution pair that can be applied in new contexts, with advice on how to apply it in novel situations and discussion of its trade-offs.” * *Larman , page 218. Design Patterns.
E N D
BTS430 Systems Analysis and Design using UML Design Patterns
Patterns • “…a pattern is a named problem/solution pair that can be applied in new contexts, with advice on how to apply it in novel situations and discussion of its trade-offs.” * *Larman,page 218
Design Patterns • “The best way to use patterns is to load your brain with them and then recognize places in your design and existing applications where you can apply them. Instead of code reuse, with patterns you get experience reuse.”* *Head First Design Patterns, p. xi
References for Pattern theory • The “Bible” • Design Patterns, Elements of Reusable Object-Oriented Software • Erich Gamma • Richard Helm • Ralph Johnson • John Vlissides • Authors known as the Gang of Four so the patterns are called the GoF patterns • First book – 1995 • Most complete
References for Pattern theory • Head First Design Patterns • Eric Freeman and Elisabeth Freeman • (“must have” for BTS530 and 630) • Applying UML and Patterns, third edition • Craig Larman
Beginnings of Patterns • Started with Christopher Alexander, a Professor of Architecture at Berkeley. • Invented patterns for building living architectures, e.g., houses, towns, cities • Books: The Timeless Way of Building and A Pattern Language • Direct analogies between creating “living architecture” and flexible, extensible software* *Head First Design Patterns, p. 602
GRASP Patterns • “A learning aid to help you understand essential object design and apply design reasoning in a methodical, rational, explainable way”. * • Patterns of assigning object responsibilities *Larman, p. 277
GRASP Patterns • “GRASP is an acronym that stands for General Responsibility Assignment Software Patterns” The name was chosen to suggest the importance of grasping these principles to successfully design object-oriented software Larman, p. 222
GRASP Patterns • Do not state new ideas • Name and codify widely used basic principles* *Larman, p. 279
Responsibilities • UML defines a responsibility as “a contract or obligation of a classifier”. • A class embodies a set of responsibilities that define the behaviour of the objects in the class.
Responsibilities • “A responsibility is not the same thing as a method, but methods are implemented to fulfill responsibilities.” • “Responsibilities are implemented using methods that either act alone or collaborate with other methods and objects.” Larman, p. 217
Fig. 17.2: Responsibilities and methods are related Implies Sale objects have a responsibility To create Payments
Responsibilities revolve around • Doing • Knowing • Collaboration
“Doing” responsibilities • Doing something itself, such as creating an object or doing a calculation • Initiating action in other objects • Controlling and co-coordinating activities in other objects Larman, p. 216
“Knowing” responsibilities • Knowing about private encapsulated data • Knowing about related objects • Knowing about things that it can derive or calculate • Larman, p. 216
GRASP Patterns • Key three: • Creator • Controller • Information Expert
Creator • Who should be responsible for creating an new instance of some class? • Some options: • Assign B the responsibility to create A if one or more of the following is/are true: • B “contains” A (e.g. Invoice creates InvoiceLineItem) • B records A • B closely uses A • B has the initializing data for A that will be passed to A when it is created (thus B is the Expert with respect to creating A). (e.g. Sale creates Payment) p. 291
Controller • What first object beyond the UI layer receives and coordinates a system operation? • Use Case or Session Controller • Use case/session (e.g. Register)* Larman, p. 286 and 302
Guidelines/Issues • Controller usually delegates work to other objects—it controls, coordinates, it does not do much work itself • Danger: Bloated controller • a single controller receives all system events (and there are many) • a controller that does the work itself • a controller that has many attributes; maintains significant information • Among Cures for Bloat • more controllers, use case controllers, more delegation
Information Expert • What is the general principle of assigning responsibilities to objects? • A Solution: • Assign a responsibility to the class that has the information necessary to fulfill it—the “information expert” • (note: start this process by clearly stating the responsibility!) Larman, p. 294
Information Expert • Example: Sale has the responsibility of knowing its total, expressed with the method named getTotal Larman, p. 222
Information Expert p. 222
Collaboration • Fulfillment of a responsibility often requires information from different classes of objects • Example, sales total requires the collaboration of 3 classes of objects: Sale, SalesLineItem, ProductDescription • Interact via messages* *Larman, p. 297
Facade • Hides all of the complexity of one or more classes in a simple interface* • Provides a simplified interface to a subsystem while still exposing the full functionality of the system to those who may need it* *Head First Design Patterns, p. 254 *Head First Design Patterns, p. 260