Design Patterns in Object Oriented Analysis and

Design
JIANG Shuai MU Huaxin
School of Software Engineering International School
Beijing University of Posts and Telecommunications Beijing University of Posts and Telecommunications
Beijing, PRC Beijing, PRC
E-mail: [email protected] E-mail: [email protected]

Abstract—Design pattern is a general reusable solution to a Strategy lets the algorithm vary independently from clients
commonly occurring problem in software development. Good that use it.
OO designs are reusable, extensible and maintainable. Patterns
only give you a general rule not code. Patterns show you how B. Description
to build systems with good OO design qualities. Most of them Strategy Pattern is an encapsulation of each of a family of
address issues of change in software and allow some part of a algorithms. It separates the use and the algorithm itself and
system to vary independently of all other parts by trying to
assigns them to different objects. Generally Strategy Pattern
take what varies in a system and encapsulate it. Patterns also
provide a shared language that can maximize the value of your encapsulates a family of algorithms into a family of Strategy
communication with other developers. In this paper, we briefly classes as the subclass of an abstract Strategy super class.
introduce the concept of software design pattern and give a
research on some design patterns including Strategy Pattern,
Iterator Pattern, Adapter Pattern and Façade Pattern.

Keywords- Design Pattern;OOAD;Software Development

I. INTRODUCTION
In software development, no matter where we work, what
we are building, or what language we are programming in,
“change” is the one true constant that will be with us always.
A design pattern is a general reusable solution to a
commonly occurring problem in software design. A design
pattern is not a finished design that can be transformed
Figure 1. Strategy Pattern Diagram
directly into code. It is a description or template for how to
solve a problem that can be used in many different situations.
Loosely coupled designs allow us to build flexible OO
Object-oriented design patterns typically show relationships
systems that can handle change because they minimize the
and interactions between classes or objects, without
interdependency between objects.
specifying the final application classes or objects that are
When two objects are loosely coupled, they can interact,
involved. Many patterns imply object-orientation or more
but have very little knowledge of each other. The Strategy
generally mutable state, and so may not be as applicable in
Pattern provides an object design where context and strategy
functional programming languages, in which data is
are loosely coupled
immutable or treated as such.
In some situations, behaviors of methods change
Applying design pattern enables developers to reuse it to
frequently between models. A common approach is to
solve a specified designing issue. Design patterns help
implement these behaviors in subclasses. This approach has
designers communicate architectural knowledge, help people
significant drawbacks: behaviors must be declared in each
learn a new design paradigm, and help new developers avoid
new subclass. The work of managing these behaviors
traps and pitfalls that have traditionally been learned only by
increases greatly as the number of models increases, and
costly experiences.
requires code to be duplicated across models. Additionally, it
II. STRATEGY PATTERN is not easy to determine the exact nature of the behavior for
each model without investigating the code in each.
A. Definition The strategy pattern uses composition instead of
The Strategy Pattern defines a family of algorithms, inheritance. In the strategy pattern behaviors are defined as
encapsulates each one, and makes them interchangeable. separate interfaces and specific classes that implement these

___________________________________
978-1-4244-9698-3/11/$26.00 ©2011 IEEE


interfaces. Specific classes encapsulate these interfaces. This need to provide the method because it’s part of the Iterator
allows better decoupling between the behavior and the class interface. If you’re not going to allow remove() in your
that uses the behavior. The behavior can be changed without iterator you’ll want to throw the runtime exception
breaking the classes that use it, and the classes can switch java.lang.UnsupportedOperationException. The Iterator API
between behaviors by changing the specific implementation documentation specifies that this exception may be thrown
used without requiring any significant code changes. from remove() and any client that is a good citizen will
Behaviors can also be changed at run-time as well as at check for this exception when calling the remove() method.
design-time. Iterators imply no ordering. The underlying collections
Because the two are loosely coupled, we are free to make may be unordered as in a hash table or in a bag; they may
changes to either, as long as the objects still meet their even contain duplicates. So ordering is related to both the
obligations to implement the strategy interfaces. properties of the underlying collection and to the
implementation. In general, you should make no assumptions
III. ITERATOR PATTERN about ordering unless the Collection documentation indicates
otherwise.
A. Definition In general the primary purpose of an iterator is to allow a
The Iterator Pattern provides a way to access the user to process every element of a container while isolating
elements of an aggregate object sequentially without the user from the internal structure of the container. This
exposing its underlying representation allows the container to store elements in any manner it
wishes while allowing the user to treat it as if it were a
B. Description simple sequence or list.
The pattern gives you a way to step through the elements
of an aggregate without having to know how things are IV. ADAPTER PATTERN AND FACADE PATTERN
represented under the covers. The effect of using iterators in
your design is very important: once you have a uniform way i. Adapter Pattern
of accessing the elements of all your aggregate objects, you A. Definition
can write polymorphic code that works with any of these
aggregates, without caring if the elements are held in an The Adapter Pattern converts the interface of a class into
Array or ArrayList (or anything else that can create an another interface the clients expect. Adapter lets classes
Iterator), as long as it can get hold of an Iterator. work together that couldn’t otherwise because of
The other important impact on your design is that the incompatible interfaces.
Iterator Pattern takes the responsibility of traversing B. Decription
elements and gives that responsibility to the iterator object, Adapter pattern allows us to use a client with an
not the aggregate object. This not only keeps the aggregate incompatible interface by creating an Adapter that does the
interface and implementation simpler, it removes the conversion. This acts to decouple the client from the
responsibility for iteration from the aggregate and keeps the implemented interface, and if we expect the interface to
aggregate focused on the things it should be focused on change over time, the adapter encapsulates that change so
(managing a collection of objects), not on iteration. Figure 2 that the client doesn’t have to be modified each time it needs
shows the architecture of iterator pattern. to operate against a different interface
The Adapter Pattern is full of good OO design principles:
check out the use of object composition to wrap the adaptee
with an altered interface. This approach has the added
advantage that we can use an adapter with any subclass of
the adaptee.
Also check out how the pattern binds the client to an
interface, not an implementation; we could use several
adapters, each converting a different backend set of classes.
Or, we could add new implementations after the fact, as long
as they adhere to the Target interface.
This is employing the principle of Loosely Coupled.
where two objects can interact, but have very little
knowledge of each other.
Figure 2. Iterator Pattern Class Diagram Because the two are loosely coupled, we are free to make
changes to either, as long as the objects still meet their
The remove() method is considered optional. You don’t obligations to implement the agreed on interfaces.
have to provide remove functionality. But, obviously you do


 The job of implementing an adapter is really proportional Object adapter pattern use composition, it can not only
to the size of the interface you need to support as your target adapt an adaptee class, but any of its subclasses. Class
interface. Think about your options, however. You could adapter patter do have trouble with that because It’s
rework all your client-side calls to the interface, which would committed to one specific adaptee class, but it have a huge
result in a lot of investigative work and code changes. Or, advantage because it doesn’t have to reimplement its entire
you can cleanly provide one class that encapsulates all the adaptee. Class adapter pattern can also override the behavior
changes in one class. of my adaptee if it need to because it’s just subclassing. In
object adapter pattern, we like to use composition over
inheritance; class adapter may be saving a few lines of code,
but all class adapter is doing is writing a little code to
delegate to the adaptee. Object adapater can keep things
flexible. Using a class adapter there is just one of that, not
an adapter and an adaptee, which means efficiency. But one
little object can’t have much impact on efficient of the
system. Class adapter might be able to quickly override a
method, but any behavior object adapter add to its adapter
code works with it’s adaptee class and all its subclasses.
In general the adapter acts as the middleman by receiving
requests from the client and converting them into requests
that make sense on the vendor classes, without changing
your existing code (and you can’t change the vendor’s code)
Figure 3. Object Adapter Pattern Class Diagram The Adapter Pattern’s role is to convert one interface
into another. While most examples of the adapter pattern
There are two kinds of adapters: object adapters and show an adapter wrapping one adaptee, we both know the
class adapters: object adapters and class adapters. You need world is often a bit more messy. So, you may well have
multiple-inheritance to implement it, which isn’t possible in situations where an adapter holds two or more adaptees that
Java. But, that doesn’t mean you might not encounter a need are needed to implement the target interface. This relates to
for class adapters down the road when using your favorite another pattern called the Facade Pattern; people often
multiple inheritance language! Let’s look at the class confuse the two. Next this paper will give a brief
diagram for multiple-inheritance. introduction to Façade Pattern
ii. Façade Pattern
A. Definition
The Facade Pattern provides a unified interface to a set of
interfaces in a subsystem. Facade defines a higher level
interface that makes the subsystem easier to use.
B. Discription
Unlike a lot of patterns, Facade is fairly straightforward;
there are no mind bending abstractions to get your head
around. But that doesn’t make it any less powerful: the
Facade Pattern allows us to avoid tight coupling between
clients and subsystems, and also helps us adhere to a new
Figure 4. Class Adapter Pattern Class Diagram object oriented principle: the principle of least knowledge.
Facades don’t “encapsulate” the subsystem classes; they
The two diagrams look similar. The only difference is merely provide a simplified interface to their functionality.
that with class adapter we subclass the Target and the The subsystem classes still remain available for direct use by
Adaptee, while with object adapter we use composition to clients that need to use more specific interfaces. This is a
pass requests to an Adaptee. nice property of the Facade Pattern: it provides a simplified
There are some issues to be mentioned while considering interface while still exposing the full functionality of the
object adapter and class adapter pattern. system to those who may need it.


 V. CONCLUSION
After learning the design patterns above, we get
some design principles:
z Identify the aspects of your application that vary and
separate them from what stays the same.
Take the parts that vary and encapsulate them, so that
later you can alter or extend the parts that vary
without affecting those that don’t.
It forms the basis for almost every design pattern.
z Program to an interface, not an implementation.
“Program to an interface” really means “Program to a
super type.”
Figure 4. Facade Pattern Class Diagram
The point is to exploit polymorphism by
programming to a super type so that the actual
A facade is free to add its own “smarts” in addition to
runtime object isn’t locked into the code. And we
making use of the subsystem. For instance, while our home
could rephrase “program to a super type” as “the
theater facade doesn’t implement any new behavior, it is
declared type of the variables should be a super type,
smart enough to know that the popcorn popper has to be
usually an abstract class or interface, so that the
turned on before it can pop (as well as the details of how to
objects assigned to those variables can be of any
turn on and stage a movie showing).
concrete implementation of the super type, which
The Facade Pattern also allows you to decouple your
means the class declaring them doesn’t have to know
client implementation from any one subsystem. Let’s say for
about the actual object types!”
instance that you get a change in your business and decide to
z Classes should be open for extension, but closed for
upgrade your subsystem to all new components that have
modification, which is the famous Open-Close-
different interfaces. Well, if you coded your client to the
Principle.
façade rather than the subsystem, your client code doesn’t
z Creating systems using composition gives you a lot
need to change, just the façade (and hopefully the vender is
more flexibility.
supplying that!).
Not only does it let you encapsulate a family of
iii. Conclusion algorithms into their own set of classes, but it also
When you need to use an existing class and its interface is lets you change behavior at runtime as long as the
not the one you need, use an adapter. When you need to object you’re composing with implements the correct
simplify and unify a large interface or complex set of behavior interface.
interfaces, use a facade. REFERENCES
An adapter changes an interface into one a client expects.
[1] Gamma, E., Richard Helm, Ralph Johnson, John Vlissides, “Design
A facade decouples a client from a complex subsystem. Patterns: Elements of Reusable Object-Oriented software” 1995:
Implementing an adapter may require little work or a great Addison-Wesley
deal of work depending on the size and complexity of the [2] Bieman, J.M., Jain, D., Yang, H.J., “OO design patterns, design
target interface. structure, and program changes: an industrial case study” Software
Implementing a facade requires that we compose the Maintenance, Proceedings. IEEE International Conference, Nov.
2001, pp:580, doi: 10.1109/ICSM.2001.972775
facade with its subsystem and use delegation to perform the
[3] McNatt, W.B., Bieman, J.M., “Coupling of design patterns: common
work of the façade. There are two forms of the Adapter practices and their benefits” Computer Softwasre and Applications
Pattern: object and class adapters. Class adapters require Conference, Oct. 2001. COMPSAC 2001. 25th Annual International,
multiple-inheritance. You can implement more than one pp:574, doi: 10.1109/CMPSAC.2001.960670
facade for a subsystem.