1. Patterns…
A primer Overview
(… Only design patterns?...)

2. Pattern (Classic definition)
• A design pattern is a solution to a general design problem in the
form of a set of interacting classes that have to be customized to
create a specific design.
• Patterns and Pattern Languages are ways to describe best practices,
good designs, and capture experience in a way that it is possible for
others to reuse this experience (Hillside Group).
• A Pattern is a way to capture recurring designs in such a way that
others can readily acquire and use the knowledge and experience
(Erich Gamma)

3. Christopher Alexander - 1979…
• As an element in the world, each pattern is a relationship between
a certain context, a certain system of forces, which occurs
repeatedly in that context, and a certain spatial configuration,
which allows these to resolve themselves.
• As an element of language, a pattern is an instruction, which
shows how this spatial configuration can be used, over and
over again, to resolve the given system of forces, wherever the
context makes it relevant.
• The pattern is, in short, at the same time a thing, which happens in
the world, and the rule which tells us how to create that thing,
and when we must create it. It is both a process and a thing; both a
description of a thing which is alive, and a description of the process
which will generate that thing.

4. Pressman
• For software design, context allows the reader to
understand the environment in which the problem resides
and what solution might be appropriate within that
environment.
• A set of requirements, including limitations and
constraints, acts as a system of forces that influences
how the problem can be interpreted within its context and
how the solution can be effectively applied.

5. Design patterns give us templates!
Pressman, Roger S. Software engineering : a practitioner’s approach, Chapter 12.

6. Design patterns are grouped into categories
(From Pressman)
• Creational patterns focus on the “creation, composition,
and representation” of objects.
• Structural patterns focus on problems and solutions
associated with how classes and objects are organized
and integrated to build a larger structure.
• Behavioral patterns address problems associated with the
assignment of responsibility between objects and the
manner in which communication is effected between
objects.

7. Design patterns are grouped into categories
(From Pressman)

8. Design patterns are grouped into categories
Schach, Stephen
R. Object-Oriented
and Classical
Software
Engineering

9. An example
Sommerville, Ian.
SOFTWARE
ENGINEERING

10. Weaknesses of Design Patterns
(From Schach - Object-Oriented and Classical Software Engineering)
1.A major problem is that there is as yet no systematic way to determine
when and how to apply design patterns.
2.The use of the 23 standard design patterns in a software product may be
an indication that the language we are using is not powerful enough.
3.To obtain maximal benefit from design patterns, multiple interacting
patterns are employed. We do not yet have a systematic way of
knowing when and how to use one pattern, let alone multiple
interacting patterns.
4.When performing maintenance on a software product built using the
classical paradigm, it is essentially impossible to retrofit classes and
objects. It is similarly all but impossible to retrofit patterns to an existing
software product, whether classical or object oriented.
Retrofitting= addition of new technology or features to older systems

11. Weaknesses of Design Patterns
See http://blog.codinghorror.com/head-first-design-patterns/

12. Strengths of Design Patterns
(From Schach - Object-Oriented and Classical Software Engineering)
1.Design patterns promote reuse by solving a general
design problem. The reusability of a design pattern can be
enhanced by careful incorporation of features that can be
used to further enhance reuse, such as inheritance.
2.A design pattern provides high-level documentation of the
design, because patterns specify design abstractions.
3.Implementations of many design patterns exist. In such
cases, there is no need to code or document those parts of a
program that implement design patterns. (Testing of those
parts of the program is still essential, of course.)

13. Strengths of Design Patterns
(From Schach - Object-Oriented and Classical Software Engineering)
4. If a maintenance programmer is familiar with design
patterns, it will be easier to comprehend a program that
incorporates design patterns, even if he or she has never
seen that specific program before.
5. Research into automated detection of design patterns is
starting to produce results.

14. Design in Context (Pressman)
Most representative
question
(systematic way)

15. Design in Context (Shalloway & Trott approach)
In Design Patterns Explained (2005), Shalloway, A., and J. Trott suggest the
following approach that enables a designer to think in patterns:
1. Be sure you understand the big picture—the context in which the
software to be built resides. The requirements model should
communicate this to you.
2. Examining the big picture, extract the patterns that are present
at that level of abstraction.
3. Begin your design with “big picture” patterns that establish a context
or skeleton for further design work.
4. “Work inward from the context” looking for patterns at lower
levels of abstraction that contribute to the design solution.
5. Repeat steps 1 to 4 until the complete design is fleshed out.
6. Refine the design by adapting each pattern to the specifics of the
software you’re trying to build.

16. Pattern’s Table (Microsoft & Pressman)
Pressman, Roger S.
Software engineering : a
practitioner’s approach,
Chapter 12.
&
Microsoft, “Prescriptive
Architecture: Integration
and Patterns,” MSDN, May
2004, available at
http://msdn2.microsoft.com
/en-
us/library/ms978700.aspx.

17. Patterns & Abstraction
• Architecture Patterns.
• Business Patterns,
• Analysis Patterns.
• Data Patterns.
• SOA Patterns.
• UI Patterns.
• Implementation Patterns.
• Process Patterns
• …
Tree’ Source: http://aojajena.wordpress.com/tag/abstraction-level/

18. Some repositories
• The Hillside Group http://hillside.net/patterns/
• Portland Pattern Repository http://c2.com/ppr/index.html
• Pattern Index http://c2.com/cgi/wiki?PatternIndex
• UI Patterns Collections UI/HCI Patterns http://www.hcipatterns.org/tiki-
index.php
• Jennifer Tidwell’s UI patterns www.time-tripper.com/uipatterns/
• Mobile UI Design Patterns http://mobile-patterns.com/
• Pattern Language for UI Design
www.maplefish.com/todd/papers/Experiences.html
• UI Design Patterns www.cs.helsinki.fi/u/salaakso/patterns/

19. Specialized Design Patterns
• Aircraft Avionics http://g.oswego.edu/dl/acs/acs/acs.html
• Business Information Systems
www.objectarchitects.de/arcus/cookbook/
• Distributed Processing www.cs.wustl.edu/~schmidt/
• IBM Patterns for e-Business
http://www.ibm.com/developerworks/patterns/
• Yahoo! Design Pattern Library http://developer.yahoo.com/ypatterns/
• MSDN Library patterns & practices
http://msdn.microsoft.com/en-us/library/ff921345.aspx

20. Don’t forget the Antipatterns X-(
Whereas patterns describe a recurring problem
and its solution, antipatterns describe solutions
that have more negative consequences than
positive benefits. In effect, they describe
dysfunctional approaches to problem solving,
followed by the changes that should be made to
overcome this dysfunction.
Source: Phillip A. Laplante & Colin J. Neill. ANTIPATTERNS - Identification,
Refactoring, and Management. CRC Press, 2007.
See more in: http://www.antipatterns.com/briefing/index.htm

21. Paul Graham on Design Patterns
For example, in the OO world you hear a good deal about
“patterns”. I wonder if these patterns are not sometimes
evidence of case (c), the human compiler, at work. When I
see patterns in my programs, I consider it a sign of
trouble. The shape of a program should reflect only the
problem it needs to solve. Any other regularity in the code
is a sign, to me at least, that I’m using abstractions that
aren’t powerful enough— often that I’m generating by hand
the expansions of some macro that I need to write.
Paul Graham http://www.paulgraham.com/icad.html

22. For awakening
(From Paolo Ciancarini)
You are enhancing an existing application in a pizza shop.
The price of the pizza depends on the options selected by
the user. Each option carries a different additional price.
There are a large number of options available (ex: extra
cheese, type of crust, toppings and so on). Which is the
best pattern for design this context? Why?

23. For awakening
(From http://www.pm.inf.ethz.ch/education/courses/kse/archive/2011/exercises/DesignPatterns.pdf)
We want to implement a text paragraph. A paragraph is a sequence of lines. Each line is represented
by a string. The Paragraph class has to provide at least the
following methods:
List<String> alignedText(); // Returns the list of formatted lines in the paragraph.
String getLine(int i ); // Returns the line at the ith position .
int getCountLines(); // Returns the number of lines in the paragraph.
void addLine(String s); // Appends a line to the paragraph.
The formatting algorithm (e.g., left-align or centered) can be selected at runtime. It also has to be
possible to add new formatting algorithms to the program without
modifying the Paragraph class.
Your task: Develop a design for Paragraph that satisfies the above requirements.
Which design pattern could you use?

24. For awakening
(From http://www.pm.inf.ethz.ch/education/courses/kse/archive/2011/exercises/DesignPatterns.pdf)
• We want to extend our design by a character counter. This counter is a separate object that stores
the number of characters in a Paragraph object. Whenever the Paragraph object is changed, the
counter has to be adapted automatically.
Your task: Develop a design for the counter. You are allowed to modify the Paragraph
Which design pattern could you use?
• Also, you must consider the support for Ctrl + Z command, which go back the Paragraph Object to
the previous state (previous content)
Which design pattern could you use?

25. Reuse implies
• Frameworks
• Software product lines
• Languages and patterns (see
http://www.slideshare.net/jcabot/improving-software-
languages-via-bottom-up-
patterns?referrer=ssid%3D50788080%26action%3Dview%26e
xp%3Dweb)
• And moreeeee

26. Thanks for your attention
fdgiraldo@uniquindio.edu.co