chapter 6: using design patterns
DESCRIPTION
Object-Oriented Software Engineering Practical Software Development using UML and Java. Chapter 6: Using Design Patterns. 6.1 Introduction to Patterns. The recurring aspects of designs are called design patterns. - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/1.jpg)
Object-Oriented Software EngineeringPractical Software Development using UML and Java
Chapter 6: Using Design Patterns
1
![Page 2: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/2.jpg)
2
6.1 Introduction to Patterns
The recurring aspects of designs are called design patterns. • A pattern is the outline of a reusable solution to a general problem
encountered in a particular context • Many of them have been systematically documented for all
software developers to use • A good pattern should
—Be as general as possible—Contain a solution that has been proven to effectively solve the
problem in the indicated context. Studying patterns is an effective way to learn from the experience of
others
![Page 3: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/3.jpg)
3
Pattern descriptionContext:
• The general situation in which the pattern applies Problem:
• A short sentence or two addressing the main difficulty being tackled.Forces:
• The issues or concerns to consider when solving the problemSolution:
• The recommended way to solve the problem in the given context.Antipatterns: (Optional)
• Solutions that are inferior or do not work in this context. Related patterns: (Optional)
• Patterns that are similar to this pattern. References:
• Who developed the pattern.
![Page 4: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/4.jpg)
4
6.2 The Abstraction-Occurrence Pattern
• Context: —Often in a domain model you find a set of related objects
(occurrences).—The members of such a set share common information
- but also differ from each other in important ways.• Problem:
—What is the best way to represent such sets of occurrences in a class diagram?
• Forces: —You want to represent the members of each set of occurrences
without duplicating the common information
![Page 5: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/5.jpg)
5
Abstraction-Occurrence
• Solution:
Create an <<Abstraction>> class that contains the data that is common to all the members of a set of occurrences. Then create an <<Occurrence>> class representing the occurrences of this abstraction. Connect these classes with a one-to-many association.
![Page 6: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/6.jpg)
6
Abstraction-Occurrence
• Solution:
![Page 7: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/7.jpg)
9
6.3 The General Hierarchy Pattern• Context:
—Objects in a hierarchy can have one or more objects above them (superiors), and one or more objects below them (subordinates).
—Some objects cannot have any subordinates • Problem:
—How do you represent a hierarchy of objects, in which some objects cannot have subordinates?
• Forces: —You want a flexible way of representing the hierarchy that
prevents certain objects from having subordinates—All the objects have many common properties and operations
![Page 8: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/8.jpg)
10
General Hierarchy
• Solution:
Create an abstract <<Node>> class to represent the features possessed by each object in the hierarchy -- one such feature is that each node can have superiors. Then create at least two subclasses. <<SuperiorNode>> must be linked by a <<subordinates>> association to the superclass. <<NonSuperiorNode>> must not be.
![Page 9: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/9.jpg)
11
General Hierarchy
• Solution:
![Page 10: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/10.jpg)
12
• Solution:
General Hierarchy
![Page 11: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/11.jpg)
14
6.4 The Player-Role Pattern
• Context: —A role is a particular set of properties associated
with an object in a particular context. —An object may play different roles in different
contexts. • Problem:
—How do you best model players and roles so that a player can change roles or possess multiple roles?
![Page 12: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/12.jpg)
15
Player-Role
• Solution:
Create a <<Player>> class to represent the object that plays different roles. Create an association from this class to the <<AbstractRole>> class. The subclasses of this <<AbstractRole>> class encapsulate all the features associated with the different roles.
![Page 13: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/13.jpg)
16
Player-Role
• Forces: —It is desirable to improve encapsulation by capturing the
information associated with each separate role in a class.—You want to avoid multiple inheritance. —You cannot allow an instance to change class
![Page 14: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/14.jpg)
17
Player-Role
Example 1:
![Page 15: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/15.jpg)
18
Player-Role
Example 2:
![Page 16: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/16.jpg)
20
6.5 The Singleton Pattern
• Context: —It is very common to find classes for which only one
instance should exist (singleton) • Problem:
—How do you ensure that it is never possible to create more than one instance of a singleton class?
• Forces: —The use of a public constructor cannot guarantee that
no more than one instance will be created. —The singleton instance must also be accessible to all
classes that require it
![Page 17: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/17.jpg)
21
Singleton• Solution:
• A private class variable, often called theInstance, which stores the single instance.
• A public class method, often called getInstance(). The first time this method is called, it creates the object. Subsequent calls simply return theInstance.
• A private constructor, which ensures that no other class will be able to create another instance.
![Page 18: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/18.jpg)
22
Singleton• The first time getInstance() is called, it creates the object.
Subsequent calls return that object….
![Page 19: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/19.jpg)
27
6.7 The Delegation Pattern
• Context: —You are designing a method in a class—You realize that another class has a method which
provides the required service —Inheritance is not appropriate
- E.g. because you do not want to use other methods of the class
• Problem: —How can you most effectively make use of a method
that already exists in the other class? • Forces:
—You want to minimize development cost by reusing methods
![Page 20: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/20.jpg)
28
6.7 The Delegation Pattern
• Solution: Create a method in the <<Delegator>> class that calls
a method in the <<Delegate>> class.
![Page 21: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/21.jpg)
29
Delegation
• Solution:
![Page 22: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/22.jpg)
30
Delegation
Example:
![Page 23: Chapter 6: Using Design Patterns](https://reader038.vdocuments.mx/reader038/viewer/2022102517/56816934550346895de08d30/html5/thumbnails/23.jpg)
38
6.10 The Immutable Pattern
• Context: —An immutable object is an object that has a state that never
changes after creation • Problem:
—How do you create a class whose instances are immutable? • Forces:
—There must be no loopholes that would allow ‘illegal’ modification of an immutable object
• Solution: —Ensure that the constructor of the immutable class is the only
place where the values of instance variables are set or modified. —Instance methods which access properties must not have side
effects.