Design Patterns Java 4

Design Patterns
Information Type: Working Standard, Disclosure Range: , Information Owner: iulia.jianu, NTT DATA Romania
Design Patterns
• Material for this lecture is taken from
 Design Patterns: Elements of Reusable Object-
Oriented Software
• by Gamma, Helm, Johnson, Vlissides
• ISBN: 0321700694, 9780321700698
 Head First Design Patterns
• By Freeman, Bates, Sierra, Robson
• ISBN: 978-0596007126, 0596007124
MVC
MVC
MVC
MVC
MVC
MVC
MVC
MVC
MVC
MVC
MVC
MVC
MVC
MVC
MVC
MVC
MVC
MVC
MVC
MVC
Behavioral Patterns
• Behavioral patterns are concerned with algorithms and the assignment of
responsibilities between objects. Behavioral patterns describe not just
patterns of objects or classes but also the patterns of communication
between them. These patterns characterize complex control flow that's
difficult to follow at run-time
 Chain of Responsibility
 Command
 Interpreter
 Iterator
 Mediator
 Memento
 Observer
 State
 Strategy
 Template Method
 Visitor
Chain of Responsibility
• Intent
 Avoid coupling the sender of a request to its receiver by giving more
than one object a chance to handle the request
• Chain the receiving objects and pass the request along the chain until an object
handles it
• Applicability
 More than one object might handle a request and the handler is not
known a priori. The handler should be ascertained automatically
 You want to issue a request to one of several objects without
specifying the receiver explicitly
 The set of objects that can handle a request should be specified
dynamically
• Structure
 A typical object structure might look like this
• Advantages
 Reduced coupling
• The pattern frees an object from knowing which other object handles a request
• Both sender and receiver have no explicit knowledge of each other
• Instead of objects maintaining references to all candidate receivers, they keep a
single reference to their successor
 Added flexibility in assigning responsibilities to objects
• You can add or change responsibilities for handling a request by adding or changing
the chain at run time
• Disadvantage
 Receipt isn’t guaranteed
• Since a request has no explicit receiver, there is no guarantee it will be handled. A
request can also go unhandled when the chain is not configured properly
• Related Patterns
 Chain of Responsibility is often applied in conjunction with Composite
pattern
• A component’s parent can act as its successor
Command
Command
Command
Command
Command
Command
Command
Command
Command
Command
Command
Command
Command
Command
Command
Command
• Intent
 Encapsulate a request as an object, thereby letting you parameterize
clients with different requests, queue or log requests, and support
undoable operations
• Applicability
 Commands are an object oriented replacement for callback functions
in a procedural language
 A command object can have a lifetime independent of the original
request
 Support undo operation
• The command interface must have an Undo operation that reverses the effects of a
previous Execute call
 Structure a system around high level operations built on primitive
operations
Command
• Structure
• Advantages
 Decouples the object that invokes the operation from the one that
knows how to perform it
 You can assemble commands into a composite command
 It’s easy to add new commands
Command
 A Composite can be used to implement MacroCommands
 A Memento can keep the state the command required to undo its
effect
 A command that must be copied before being placed on the history
list acts like a Prototype
Mediator
• Intent
 Define an object that encapsulates how a set of objects interact.
Mediator promotes loose coupling by keeping objects from referring
to each other explicitly and it lets you vary their interaction
independently
Mediator
Mediator
Mediator
Mediator
Mediator
• Applicability
 A set of objects communicate in a well-defined but complex ways. The
resulting interdependencies are unstructured and difficult to
understand
 Reusing an object is difficult because it refers to and communicates
with many other objects
 A behavior that’s distributed between several classes should be
customizable without a lot of subclassing
• Structure
Mediator
• Advantages
 Promotes loose coupling between colleagues. You can vary and reuse
Colleague and Mediator classes independently
 Replaces many-to-many interactions with one-to-many interactions
between the mediator and it’s colleagues. One-to-many relationships
are easier to understand, maintain and extend
 It abstracts how objects interact
• Disadvantages
 It limits subclassing. A mediator localizes behavior that otherwise
would be distributed among several objects. Changing this behavior
required subclassing Mediator only
 It centralizes control. It trades complexity of interactions for
complexity in the mediator. A mediator can become very complex and
hard to maintain
Mediator
 Façade differs from Mediator in that it abstracts a system of objects to
provide a more convenient interface. The protocol is unidirectional;
that is, Façade object make requests to the subsystem classes and not
vice versa. In contrast, Mediator’s protocol is multidirectional
 Colleagues can communicate with the mediator using the Observer
pattern
Memento
• Intent
 Without violating encapsulation, capture and externalize an object’s
internal state so that the object can be restored to this later state
• Applicability
 A snapshot of (some portion of) an object’s state must be saved so
that it can be restored to that state later
 A direct interface to obtain the state would expose implementation
details and break the object’s encapsulation
• Structure
Memento
• Collaboration
Memento
• Advantages
 Memento avoids exposing information that only an originator should
manage but that must be stored nevertheless outside the originator
 It simplifies the Originator, because the versions of the internal state
are not managed internally by the Originator
• Disadvantages
 Using memento might be expensive. Sometimes the overhead is to
high in order copy the large amounts of information to mementos and
to restore it back
 Large storage costs for mementos, because a caretaker will never
know how much state is in a memento
Memento
 Commands can use mementos to maintain state for undoable
operations
 Mementos can be used for iteration
State
State
State
State
State
State
State
State
State
State
State
State
State
State
State
State
State
State
State
• Intent
 Allow an object to alter its behavior when its internal state changes.
The object will appear to change its class
• Applicability
 An object’s behavior depends on state and it must change its behavior
at run-time depending on that state
 Operations have large, multipart conditional statements that depend
on the object’s state. This state is usually represented by one or more
enumerated constants. Often, several operations will contain this
same conditional structure
State
State
• Advantages
 It localizes state specific behavior and partitions behavior for different
states
• All behavior associated with a particular state will be located in one object
• New states and transitions can be added easily by defining new subclasses
 It makes state transition explicit
• State objects can protect the Context from inconsistent internal states, because
state transitions represent rebinding one variable
 State objects can be shared
 The Flyweight pattern explains when and how State objects can be
shared
 State objects are often singletons
Template Method
Template Method
Template Method
Template Method
Template Method
Template Method
Template Method
Template Method
Template Method
Template Method
Template Method
• Intent
 Define the skeleton of an algorithm in an operation, deferring some
steps to subclasses. Template Method lets subclasses redefine certain
steps of an algorithm without changing the algorithm’s structure
• Applicability
 To implement the invariant parts of an algorithm once and leave it up
to subclasses to implement the behavior that can vary
 When a common behavior among subclasses should be factored and
localized in a common class to avoid code duplication
 To control subclasses extensions. You can define a template method
that calls “hook” operations at specific points
Template Method
• Structure
• Related patterns
 Factory method are often called by template methods
 Template methods use inheritance to vary part of an algorithm.
Strategies use delegation to vary the entire algorithm
Visitor
• Intent
 Represent an operation to be performed on the elements of an object
structure. Visitor lets you define a new operation without changing
the classes of the elements on which it operates
• Applicability
 An object structure contains many classes of objects with different
interfaces and you want to perform operations on these objects that
depend on their concrete classes
 Many distinct and unrelated operations need to be performed on
objects in an object structure and want to avoid “polluting” their
classes with these operations
 The classes defining the object structure rarely change, but you often
want to define new operations over the structure
Visitor
• Structure
Visitor
• Collaboration
Visitor
• Advantages
 Add new operations easy. To create a new operation, just add a new
Visitor
 A visitor gathers related operations and separates unrelated ones
 With the use of an iterator visiting across class hierarchies is easy
 Visitors can accumulate state as they visit each element in the object
structure. Without a visitor this state might appear global variables
• Disadvantages
 Adding new concrete element is hard. Each new subclass of Element
implies the addition of a new abstract operation in Visitor class. And this
abstract operation needs then to be implemented by all subclasses of
Visitor
 Breaking encapsulation. Visitor’s approach assumes that ConcreteElement
interface is powerful enough to let visitors do their job
Visitor
 Composite: Visitors can be used to apply an operation over an object
structure defined by the composite pattern
 Interpreter: Visitor may be applied to do the interpretation
Visitor
Visitor
Visitor
Assignment
• SSE 4.0
• In the next development iteration, you are required to redesign formula cells in
order to allow the definition of more general mathematical expressions.
Expressions combine a number of operators (either unary or binary) with a
number of operands (either constant values or numeric cell values).
• Example: [1,1] * (2 + [2,3]) - sqrt([4,4] + [4,5])
• The following operators should be supported: +, -, *, /, sqrt (square root), exp
(exponent). Hint: employ the pattern “composite” for representing mathematical
expressions.
• You are then required to design and implement all formula related functionality
(i.e. display and evaluate, described below) in SSE, in accordance with the design
pattern “visitor”.
• In other words, the evaluation of mathematical expressions should be
implemented using a specialized visitor class.
• The display functionality for mathematical expressions stored in SSE spreadsheets
should produce the “preorder” representation of arbitrary expressions, by
“visiting” their corresponding abstract syntax trees.

Design Patterns Java 4

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Design Patterns Java 4

Uploaded by

Copyright:

Available Formats

Design Patterns

 A typical object structure might look like this

You might also like