design patterns: back to basics
TRANSCRIPT
PRINCIPLES AND PATTERNS OF
SOFTWARE DESIGNJune 15, 2015Paulo Sousa
Back to the basics
2ISEP/IPP
3
A building or a town will only be alive to the extent that is governed by the timeless way. It is a process which brings order out of nothing but ourselves; it cannot be attained, but it will happen of its own accord, if we will only let it.To seek the timeless way we must first know the quality without a name. To reach the quality without a name we must then build a living pattern language as a gate.Once we have built the gate, we can pass through it to the practice of the timeless way. And yet the timeless way is not complete, and will not fully generate the quality without a name, until we leave the gate behind.
“The timeless Way of Building” (1979) Christopher Alexander
Each pattern describes a problem that occurs over and over again in our environment and then describes the core of the solution to that problem in such a way that you can use this solution a million times over without ever doing it the same way twice.
“A Software Design Pattern names, abstracts, and
identifies the key aspects of a common design structure
that make it useful for creating a reusable object-
oriented design.”Design Patterns-Elements of Reusable
Object-oriented Software, Gamma et al. (Gang of Four)
1995
“A particular recurring design problem that arises in specific design contexts,
and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing its
constituent components, their responsibilities and relationships, and
the ways in which they collaborate”
Pattern Oriented Software Architecture, volume 1Bushman et al. 1996
“At this final stage [...] the patterns aren’t important. The forces in the problem
domain and how to resolve them are.”
PrinciplesCore object-oriented design principles
EncapsulationGroup data and behavior on that data together.
10
11
Information HidingSegregation of the design decisions that are most likely to change, thus protecting other parts from extensive modification if the design decision is changed.
12
What’s wrong with this code?class Employee {
private int number;private double salary;private ArrayList skil = new ArrayList<String>;
...public int getNumber() { … }public void setNumber(int n) { … }public double getSalary() { … }public setSalary(double s) { … }public ArrayList getSkills() { … }public void setSkills(ArrayList s) { … }
}
Getters and setters are EVIL
13
Anemic Domain ModelProcedural thinking where Objects are just Plain data structures devoid of any behaviour, and behaviour is concentrated in “service” and “controller” classes.
14
Tell, don’t askProcedural code gets information then makes decisions. Object-oriented code tells objects to do things.
— Alec Sharp
15ISEP/IPP
16ISEP/IPP
17
Don’t talk to strangersAny method of an object should only call methods belonging to:• itself.• any parameters that were passed in to the method.• any objects it created.• any composite objects.
(a.k.a. The Law of Demeter)
18
Objects are allways in a valid stateAn object cannot be constructed neither modified in a way that it does not hold its internal consistency.
19ISEP/IPP
Replace “set” sintax with strong names• setFirstName(string fn)• setLastName(string ln)
vs.
• changeName(string first,
string last)
• setStatus(STATUS st)• getStatus()
vs.
• activate()• deactivate()• isActive()
20
Intention Revealing InterfaceName classes and operations to describe their effect and purpose, without reference to the means by which they do what they promise.
21
Intention Revealing Interfaceinterface ISapService {double getHourlyRate(int sapID);}
vs.
interface IPayrollService {double getHourlyRate(Employee e);}
22ISEP/IPP
Closings
Key Principles Information hiding ≠ encapsulation Getter and setter mentality is wrong-doing Tell, don’t ask Avoid anemic domain model Provide intention revealing interfaces
References
Bibliography• Christopher Alexander (1979) The timeless way of
building• Erich Gamma, Richard Helm, Ralph Johnson, John
Vissides. Design patterns : elements of reusable object-oriented software. Adisson-Wesley. • Frank Buschmann, Regine Meunier, Hans Rohnert,
Peter Sommerlad, Michael Stal. Pattern-oriented Software Architecture: System of Patterns.
Bibliography• Anemic Domain Model. Martin Fowler.
http://martinfowler.com/bliki/AnemicDomainModel.html • Why getter and setter methods are evil . Allen
Holub http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html • Tell, don’t ask. The Pragmatic Programmers.
https://pragprog.com/articles/tell-dont-ask