design patterns: from stupid to solid code
TRANSCRIPT
![Page 1: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/1.jpg)
PRINCIPLES AND PATTERNS OF
SOFTWARE DESIGNJune 29, 2015Paulo Sousa
Make yor code solid, not stupid
![Page 2: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/2.jpg)
Singleton
Tight coupling
Untestable
Premature optimization
Indescriptive Naming
Duplication
![Page 3: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/3.jpg)
3
Code smellsSigns that the code is rotten and should be refactored
We’ll get back to this
![Page 4: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/4.jpg)
Single Responsibility Principle
Open/Close
Liskov Substitution Principle
Interface Segregation
Dependency Inversion
![Page 5: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/5.jpg)
Single Responsibility PrincipleA class should have only one reason to change.
5
![Page 6: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/6.jpg)
6
![Page 7: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/7.jpg)
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
![Page 8: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/8.jpg)
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
*
![Page 9: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/9.jpg)
Open/Close PrincipleA module should be open for extension but closed for modification.
9
![Page 10: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/10.jpg)
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?
![Page 11: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/11.jpg)
11
Polymorphism
![Page 12: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/12.jpg)
12ISEP/IPP
Template MethodDefine an overall algorithm structure while allowing for certain operations (steps) to be tailored for concrete cases
![Page 13: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/13.jpg)
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
![Page 14: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/14.jpg)
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
![Page 15: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/15.jpg)
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
![Page 16: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/16.jpg)
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.
![Page 17: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/17.jpg)
17
The circle/elipse dilemma
![Page 18: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/18.jpg)
18
The circle/ellipse dilemmaLiskov Substitution principleSubclasses should expect no more and provide no less.
![Page 19: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/19.jpg)
Interface Seggregation PrincipleMany client specific interfaces are better than one general purpose interface.
19
![Page 20: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/20.jpg)
20
Interface Seggregation Principle
![Page 21: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/21.jpg)
21
Interface Seggregation Principle
![Page 22: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/22.jpg)
Dependency Inversion PrincipleDepend upon Abstractions. Do not depend upon concretions.
22
![Page 23: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/23.jpg)
23
Dependency Inversion Principle
![Page 24: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/24.jpg)
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;
}}
![Page 25: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/25.jpg)
Separated InterfaceDefines an interface in a separate package from its implementation.
source: Patterns of Enterprise Application Architecture
![Page 26: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/26.jpg)
26ISEP/IPP
Closings
![Page 27: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/27.jpg)
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
![Page 28: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/28.jpg)
References
![Page 29: Design Patterns: From STUPID to SOLID code](https://reader034.vdocuments.mx/reader034/viewer/2022051300/58edf5671a28ab8c708b45bb/html5/thumbnails/29.jpg)
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.