The Goal of Object-Oriented (OO) Design Patterns Our goal is to - - PDF document

The Goal of Object-Oriented (OO) Design Patterns

• Our goal is to design good OO software
• systems. Here, “good” means reusable

and flexible.

• We want source files that require no

modification when used in future systems.

• Contrary to initial expectations

(ca., 1990), OO design is difficult. Creating reusable designs is even more difficult.

• Inexperienced designers tend to overuse
• inheritance. Rearranging the inheritance

hierarchy of an existing system is very

• traumatic. There is an alternative.
• Each pattern is the result of many

iterations, by experts, which eventually resulted in reusable designs. By understanding them, our “first” designs can be reusable.

OODP.1

The Risks of Patterns

• If you don’t need reusable and flexible

designs, don’t use these patterns. They add complexity.

• Don’t apply them without careful analysis.
• They can complicate a system and reduce

performance.

• Use them only when the added reusability

and flexibility is worth the cost.

OODP.2

The Form and Structure of a Pattern

• Each pattern has several parts:

– Name (and aliases) – Motivation (with examples) – Applicability: how the pattern addresses the problem – Structure: UML diagram – Participants: interfaces, classes, and methods – Collaborations (between participants) – Consequences: pros and cons of using the pattern – Implementation Choices – Sample Code – Known Uses – Related Patterns: similar and dependent patterns

OODP.3

Patterns in The BSU CS Curriculum

• We offer a senior-level elective, CS 472

(Object-Oriented Design Patterns): Reviews object-oriented design principles, explains the goals and form of design patterns, and examines several well-known patterns.

• However, other courses use rudimentary

patterns: – CS 121: Java’s Swing API – CS 221: Iterator(257), Adapter(139), and Bridge(151) – CS 354: Interpreter(243)

OODP.4

The History of Patterns (1 of 2)

• OO design patterns were modeled after

Christopher Alexander’s brick-and-mortar construction patterns, 1977: pub/ch1/ca-cover.pdf pub/ch1/ca-face.pdf Each pattern describes a problem that occurs over and over again in

• ur environment, and then describes

the core of the solution to that problem, in such a way that you can use this solution a million times

• ver, without ever doing it the same

way twice.

OODP.5

The History of Patterns (2 of 2)

• James Coplien’s Advanced C++

Programming Styles and Idioms, 1992.

• Erich Gamma’s Ph.D. dissertation (in

German), 1992. He also worked on JUnit and Eclipse.

• Erich Gamma, Richard Helm, Ralph

Johnson, and John Vlissides wrote the Gang of Four (GoF) book, in 1995: pub/ch1/gof.pdf “... the most popular computer book ever published, with over one million copies in print.” It contains 23 patterns, in 3 categories: – Creational patterns determine how

• bjects are created.

– Structural patterns determine how

• bjects look.

– Behavioral patterns determine how

• bjects act.

OODP.6

How Design Patterns Solve Design Problems (1 of 2)

• Patterns help us decompose a system into
• bjects:

– An object encapsulates data, and methods that operate on the data. – An object’s data should be private. Only an object’s methods can change it. – OO design methodologies typically produce designs where objects correspond to nouns in the problem statement or real-world entities. But, good designs often end up with objects that have no real-world counterpart (e.g., Adapter). Patterns help us include these objects in our designs, increasing flexibility and reusability.

OODP.7

How Design Patterns Solve Design Problems (2 of 2)

• They help us determine object granularity:

– An object can be tiny or huge. We may need one object of a class, or thousands. – Some patterns describe objects that create objects, compose objects, or implement requests between objects.

• They help us specify object interfaces:

– A method’s name, argument types, return type, and exceptions compose its signature. – The set of public-method signatures defined by an object is its interface. – A type is a name denoting an interface.

OODP.8

The GoF Principles of Object-Oriented Design

• 1. Program to an interface, not an

implementation. This reduces coupling and allows an implementation to be replaced.

• 2. Favor object composition over class

inheritance. Using has-a, rather than is-a, preserves encapsulation and allows classes and class hierarchies to remain small. It leads to more reusable designs, where reuse can

• ccur dynamically, at run time.

OODP.9

Delegation

• With inheritance, a subclass can defer

requests to a superclass, by not overriding a superclass method.

• Delegation is the object-composition way
• f doing this.
• A Delegator object can delegate a request

to a Delegate object.

• Thus, object composition can always

replace inheritance for code reuse.

• This is very common:

pub/ch1/LightSwitch.java Here, an object of class LightSwitch delegates part of the init request to an

• bject of class ToggleButton.

OODP.10

The Iterator Pattern(257) (1 of 4)

• Aliases: It is also known as Cursor or

Enumerator.

• Motivation/Applicability:

– You want to access an aggregate’s content without exposing representation. – You want concurrent traversals. – You want polymorphic iteration.

• Structure:

pub/patterns/Iterator.pdf

OODP.11

The Iterator Pattern(257) (2 of 4)

• Participants:

– Iterator: This is the interface for access and traversal. – ConcreteIterator: This implements Iterator for a particular aggregate. It records the current position in an aggregate. – Aggregate: This is the interface for creating an Iterator object. – ConcreteAggregate: This implements the interface for creating an Iterator

• bject.

OODP.12

The Iterator Pattern(257) (3 of 4)

• Consequences:

– It supports different traversals of a single data structure. – It simplifies the Aggregate interface. – It supports concurrent traversal, because each ConcreteIterator maintains state.

OODP.13

The Iterator Pattern(257) (4 of 4)

• Implementation:

– There are external and internal iterators: ∗ With an external iterator, the client performs an action on each element. ∗ With an internal iterator, the client tells the iterator what to do with each element. ∗ External iterators are more flexible, but internal iterators are more convenient. – Robust iterators allow elements to be added or removed during traversal. – Of course, you can provide additional methods (e.g., prev) or fewer methods (e.g., merge next and isDone).

OODP.14

The Iterator Pattern(257)

• This is a simple Java program,

demonstrating the pattern: pub/ch2/Iterator.java pub/ch2/BoxIterator.java pub/ch2/Aggregate.java pub/ch2/Box.java

OODP.15