design patterns: back to basics
TRANSCRIPT
![Page 1: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/1.jpg)
PRINCIPLES AND PATTERNS OF
SOFTWARE DESIGNJune 15, 2015Paulo Sousa
Back to the basics
![Page 2: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/2.jpg)
2ISEP/IPP
![Page 3: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/3.jpg)
3
![Page 4: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/4.jpg)
![Page 5: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/5.jpg)
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
![Page 6: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/6.jpg)
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.
![Page 7: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/7.jpg)
“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
![Page 8: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/8.jpg)
“At this final stage [...] the patterns aren’t important. The forces in the problem
domain and how to resolve them are.”
![Page 9: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/9.jpg)
PrinciplesCore object-oriented design principles
![Page 10: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/10.jpg)
EncapsulationGroup data and behavior on that data together.
10
![Page 11: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/11.jpg)
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.
![Page 12: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/12.jpg)
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
![Page 13: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/13.jpg)
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.
![Page 14: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/14.jpg)
14
Tell, don’t askProcedural code gets information then makes decisions. Object-oriented code tells objects to do things.
— Alec Sharp
![Page 15: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/15.jpg)
15ISEP/IPP
![Page 16: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/16.jpg)
16ISEP/IPP
![Page 17: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/17.jpg)
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)
![Page 18: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/18.jpg)
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.
![Page 19: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/19.jpg)
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()
![Page 20: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/20.jpg)
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.
![Page 21: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/21.jpg)
21
Intention Revealing Interfaceinterface ISapService {double getHourlyRate(int sapID);}
vs.
interface IPayrollService {double getHourlyRate(Employee e);}
![Page 22: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/22.jpg)
22ISEP/IPP
Closings
![Page 23: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/23.jpg)
Key Principles Information hiding ≠ encapsulation Getter and setter mentality is wrong-doing Tell, don’t ask Avoid anemic domain model Provide intention revealing interfaces
![Page 24: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/24.jpg)
References
![Page 25: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/25.jpg)
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.
![Page 26: Design Patterns: Back to Basics](https://reader035.vdocuments.mx/reader035/viewer/2022070522/58edf55b1a28ab50618b46d1/html5/thumbnails/26.jpg)
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