Design Patterns: From STUPID to SOLID code
-
Upload
paulo-gandra-de-sousa -
Category
Technology
-
view
1.673 -
download
0
Transcript of Design Patterns: From STUPID to SOLID code
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.