Java Course 11: Design Patterns

Java course - IAG0040

Design Patterns

Anton Keks 2011

The Increasing Complexity

Complexity of software systems
Time

New programming paradigms
Higher level of abstraction
HW Assembler Structural P. (DSL, AOP?)
CPUs Procedural P. OOP ...

Java course – IAG0040 Lecture 11
Anton Keks Slide 2

The emerge of OOP
●
Response to complexity
● Software crisis: difficulty of writing correct,
understandable, and verifiable programs

●
Emphasizes modularity & reusability
●
Solves the “Tramp Data” problem
●
Closer to the Real World
●
Program == cooperating objects,
not a list of instructions
Anton Keks Slide 3

What are design patterns?
●
Anywhere in the world you can find recurring
patterns
●
Design patterns
– are building blocks of a system's architecture
– are recurring solutions to design problems
that you see over
– identify and specify abstractions that are
above the level of single classes and instances

Anton Keks Slide 4

Where do they come from?
●
First referenced in early 80's,
with the emerge of OOP
● Formally defined in 1994 in the GOF book
(even before Java!)
●
Hundreds more have been identified since
then

●
Are usually discovered (through pattern-
mining) rather than invented
Anton Keks Slide 5

GOF (Gang of Four) book
●
Title: Design Patterns:
Elements of Reusable
Object-Oriented
Software
●
Is the first and essential
book on patterns
●
Patterns are well
classified and described
● Every professional
software developer must
know them
Anton Keks Slide 6

MVC
●
Model-View-Controller
●
One of the first patterns, comes from Smalltalk language
●
Is a “best practice” of splitting GUI applications into
– Model - holds/stores data and provides data access interface
– View - displays data to the user obtained from the model
– Controller - manipulates the model, selects appropriate views
● Therefore, the code consists of three decoupled layers, which
can work together or independently
● Any of the layers can be modified/rewritten without
modifications to other layers

Anton Keks Slide 7

Pattern classification
● The GOF book defines 3 major types of patterns:
– Creational patterns are ones that create objects for
you, rather than having you instantiate objects directly.
This gives your program more flexibility in deciding
which objects need to be created for a given case.
– Structural patterns help you compose groups of objects
into larger structures, such as complex user interfaces
or accounting data.
– Behavioral patterns help you define the
communication between objects in your system and
how the flow is controlled in a complex program.

Anton Keks Slide 8

Anti-patterns
●
This term is also widely used to define certain
patterns, which should be avoided in software design
●
Anti-patterns (aka pitfalls) are commonly reinvented
bad solutions to problems
●
Knowing anti-patterns is as important as knowing
patterns
● Another term used in Agile Software Development is
code smell (eliminated by refactoring)
●
See Wikipedia articles on both Anti-pattern and
Code smell for more info and examples
Anton Keks Slide 9

Software Design vs Architecture
●
Software design is the structure of code and
relations between its elements (classes)
● Software architecture is the same as software
design, but used when people want to make it
look important (after Martin Fowler)
– Architecture is the part of design that is
difficult to change
– Therefore it is undesired :-)

Anton Keks Slide 10

Some design considerations
●
Thinking about design is very important at all
stages during a project. If it needs corrections
then refactoring should be used
●
Consistent API and loosely coupled code are
very important - they make changes easy
●
Unit tests and TDD help a lot
●
Design patterns help make your design better
and more understandable to others

Anton Keks Slide 11

General concepts of design
●
Fundamental reason for patterns: keep classes
separated, prevent them from knowing too much
about each other
●
Abstract classes and interfaces are major tools
●
Program to interfaces, not to implementations
● Prefer object composition to inheritance; it usually
results in cleaner code (this is simply a construction
of objects that contain others)
– Delegation may be used for reusing “parent” behavior

Anton Keks Slide 12

Iterator
●
Behavioral pattern, synonym: Cursor
●
You already know it from the Collections API!
●
Iterator provides a way for accessing elements of an
aggregate object sequentially without exposing its
underlying representation
●
Iterator is a special object provided by an aggregate
object for holding of iteration state
– better than if aggregate objects change their state during
iteration (e.g. provide their own next() methods)
– better than index-based element access - hides
implementation details
– several iterators may be used at once on the same data
Anton Keks Slide 13

Lazy Initialization
●
The idea is to initialize “expensive” objects on demand, e.g.
only when they are accessed (this is sometimes referred to as
“caching”)
– if expensive object is never accessed then it is never created
● If initialization takes time and several threads access the object,
then synchronization is needed
● Double-checked locking is a clever (but broken) trick:
– public Object getExpensiveObject() {
if (instance == null) {
synchronized (this) {
if (instance == null)
instance = new ...
}
}
return instance;
}
Anton Keks Slide 14

Singleton
●
Creational pattern, sometimes uses lazy initialization
●
Ensures a class has only one instance, and provides
global access point to it
● public class Singleton {
private Singleton() {} // private constructor
private static Singleton uniqueInstance =
new Singleton();
public static Singleton getInstance() {
return uniqueInstance;
// can be lazily initialized
}
}

Anton Keks Slide 15

Singleton (2)
● Better than global variables (controlled access,
doesn't pollute namespace)
● More flexible than class operations (static
methods): can be polymorphic and subclassed,
permits easy design changes, etc
● Disadvantages: may result in coupled code, if
used directly too much. Difficult to mock in unit
tests
● (better alternative – use singletons in an IoC
container, like PicoContainer or Spring)
Anton Keks Slide 16

Factory Method
● Creational pattern, synonyms: Factory, Virtual
Constructor
● Defines an interface for creating an object of
particular abstract type, but lets subclasses decide
which concrete class to instantiate
● Used by many modern frameworks and APIs (e.g.
SAXParserFactory)
● public class BulldogFactory implements DogFactory {
public Dog createDog() { return new Bulldog(); } }
● public class DachshundFactory implements DogFactory {
public Dog createDog() {
return new Dachshund(); } }
Anton Keks Slide 17

Factory Method (2)
●
Allows writing of polymorphic code that can work
with different implementations of interfaces without
any direct references to them, eliminates hardcoding
of implementation class names
● The method must be non-static, if you want to override
it in a superclass of factory
● Variation: factory method can be static and decide
itself what to instantiate
– using configuration
– with the help of parameters

Anton Keks Slide 18

Abstract Factory
●
Creational pattern, synonym: Kit
●
Provides an interface for creating families of related
or dependent objects without specifying their
concrete classes
●
Abstract Factory is similar to Factory Method with the
exception that methods are never static and
Factories are always subclassed in order to return
different sets of instances

Anton Keks Slide 19

Abstract Factory (2)
●
Example: GUI toolkit with Factories for creation of
widgets with different look and feel
● public interface AbstractWidgetFactory {
public Button createButton();
public ScrollBar createScrollBar();
}

public class MotifLookAndFeelWidgetFactory
implements AbstractWidgetFactory {
...
}

Anton Keks Slide 20

Builder
●
Creational pattern
●
Eliminates 'telescoping' constructors
– without sacrificing immutability
– has all advantages of Factory
●
Create Builder inner static class with methods returning
'this' and build() method returning the class instance
● Pizza pizza = new Pizza.Builder().
withOnion().doubleCheese().build();
●
Very readable, better than infinite number of constructors
with boolean or numeric arguments, or setters

Anton Keks Slide 21

Common structural patterns

● Decorator
● Adapter

●
Composite
● (Proxy)

Anton Keks Slide 22

Decorator
● Structural pattern, synonym: Wrapper
● Attach additional responsibilities to an object
dynamically.
● Decorators provide a flexible alternative to
subclassing for extending functionality
● Useful for adding responsibilities dynamically to
objects, not classes.
●
Decorator must have the same interface as the
decorated object.

Anton Keks Slide 23

Decorator (2)
●
Decorator delegates all method calls to wrapped
instance and does something else before or after.
Every object can be decorated several times.
● BufferedInputStream decorates any
InputStream
● public class LoggingConnection implements Connection {
private Connection conn;
...
public boolean isActive() {
System.out.println(“isActive was called!”);
return conn.isActive();
}
...
}

Anton Keks Slide 24

Adapter
●
Structural pattern, synonym: Wrapper
● Converts the interface of a class into another
interface clients expect
●
Adapter lets classes work together that
couldn't otherwise because of incompatible
interfaces

Anton Keks Slide 25

Adapter (2)
●
In other words, Adapter just translates requests to
another API of the wrapped class
●
Examples
– InputStreamReader adapts an InputStream to
the Reader interface
– Arrays.asList() represents java arrays as List
instances
– Collections.enumeration() represents
Iterators as Enumerations

Anton Keks Slide 26

Composite
●
Structural pattern, similar to Decorator
● Composes objects into tree structures to
represent part-whole hierarchies
●
Composite lets clients treat individual objects
and compositions of objects uniformly

Anton Keks Slide 27

Composite (2)
● Example: in a GUI toolkit, a Window is a
composite of other Widgets, while is a Widget
itself
● Many GUI toolkits have base classes named
Composite, which can have a layout manager
assigned and an arbitrary number of child
Composites
● SequenceInputStream is a composite of many
InputStreams

Anton Keks Slide 28

Proxy
●
Decorator, Adapter, and Composite
– any of them can be called 'Proxy'
●
Proxy is a class, functioning as an interface to
another thing
●
In a more specific sense (Virtual Proxy):
wrapping classes can
– control access to wrapped objects
– lazily initialize the delegates inside them

Anton Keks Slide 29

Strategy
●
Behavioral pattern, synonym: Policy
●
Defines a family of algorithms, encapsulates each one,
and makes them interchangeable; eliminates
conditions from the code (GoF)
●
Capture the abstraction in an interface, bury
implementation details in derived classes
● Strategy lets the algorithm vary independently from
clients that use it
– Algorithms can be changed on-the-fly at runtime

Anton Keks Slide 30

Strategy (2)
●
Strategy pattern allows adding of new algorithms
easily and/or dynamically
●
Participants:
– Strategy – an interface or abstract class of all
strategies
– ConcreteStrategy – each is a different
implementation of Strategy
– Context – a class, initialized to use and maintain a
ConcreteStrategy, can provide additional (context
specific) data to it

Anton Keks Slide 31

State
●
Behavioral pattern, similar to Strategy
● Each “Strategy” is one of the states of the
Context
– Strategy usually represents a single abstraction
– each State can implement several behaviors
(different actions, methods)
– State interface may as well provide methods for
transitions in order to implement a Finite State
Machine

Anton Keks Slide 32

Façade
● Structural pattern
●
Provides a unified interface to a set of interfaces in subsystem
● Facade defines a higher-level interface that makes the subsystem
easier to use
● Structuring a system into subsystems reduces complexity. Then
subsystems can communicate only through Facades, while using
their own lower-level interfaces internally. This reduces coupling
● Example: consider internals of a compiler: it can have classes like
Scanner, Parser, ProgramNode, BytecodeStream, etc, but externally
you use the Facade class named Compiler, which simply takes input
file and produces an output file
●
Facade just delegates requests to appropriate subsystem classes, it
doesn't do anything itself
Anton Keks Slide 33

Prototype
● Creational pattern
●
Specifies the kind of objects to create using the
prototypical instance
– creates new objects by copying (cloning) the prototype
● Allows having an initialized reference instance of some
abstract class, then it can be cloned or recreated with
reflection API for creation of new objects
● Useful when creating new instances is too complex (and
slow) or less convenient than cloning
● Convenient for implementation of plug-in architectures,
where implementations may be added/removed dynamically

Anton Keks Slide 34

Observer
●
Behavioral pattern, synonym: Publish-
Subscribe
● Defines a one-to-many dependency between
objects so that when one object changes
state, all its dependents are notified and
updated automatically
●
Provides decoupled classes, which can work
together or independently

Anton Keks Slide 35

Observer (2)
●
Participants:
– Subject (Observable) – the data to observe
– Observer – an updating interface for objects, which
are notified
– ConcreteSubject – sends notifications to all
registered ConcreteObservers
– ConcreteObserver – knows about ConcreteSubject,
updates itself on notifications
● Java provides both Observable abstract class and
Observer interface
Anton Keks Slide 36

Java Course 11: Design Patterns

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Java Course 11: Design Patterns

Similar to Java Course 11: Design Patterns (20)

More from Anton Keks

More from Anton Keks (16)

Recently uploaded

Recently uploaded (20)

Java Course 11: Design Patterns