CSE351 DESIGN PATTERNS

10. BETTER LIVING WITH PATTERNS

Patterns In The Real World
Ahhhh, now you’re ready for a
bright new world filled with
Design Patterns.
The Objectville Guide to Please accept our handy guide with tips & tricks for
Better Living with Design Patterns living with patterns in the real world.

✓Learn the all-too-common misconceptions about the definition of a “Design Pattern.”

✓Discover those nifty Design Pattern Catalogs and why you just have to get one.
✓Avoid the embarrassment of using a Design Pattern at the wrong time.
✓Learn how to keep patterns in classifications where they belong.
✓See that discovering patterns isn’t just for the gurus; read our quick HowTo and become a
patterns writer too.
✓Be there when the true identity of the mysterious Gang of Four is revealed.
✓Keep up with the neighbors – the coffee table books any patterns user must own.
✓Learn to train your mind like a Zen master.
✓Win friends and influence developers by improving your patterns vocabulary.
2
Design Pattern defined
A Pattern is a solution to a problem in a context.

The context is the situation in which the pattern applies.

This should be a recurring situation.

The problem refers to the goal you are trying to

achieve in this context, but it also refers to any
constraints that occur in the context.

The solution is what you’re after: a general design

that anyone can apply which resolves the goal and set
of constraints.

3
This definition takes a while to sink in …
Here’s a little mnemonic you can repeat to yourself to remember it:
“If you find yourself in a context with a problem that has a
goal that is affected by a set of constraints, then you can
apply a design that resolves the goal and constraints and
leads to a solution.”

After all, you already know that a Design Pattern gives you a
solution to a common recurring design problem.
What is all this formality getting you?

we can create a catalog of patterns,

which has all kinds of benefits. -->
4
You might be right; let’s think about this a bit...
We need a problem, a solution and a context:
Problem: How do I get to work on time?
Context: I’ve locked my keys in the car.
Solution: Break the window, get in the car, start the engine and drive to work.
We have all the components of the definition:
▪ we have a problem, which includes the goal of getting to work, and the
constraints of time, distance and probably some other factors.
▪ we also have a context in which the keys to the car are inaccessible.
▪ and we have a solution that gets us to the keys and resolves both the time and
distance constraints.
We must have a pattern now! Right?
5
Looking more closely at the
Design Pattern definition
Our example does seem to match the Design Pattern definition,
but it isn’t a true pattern. Why?
1. For starters, we know that a pattern needs to apply to a
recurring problem.
▪ While an absent-minded person might lock his keys in
the car often, breaking the car window doesn’t qualify
as a solution that can be applied over and over (or at
least isn’t likely to if we balance the goal with another
constraint: cost).
2. It isn’t easy to take this description, hand it to someone
and have him apply it to his own unique problem.
3. We’ve violated an important but simple aspect of a pattern:
we haven’t even given it a name!
▪ Without a name, the pattern doesn’t become part of a
vocabulary that can be shared with other developers it We have much better ways of
isn’t easy to take this description, hand it to someone
and have him apply it to his own unique problem.
describing patterns and collecting
them together into patterns catalogs.
-->
6
 May the force be with you
The Design Pattern
definition tells us that
the problem consists of
a goal and a set of constraints.
Patterns gurus have a term for these:
they call them forces. Why? Well, we’re sure they
have their own reasons, but if you remember the movie,
the force “shapes and controls the Universe.”
Likewise, the forces in the pattern definition shape and control
the solution. Only when a solution balances both sides of the force
(the light side: your goal, and the dark side: the constraints) do we have a useful pattern.

This “force” terminology can be quite confusing when you first see it in
pattern discussions, but just remember that there are two sides of the force
(goals and constraints) and that they need to be balanced or resolved to create a pattern solution.
Don’t let the lingo get in your way and may the force be with you!
7
P
A
T C
T A
E T
R A
N L
O
G
U
E
S
8
9
Organizing Design Patterns Sharpen your pencil
The most well-known scheme was used by the
Adapter Factory Method first pattern catalog and partitions patterns into three
Abstract Factory State
Iterator Strategy distinct categories based on their purposes:
Observer Command Decorator
Template Method Creational, Behavioral and Structural.
Composite Singleton
Facade
Creational patterns involve
Any pattern that is a Behavioral
object instantiation and all
Pattern is concerned with how
provide a way to decouple a client
classes and objects interact and
from the objects it needs to
distribute responsibility.
instantiate.

Structural patterns let you

compose classes or objects
into larger structures.
10
Patterns are often classified by a second attribute:
whether or not the pattern deals with classes or objects:
Object patterns describe relationships
Class patterns describe how relationships between objects and are primarily
between classes are defined via defined by composition. Relationships
inheritance. Relationships in in object patterns are typically
class patterns are created at runtime and are more
established at compile time. dynamic and flexible.

Adapter Factory Method

Abstract Factory State
Iterator Strategy
Observer Command Decorator
Composite Singleton Template Method
11
Thinking in Patterns
Keep it simple (KISS)
▪ Your goal should be simplicity, not “how can I apply a pattern to this problem.”
▪ Appreciate and admire the simplicity of your design
▪ Sometimes the best way to keep your design simple and flexible is to use a pattern

Design Patterns aren’t a magic bullet; in fact they’re not even a bullet!
▪ Patterns are general solutions to recurring problems and have the benefit of being well tested by lots of developers.
▪ However, patterns aren’t a magic bullet. You also need to think through the consequences on the rest of your design.

You know you need a pattern when...

▪ If a simpler solution might work, give that consideration before you commit to using a pattern.
▪ Knowing when a pattern applies is where your experience and knowledge come in.
▪ If a simple solution will not meet your needs, consider using a pattern along with the constraints under which the solution will operate
▪ The intent and applicability sections of the patterns catalogs are particularly useful for this
▪ There is one situation to use a pattern even if a simpler solution would work: when you expect aspects of your system to vary.
▪ Just make sure you are adding patterns to deal with practical change that is likely to happen, not hypothetical change that may happen.
▪ You might use patterns at design time and refactoring time.

12
Thinking in Patterns
Refactoring time is Patterns time!
▪ Refactoring is the process of making changes to your code to improve the way it is organized.
▪ not to change its behavior
▪ For instance, clear code with full of conditional statements with the State pattern or concrete dependencies with a Factory.

Take out what you don’t really need. Don’t be afraid to remove a Design Pattern from your design.
▪ So when do you remove a pattern? When your system has become complex and the flexibility you planned for isn’t needed.
▪ In other words, when a simpler solution without the pattern would be better.

If you don’t need it now, don’t do it now.

▪ If you have a practical need to support change in a design today, go ahead and employ a pattern to handle
that change.
▪ if the reason is only hypothetical, don’t add the pattern, it is only going to add complexity to your system,
and you might never need it!

13
Your Mind on Patterns
The Beginner uses patterns everywhere.
This is good: the beginner gets lots of
experience with and practice using As learning progresses, the Intermediate mind
patterns. The beginner also thinks, starts to see where patterns are needed and
“The more patterns I use, the better the design.” where they aren’t.
Complexity and patterns should only be The intermediate mind still tries to fit too
used for practical extensibility. many square patterns into round holes, but
also begins to see that patterns can be
adapted to fit situations where the canonical
The Zen mind is able to see patterns where they fit pattern doesn’t fit.
naturally.
The Zen mind looks for simple solutions that best
solve the problem. The Zen mind thinks in terms of
the object principles and their trade-offs. The Zen
mind also sees relationships to similar patterns
and understands the subtleties of differences in
the intent of related patterns. The Zen mind is also
a Beginner mind — it doesn’t let all that pattern
knowledge overly influence design decisions.

14
when not to use patterns

Of course we want you to use Design Patterns!

But we want you to be a good OO designer even more.

When a design solution calls for a pattern, you get the benefits of using a solution that has been
time tested by lots of developers (you know, that whole shared vocabulary thing).

However, when you use Design Patterns, there can also be a downside.
Patterns often introduce additional classes and objects, and they increase the complexity.
Patterns can also add more layers to your design, which also adds inefficiency.

Many times you can fall back on your design principles and find a much simpler solution.
If that happens, don’t fight it.
Use the simpler solution.
15
Don’t forget the power of the SHARED VOCABULARY
▪ Don’t underestimate the power of a shared
vocabulary, it’s one of the biggest benefits of
Patterns.
▪ Just think, since the last time we talked about
shared vocabularies; you’ve now started to build up
quite a vocabulary of your own!
▪ Not to mention, you have also learned a full set of
OO design principles from which you can easily
understand the motivation and workings of any
new patterns you encounter.
▪ Now spread the word to others. Why?
Because when your fellow developers know patterns and
use a shared vocabulary as well, it leads to better designs,
better communication and, best of all, it’ll save you a lot of
time that you can spend on cooler things.

16
Top five ways to share your vocabulary
1. In design meetings emretanriverdi.medium.com
Use design patterns to help stay “in the design” longer. Discussing designs from the perspective of Design Patterns and OO
principles keeps your team from getting bogged down in implementation details and prevent many misunderstandings.

2. With other developers

Use patterns in your discussions with other developers. This helps other developers learn about new patterns and builds a
community. The best part about sharing what you’ve learned is that great feeling when someone else “gets it!”
3. In architecture documentation
Using patterns will reduce the amount of documentation you need to
write and gives the reader a clearer picture of the design.
4. In code comments and naming conventions
When you’re writing code, clearly identify the patterns you’re using in
comments. Also, choose class and methods names that reveal any patterns underneath.
5. To groups of interested developers
Volunteer to give a brown-bag lunch on patterns or a talk at your local user group.
17
Annihilating evil with Anti-Patterns
A Design Pattern gives you a general solution to a recurring problem in a particular
context, what does an anti-pattern give you?

An Anti-Pattern tells you how to go from a problem

to a BAD solution.

Why on earth would anyone waste their time documenting bad solutions?
▪ if there is a recurring bad solution to a common problem, then by documenting it
we can prevent other developers from making the same mistake. After all,
avoiding bad solutions can be just as valuable as finding good ones!

Let’s look at the elements of an anti-pattern:

▪ An anti-pattern tells you why a bad solution is attractive.
▪ An anti-pattern tells you why that solution in the long term is bad.
▪ An anti-pattern suggests other patterns that are applicable which
may provide good solutions.
18
19
CSE351 THE END
LEAVING?
BOYS AND GIRLS
IT’S BEEN GREAT
HAVING YOU HERE WITH ME.
Tools for your Design Toolbox
Bullet Points
▪ Let Design Patterns emerge in your designs, don’t force them in
just for the sake of using a pattern.
▪ Design Patterns aren’t set in stone; adapt and tweak them to
meet your needs.
▪ Always use the simplest solution that meets your needs, even if it
doesn’t include a pattern.
▪ Study Design Pattern catalogs to familiarize yourself with
patterns and the relationships among them.
▪ Pattern classifications (or categories) provide groupings for
patterns. When they help, use them.
▪ You need to be committed to be a patterns writer: it takes time
and patience, and you have to be willing to do lots of refinement.
▪ Remember, most patterns you encounter will be adaptations of
existing patterns, not new patterns.
▪ Build your team’s shared vocabulary. This is one of the most
powerful benefits of using patterns.
▪ Like any community, the patterns community has its own lingo.
Don’t let that hold you back. Having read this book, you now
know most of it. 21