Text
Page: 1
Patterns
in Software Engineering
Giovanni Sakti
Starqle
Page: 2
What is Patterns?
Page: 3
Patterns
Patterns describes a problem,
which occurs over and over again
in our environment and then
desribes the core of the solution
to that problem...
[cited from `Christopher Alexander']
Page: 4
Patterns
...in such a way that you can use
this solution a million times over
without ever doing it the same
way twice.
[cited from `Christopher Alexander']
Page: 5
Okay, but who is Christopher
Alexander?
Page: 7
He authored widely-influential book in
1977.
Page: 9
The book influences multiple
disciplines including software
engineering.
Page: 10
So, what is patterns from the
viewpoint of software engineering?
Page: 11
Patterns
Patterns are distilled commonalities
that you find in software.
Page: 12
Patterns
It allows us to deconstruct a large
complex structure and build using the
pattern itself.
Page: 13
Patterns
Patterns contain solution that have
developed and evolved over time.
Page: 14
Patterns
It is rarely designs that people tend to
get initially.
Page: 15
We know that designing software is
hard.
Page: 16
Designing software with reusable
components are even harder.
Page: 17
Your design should be specific to the
problem at hand, but general enough
to address future problems and
requirements.
Page: 18
Reusable & flexible design is difficult,
if not impossible, to get "right" the
first time.
Even for experienced designer.
Page: 19
Reusability
Instead, experienced designer won't
try to solve every problem from
scratch.
Page: 20
Reusability
They will try to reuse existing solution
instead.
Page: 21
Reusability
So, patterns help designer gets a
design "right" faster.
Page: 22
What can learning patterns help you?
Page: 23
Expectations
Common design vocabulary
Page: 24
Expectations
Documentation and learning aid
Page: 25
Expectations
An adjunct to existing methods
Page: 26
Expectations
A target for refactoring
Page: 27
Expectations
Common design vocabulary
Documentation and learning aid
An adjunct to existing methods
A target for refactoring
Page: 28
Patterns Essential Elements
Page: 29
Patterns Essential Elements
An excellently documented patterns
will have several elements attached to
it.
Page: 30
Patterns Essential Elements
Which you can use to learn more
about them.
Page: 31
Patterns Essential Elements
Name
Intent
Sketch
Page: 32
Patterns Essential Elements
(cont'd)
Problem
Solution
Consequence(s)
Page: 33
Patterns Essential Elements
(cont'd)
When to Use It
Example(s)
Page: 34
Patterns Categories
Page: 35
Patterns Categories
There are several categories of
patterns, based on the level in which
they reside.
Page: 36
Patterns Categories
From "lowest" level to "highest" level
Programming Paradigms
Design Patterns
Architectural Patterns
Page: 37
Patterns Categories
We'll try to discuss it one-by-one.
Page: 38
Programming paradigms
Page: 39
Programming Paradigms
(*1)
Programming paradigms , in a way, is
a pattern.
(*1) Such as: OO, Functional or Procedural
Page: 40
Programming Paradigms
To be precise, programming paradigms
is the smallest and lowest level of
patterns possible.
Page: 41
Programming Paradigms
Programming paradigms are most
likely to influence patterns that reside
above it.
Page: 42
Programming Paradigms
And because programming paradigms
are tightly coupled to programming
language..
Page: 43
Programming Paradigms
..our pick of programming language
may influence the way we design our
software.
Page: 45
Design Patterns
Design patterns are code-level
commonalities.
Page: 46
Design Patterns
Providing schemes for refining &
building smaller subsystems.
Page: 47
Design Patterns
Design patterns are medium-scale
tactics that flesh out some of the
structure & behaviour of entities and
their relationships.
Page: 48
Design Patterns
As we discuss previously, design
patterns may be influenced by
programming paradigms.
Page: 49
Design Patterns
Some design patterns can be very
important or pale to insignificance due
to language that we use.
Page: 50
Design Patterns
Design patterns can be categorized
further.
Page: 51
But first let us discuss about the last
category of pattern.
Page: 52
Architectural Patterns
Page: 53
Architectural Patterns
Architectural patterns on the other
hand, are commonalities at higher level
than design patterns.
Page: 54
Architectural Patterns
Architectural patterns are high level
strategies.
Page: 55
Architectural Patterns
Architectural patterns concerns:
Large-scale components
Global properties
Mechanism of a system
Page: 56
Architectural Patterns
One of the most well-known
architectural pattern is the MVC
architecture.
Page: 57
MVC Architecture
MVC intents are to promote efficient
code reuse and parallel development.
Page: 58
MVC Architecture
Page: 59
MVC Architecture
It tries to solve the problem of tightly-
coupled relation between UI codes and
logic that hinders reusability.
Page: 60
MVC Architecture
It does so by separating codes into
three concerns: models, views and
controllers.
Page: 61
MVC Architecture
Notice that we already discuss about
the name, intent, sketch, problem and
solution provided by a pattern.
Page: 62
Design Patterns Categories
Page: 63
Design Patterns Categories
In arguably the most influential book
on design patterns (The GoF book),
Page: 64
Design Patterns Categories
Page: 65
Design Patterns Categories
the authors categorize design patterns
into three categories
Creational
Structural
Behavioural
Page: 66
Creational Patterns
Page: 67
Creational Patterns
Creational patterns concern about
object creation.
Page: 68
Creational Patterns
It abstract the instantiation process.
Page: 69
Creational Patterns
They help make a system independent
on how its objects are created,
composed and represented.
Page: 70
Creational Patterns
Useful when creating objects with
particular behaviour requires more
than simply instantiation a class.
Page: 71
Creational Patterns
Favour system that prefer to use
object composition instead of class
inheritance.
Page: 72
Creational Patterns
Example: Abstract Factory
Page: 73
Abstract Factory
Provide an interface for creating
families of related or dependent
objects without specifying their
concrete class.
Page: 75
Structural Patterns
Page: 76
Structural Patterns
Structural patterns deal with the
compositions of classes or objects to
form larger structures.
Page: 77
Structural Patterns
Example: Adapter
Page: 78
Adapter
Convert the interface of a class into
another interface clients expect.
Page: 79
Adapter
Adapter lets classes work together
that couldn't otherwise because of
incompatible interfaces.
Page: 81
Behavioural Patterns
Page: 82
Behavioural Patterns
Behavioural patterns characterize the
way in which classes or objects
interact and distribute responsibility.
Page: 83
Behavioural Patterns
Not just patterns of classes and
objects but also the patterns of
communication between them.
Page: 84
Behavioural Patterns
Example: Observer or Pub-Sub
Page: 85
Observer
Define one-to-many dependency
between objects.
Page: 86
Observer
When one object change state, all its
dependents are notified and updated
automatically.
Page: 88
Design Patterns Categories
There are no limits in defining design
pattern categories, what we just
discussed is just a (famous) example.
Page: 89
How to Utilize Patterns Properly?
Page: 90
Utilizing Patterns
Consider how patterns solve the
problems
Page: 91
Utilizing Patterns
Scan intent and sketch sections
Page: 92
Utilizing Patterns
Study how patterns relate with each
other
Page: 93
Utilizing Patterns
Study patterns of like purpose
Page: 94
Utilizing Patterns
Examine a cause of redesign
Page: 95
Utilizing Patterns
Consider what should be variable in
your design
Page: 97
Anti-patterns
There are also patterns that have
negative consequences when it is
present in our software
Page: 98
Anti-patterns
It is called the anti-patterns
Page: 99
Anti-patterns
Anti-patterns are common response
to a recurring problem that is usually
ineffective and risks being highly
counterproductive.
Page: 100
Anti-patterns
Example: Big ball of mud
Page: 101
Big ball of mud
Software system that lacks a
perceivable architecture.
Page: 102
Big ball of mud
Although undesirable from a software
engineering PoV, such systems are
common in practice.
Page: 103
Big ball of mud
Due to business pressure, developers
turnover and code entropy.
