PRINCIPLES AND PATTERNS OF

SOFTWARE DESIGNJune 29, 2015Paulo Sousa

Make yor code solid, not stupid

Singleton

Tight coupling

Untestable

Premature optimization

Indescriptive Naming

Duplication

3

Code smellsSigns that the code is rotten and should be refactored

We’ll get back to this

Single Responsibility Principle

Open/Close

Liskov Substitution Principle

Interface Segregation

Dependency Inversion

Single Responsibility PrincipleA class should have only one reason to change.

5

6

Single Responsibility Principle

7

changeName(first, last)changeAddress(street, zip)

first: stringlast:stringstreet: stringzip: stringemail:string

Person

changeName(first, last)changeAddress(address)

first: stringlast:stringemail:string

Person

changeAddress(street, zip)

street: stringzip: string

Address

The domain, SRP and Value ObjectsPrimitive types are not the best option to represent domain concepts!Favour imutability of your objects.

8

Person«value»Name

«value»Address

«value»NIF

«value»PhoneNumber

1..*1

1 *«value»Email

*

Open/Close PrincipleA module should be open for extension but closed for modification.

9

10

What would you choose to protect yourself from the sun?

• Brain surgery to implant sun-resisting hair and skin, or

• Put on a hat?

11

Polymorphism

12ISEP/IPP

Template MethodDefine an overall algorithm structure while allowing for certain operations (steps) to be tailored for concrete cases

StrategyProvide different implementations of the same algorithm and allow the client to choose which one to use.

source: Design Patterns: Elements of Reusable Object-Oriented Software

DecoratorDynamically attach additional responsibilities to an object. Decorators provide a flexible alternative to subclassing for extending functionality.

source: Design Patterns: Elements of Reusable Object-Oriented Software

VisitorSeparate the algorithm from the data structure it operates on by creating a visitor that traverses the desired object.

Source: http://www.oodesign.com/visitor-pattern.html

Liskov Substitution PrincipleSubclasses should be substitutable for their base classes.

16

The implication is:Subclasses must abide the

same contract and invariants of the base class, without

semantic changes.

17

The circle/elipse dilemma

18

The circle/ellipse dilemmaLiskov Substitution principleSubclasses should expect no more and provide no less.

Interface Seggregation PrincipleMany client specific interfaces are better than one general purpose interface.

19

20

Interface Seggregation Principle

21

Interface Seggregation Principle

Dependency Inversion PrincipleDepend upon Abstractions. Do not depend upon concretions.

22

23

Dependency Inversion Principle

24

Dependency InjectionModules declare their dependencies but do not create them explicitily

class Component {NeededService svc;

Component() {svc = new ServiceImplementation();

}}

class Component {NeededService svc;

Component(NeededService impl) {svc = impl;

}}

Separated InterfaceDefines an interface in a separate package from its implementation.

source: Patterns of Enterprise Application Architecture

26ISEP/IPP

Closings

Key Principles Consider what should be variable in your design Program to an interface not an implementation Keep different responsibilities apart from each

other Favour composition instead of inheritance

References

Bibliography• Robert C. Martin. Design Principles and Design Patterns. http://

www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

• William Durand. From STUPID to SOLID code!. http://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/

• Allen Holub. Why extends is evil. http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

• Erich Gamma, Richard Helm, Ralph Johnson, John Vissides. Design patterns : elements of reusable object-oriented software. Adisson-Wesley.