design patterns: back to basics

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