SlideShare a Scribd company logo
PRINCIPLES AND PATTERNS
OF
SOFTWARE DESIGN
June 29, 2015
Paulo Sousa
Singleton
Tight coupling
Untestable
Premature optimization
Indescriptive Naming
Duplication
Code smells
Signs that the code is rotten and should be refactored
2
Single Responsibility Principle
Open/Close
Liskov Substitution Principle
Interface Segregation
Dependency Inversion
Single Responsibility Principle
A class should have only one reason to change.
4
5
Single Responsibility Principle
6
changeName(first, last)
changeAddress(street, zip)
first: string
last:string
street: string
zip: string
email:string
Person
changeName(first, last)
changeAddress(address)
first: string
last:string
email:string
Person
changeAddress(street, zip)
street: string
zip: string
Address
The domain, SRP and Value Objects
Primitive types are not the best option to represent
domain concepts!
Favour imutability of your objects.
7
Person
«value»
Name
«value»
Address
«value»
NIF
«value»
PhoneNumber
1..*1
1 *
«value»
Email
*
Open/Close Principle
A module should be open for extension but closed for
modification.
8
What would you choose to protect yourself from the
sun?
• Brain surgery to implant sun-resisting hair and
skin, or
• Put on a hat?
9
Polymorphism
10
Template Method
Define an overall
algorithm structure while
allowing for certain
operations (steps) to be
tailored for concrete
cases
11
Strategy
Provide 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
Decorator
Dynamically 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
Visitor
Separate 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 Principle
Subclasses should be substitutable for their base
classes.
15
The implication is:
Subclasses must abide the
same contract and invariants
of the base class, without
semantic changes.
The circle/elipse dilemma
16
The circle/ellipse dilemma
17
Interface Seggregation Principle
Many client specific interfaces are better than one
general purpose interface.
18
Interface Seggregation Principle
19
Interface Seggregation Principle
20
Dependency Inversion Principle
Depend upon Abstractions. Do not depend upon
concretions.
21
Dependency Inversion Principle
22
Dependency Injection
Modules declare their dependencies but do not
create them explicitily
23
class Component {
NeededService svc;
Component() {
svc = new ServiceImplementation();
}
}
class Component {
NeededService svc;
Component(NeededService impl) {
svc = impl;
}
}
Separated Interface
Defines an interface in a
separate package from
its implementation.
source: Patterns of Enterprise Application Architecture
Closings
25
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/Princ
iples_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.

More Related Content

What's hot

Geecon09: SOLID Design Principles
Geecon09: SOLID Design PrinciplesGeecon09: SOLID Design Principles
Geecon09: SOLID Design PrinciplesBruno Bossola
 
SOLID Design Principles
SOLID Design PrinciplesSOLID Design Principles
SOLID Design PrinciplesSamuel Breed
 
Single Responsibility Principle
Single Responsibility PrincipleSingle Responsibility Principle
Single Responsibility PrincipleEyal Golan
 
Solid design principles
Solid design principlesSolid design principles
Solid design principlesMahmoud Asadi
 
Java 8 Lambda Built-in Functional Interfaces
Java 8 Lambda Built-in Functional InterfacesJava 8 Lambda Built-in Functional Interfaces
Java 8 Lambda Built-in Functional InterfacesGanesh Samarthyam
 
Clean architecture - Protecting the Domain
Clean architecture - Protecting the DomainClean architecture - Protecting the Domain
Clean architecture - Protecting the DomainVictor Rentea
 
The tests are trying to tell you something@VoxxedBucharest.pptx
The tests are trying to tell you something@VoxxedBucharest.pptxThe tests are trying to tell you something@VoxxedBucharest.pptx
The tests are trying to tell you something@VoxxedBucharest.pptxVictor Rentea
 
Hexagonal architecture - message-oriented software design
Hexagonal architecture  - message-oriented software designHexagonal architecture  - message-oriented software design
Hexagonal architecture - message-oriented software designMatthias Noback
 
SOLID, DRY, SLAP design principles
SOLID, DRY, SLAP design principlesSOLID, DRY, SLAP design principles
SOLID, DRY, SLAP design principlesSergey Karpushin
 
OOP - Polymorphism
OOP - PolymorphismOOP - Polymorphism
OOP - PolymorphismMudasir Qazi
 
Java11 New Features
Java11 New FeaturesJava11 New Features
Java11 New FeaturesHaim Michael
 
S.O.L.I.D. Principles for Software Architects
S.O.L.I.D. Principles for Software ArchitectsS.O.L.I.D. Principles for Software Architects
S.O.L.I.D. Principles for Software ArchitectsRicardo Wilkins
 
Clean Pragmatic Architecture - Avoiding a Monolith
Clean Pragmatic Architecture - Avoiding a MonolithClean Pragmatic Architecture - Avoiding a Monolith
Clean Pragmatic Architecture - Avoiding a MonolithVictor Rentea
 
The Kotlin Programming Language
The Kotlin Programming LanguageThe Kotlin Programming Language
The Kotlin Programming Languageintelliyole
 
Hexagonal architecture with Spring Boot
Hexagonal architecture with Spring BootHexagonal architecture with Spring Boot
Hexagonal architecture with Spring BootMikalai Alimenkou
 

What's hot (20)

Geecon09: SOLID Design Principles
Geecon09: SOLID Design PrinciplesGeecon09: SOLID Design Principles
Geecon09: SOLID Design Principles
 
SOLID Design Principles
SOLID Design PrinciplesSOLID Design Principles
SOLID Design Principles
 
Solid Principles
Solid PrinciplesSolid Principles
Solid Principles
 
Single Responsibility Principle
Single Responsibility PrincipleSingle Responsibility Principle
Single Responsibility Principle
 
Solid design principles
Solid design principlesSolid design principles
Solid design principles
 
Solid principles
Solid principlesSolid principles
Solid principles
 
Java 8 Lambda Built-in Functional Interfaces
Java 8 Lambda Built-in Functional InterfacesJava 8 Lambda Built-in Functional Interfaces
Java 8 Lambda Built-in Functional Interfaces
 
Clean architecture - Protecting the Domain
Clean architecture - Protecting the DomainClean architecture - Protecting the Domain
Clean architecture - Protecting the Domain
 
The tests are trying to tell you something@VoxxedBucharest.pptx
The tests are trying to tell you something@VoxxedBucharest.pptxThe tests are trying to tell you something@VoxxedBucharest.pptx
The tests are trying to tell you something@VoxxedBucharest.pptx
 
Hexagonal architecture - message-oriented software design
Hexagonal architecture  - message-oriented software designHexagonal architecture  - message-oriented software design
Hexagonal architecture - message-oriented software design
 
SOLID, DRY, SLAP design principles
SOLID, DRY, SLAP design principlesSOLID, DRY, SLAP design principles
SOLID, DRY, SLAP design principles
 
OOP - Polymorphism
OOP - PolymorphismOOP - Polymorphism
OOP - Polymorphism
 
Java11 New Features
Java11 New FeaturesJava11 New Features
Java11 New Features
 
JUnit 5
JUnit 5JUnit 5
JUnit 5
 
S.O.L.I.D. Principles for Software Architects
S.O.L.I.D. Principles for Software ArchitectsS.O.L.I.D. Principles for Software Architects
S.O.L.I.D. Principles for Software Architects
 
Clean code: SOLID
Clean code: SOLIDClean code: SOLID
Clean code: SOLID
 
Clean Pragmatic Architecture - Avoiding a Monolith
Clean Pragmatic Architecture - Avoiding a MonolithClean Pragmatic Architecture - Avoiding a Monolith
Clean Pragmatic Architecture - Avoiding a Monolith
 
The Kotlin Programming Language
The Kotlin Programming LanguageThe Kotlin Programming Language
The Kotlin Programming Language
 
SOLID Principles
SOLID PrinciplesSOLID Principles
SOLID Principles
 
Hexagonal architecture with Spring Boot
Hexagonal architecture with Spring BootHexagonal architecture with Spring Boot
Hexagonal architecture with Spring Boot
 

Viewers also liked (15)

Rest web services
Rest web servicesRest web services
Rest web services
 
PoEAA by Example
PoEAA by ExamplePoEAA by Example
PoEAA by Example
 
Enterprise Integration Patterns
Enterprise Integration PatternsEnterprise Integration Patterns
Enterprise Integration Patterns
 
Lição prova professor coordenador
Lição prova professor coordenadorLição prova professor coordenador
Lição prova professor coordenador
 
REST beyond CRUD
REST beyond CRUDREST beyond CRUD
REST beyond CRUD
 
Principles of Service Orientation
Principles of Service OrientationPrinciples of Service Orientation
Principles of Service Orientation
 
Modern web architectural patterns
Modern web architectural patternsModern web architectural patterns
Modern web architectural patterns
 
Patterns for distributed systems
Patterns for distributed systemsPatterns for distributed systems
Patterns for distributed systems
 
Communication
CommunicationCommunication
Communication
 
RESTful services Design Lab
RESTful services Design LabRESTful services Design Lab
RESTful services Design Lab
 
Decoupled Communication
Decoupled CommunicationDecoupled Communication
Decoupled Communication
 
OO design principles and patterns
OO design principles and patternsOO design principles and patterns
OO design principles and patterns
 
Benefits of Hypermedia API
Benefits of Hypermedia APIBenefits of Hypermedia API
Benefits of Hypermedia API
 
Software Product Lines
Software Product LinesSoftware Product Lines
Software Product Lines
 
Patterns of Enterprise Application Architecture (by example)
Patterns of Enterprise Application Architecture (by example)Patterns of Enterprise Application Architecture (by example)
Patterns of Enterprise Application Architecture (by example)
 

Similar to Design Patterns: From STUPID to SOLID code

Object Oriented Concepts and Principles
Object Oriented Concepts and PrinciplesObject Oriented Concepts and Principles
Object Oriented Concepts and Principlesdeonpmeyer
 
SOLID principles-Present
SOLID principles-PresentSOLID principles-Present
SOLID principles-PresentQuang Nguyen
 
Design principle vs design patterns
Design principle vs design patternsDesign principle vs design patterns
Design principle vs design patternsPrabhakar Sharma
 
Development principles in test automation!
Development principles in test automation!Development principles in test automation!
Development principles in test automation!David Baak
 
OO design principles & heuristics
OO design principles & heuristicsOO design principles & heuristics
OO design principles & heuristicsDhaval Shah
 
Inversion of Control
Inversion of ControlInversion of Control
Inversion of ControlShuhab Tariq
 
Is your code solid
Is your code solidIs your code solid
Is your code solidNathan Gloyn
 
Common Design Patterns.pptx
Common Design Patterns.pptxCommon Design Patterns.pptx
Common Design Patterns.pptxfake195786
 
Solid OO & Clean Coding is essential to successful Agile development
Solid OO & Clean Coding is essential to successful Agile developmentSolid OO & Clean Coding is essential to successful Agile development
Solid OO & Clean Coding is essential to successful Agile developmentSimon Gould
 
Combating software entropy 2-roc1-
Combating software entropy 2-roc1-Combating software entropy 2-roc1-
Combating software entropy 2-roc1-Hammad Rajjoub
 
The software design principles
The software design principlesThe software design principles
The software design principlesAman Kesarwani
 
C:\Fakepath\Combating Software Entropy 2
C:\Fakepath\Combating Software Entropy 2C:\Fakepath\Combating Software Entropy 2
C:\Fakepath\Combating Software Entropy 2Hammad Rajjoub
 
C:\Fakepath\Combating Software Entropy 2
C:\Fakepath\Combating Software Entropy 2C:\Fakepath\Combating Software Entropy 2
C:\Fakepath\Combating Software Entropy 2Hammad Rajjoub
 
Software Design Principles (SOLID)
Software Design Principles (SOLID)Software Design Principles (SOLID)
Software Design Principles (SOLID)ASIMYILDIZ
 

Similar to Design Patterns: From STUPID to SOLID code (20)

Object Oriented Concepts and Principles
Object Oriented Concepts and PrinciplesObject Oriented Concepts and Principles
Object Oriented Concepts and Principles
 
SOLID principles-Present
SOLID principles-PresentSOLID principles-Present
SOLID principles-Present
 
OO Design Principles
OO Design PrinciplesOO Design Principles
OO Design Principles
 
Design principle vs design patterns
Design principle vs design patternsDesign principle vs design patterns
Design principle vs design patterns
 
Development principles in test automation!
Development principles in test automation!Development principles in test automation!
Development principles in test automation!
 
L07 Design Principles
L07 Design PrinciplesL07 Design Principles
L07 Design Principles
 
Android architecture
Android architectureAndroid architecture
Android architecture
 
OO design principles & heuristics
OO design principles & heuristicsOO design principles & heuristics
OO design principles & heuristics
 
Inversion of Control
Inversion of ControlInversion of Control
Inversion of Control
 
Is your code solid
Is your code solidIs your code solid
Is your code solid
 
Solid
SolidSolid
Solid
 
L22 Design Principles
L22 Design PrinciplesL22 Design Principles
L22 Design Principles
 
Common Design Patterns.pptx
Common Design Patterns.pptxCommon Design Patterns.pptx
Common Design Patterns.pptx
 
Solid OO & Clean Coding is essential to successful Agile development
Solid OO & Clean Coding is essential to successful Agile developmentSolid OO & Clean Coding is essential to successful Agile development
Solid OO & Clean Coding is essential to successful Agile development
 
Combating software entropy 2-roc1-
Combating software entropy 2-roc1-Combating software entropy 2-roc1-
Combating software entropy 2-roc1-
 
The software design principles
The software design principlesThe software design principles
The software design principles
 
Solid Principles
Solid PrinciplesSolid Principles
Solid Principles
 
C:\Fakepath\Combating Software Entropy 2
C:\Fakepath\Combating Software Entropy 2C:\Fakepath\Combating Software Entropy 2
C:\Fakepath\Combating Software Entropy 2
 
C:\Fakepath\Combating Software Entropy 2
C:\Fakepath\Combating Software Entropy 2C:\Fakepath\Combating Software Entropy 2
C:\Fakepath\Combating Software Entropy 2
 
Software Design Principles (SOLID)
Software Design Principles (SOLID)Software Design Principles (SOLID)
Software Design Principles (SOLID)
 

More from Paulo Gandra de Sousa

More from Paulo Gandra de Sousa (9)

Introduction to Microservices
Introduction to MicroservicesIntroduction to Microservices
Introduction to Microservices
 
Minds-on DDD
Minds-on DDDMinds-on DDD
Minds-on DDD
 
Introduction to microservices
Introduction to microservicesIntroduction to microservices
Introduction to microservices
 
Design Patterns: Back to Basics
Design Patterns: Back to BasicsDesign Patterns: Back to Basics
Design Patterns: Back to Basics
 
Hypermedia APIs
Hypermedia APIsHypermedia APIs
Hypermedia APIs
 
Revision control with Mercurial
Revision control with MercurialRevision control with Mercurial
Revision control with Mercurial
 
Documenting Software Architectures
Documenting Software ArchitecturesDocumenting Software Architectures
Documenting Software Architectures
 
models of distributed computing
models of distributed computingmodels of distributed computing
models of distributed computing
 
Distributed Systems
Distributed SystemsDistributed Systems
Distributed Systems
 

Recently uploaded

Syngulon - Selection technology May 2024.pdf
Syngulon - Selection technology May 2024.pdfSyngulon - Selection technology May 2024.pdf
Syngulon - Selection technology May 2024.pdfSyngulon
 
Enterprise Knowledge Graphs - Data Summit 2024
Enterprise Knowledge Graphs - Data Summit 2024Enterprise Knowledge Graphs - Data Summit 2024
Enterprise Knowledge Graphs - Data Summit 2024Enterprise Knowledge
 
UiPath Test Automation using UiPath Test Suite series, part 2
UiPath Test Automation using UiPath Test Suite series, part 2UiPath Test Automation using UiPath Test Suite series, part 2
UiPath Test Automation using UiPath Test Suite series, part 2DianaGray10
 
Structuring Teams and Portfolios for Success
Structuring Teams and Portfolios for SuccessStructuring Teams and Portfolios for Success
Structuring Teams and Portfolios for SuccessUXDXConf
 
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdfIntroduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdfFIDO Alliance
 
Connecting the Dots in Product Design at KAYAK
Connecting the Dots in Product Design at KAYAKConnecting the Dots in Product Design at KAYAK
Connecting the Dots in Product Design at KAYAKUXDXConf
 
Measures in SQL (a talk at SF Distributed Systems meetup, 2024-05-22)
Measures in SQL (a talk at SF Distributed Systems meetup, 2024-05-22)Measures in SQL (a talk at SF Distributed Systems meetup, 2024-05-22)
Measures in SQL (a talk at SF Distributed Systems meetup, 2024-05-22)Julian Hyde
 
IESVE for Early Stage Design and Planning
IESVE for Early Stage Design and PlanningIESVE for Early Stage Design and Planning
IESVE for Early Stage Design and PlanningIES VE
 
The Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdf
The Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdfThe Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdf
The Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdfFIDO Alliance
 
FDO for Camera, Sensor and Networking Device – Commercial Solutions from VinC...
FDO for Camera, Sensor and Networking Device – Commercial Solutions from VinC...FDO for Camera, Sensor and Networking Device – Commercial Solutions from VinC...
FDO for Camera, Sensor and Networking Device – Commercial Solutions from VinC...FIDO Alliance
 
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo DiehlFuture Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo DiehlPeter Udo Diehl
 
PLAI - Acceleration Program for Generative A.I. Startups
PLAI - Acceleration Program for Generative A.I. StartupsPLAI - Acceleration Program for Generative A.I. Startups
PLAI - Acceleration Program for Generative A.I. StartupsStefano
 
Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptx
Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptxUnpacking Value Delivery - Agile Oxford Meetup - May 2024.pptx
Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptxDavid Michel
 
10 Differences between Sales Cloud and CPQ, Blanka Doktorová
10 Differences between Sales Cloud and CPQ, Blanka Doktorová10 Differences between Sales Cloud and CPQ, Blanka Doktorová
10 Differences between Sales Cloud and CPQ, Blanka DoktorováCzechDreamin
 
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya HalderCustom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya HalderCzechDreamin
 
Strategic AI Integration in Engineering Teams
Strategic AI Integration in Engineering TeamsStrategic AI Integration in Engineering Teams
Strategic AI Integration in Engineering TeamsUXDXConf
 
Extensible Python: Robustness through Addition - PyCon 2024
Extensible Python: Robustness through Addition - PyCon 2024Extensible Python: Robustness through Addition - PyCon 2024
Extensible Python: Robustness through Addition - PyCon 2024Patrick Viafore
 
UiPath Test Automation using UiPath Test Suite series, part 1
UiPath Test Automation using UiPath Test Suite series, part 1UiPath Test Automation using UiPath Test Suite series, part 1
UiPath Test Automation using UiPath Test Suite series, part 1DianaGray10
 
AI presentation and introduction - Retrieval Augmented Generation RAG 101
AI presentation and introduction - Retrieval Augmented Generation RAG 101AI presentation and introduction - Retrieval Augmented Generation RAG 101
AI presentation and introduction - Retrieval Augmented Generation RAG 101vincent683379
 
IoT Analytics Company Presentation May 2024
IoT Analytics Company Presentation May 2024IoT Analytics Company Presentation May 2024
IoT Analytics Company Presentation May 2024IoTAnalytics
 

Recently uploaded (20)

Syngulon - Selection technology May 2024.pdf
Syngulon - Selection technology May 2024.pdfSyngulon - Selection technology May 2024.pdf
Syngulon - Selection technology May 2024.pdf
 
Enterprise Knowledge Graphs - Data Summit 2024
Enterprise Knowledge Graphs - Data Summit 2024Enterprise Knowledge Graphs - Data Summit 2024
Enterprise Knowledge Graphs - Data Summit 2024
 
UiPath Test Automation using UiPath Test Suite series, part 2
UiPath Test Automation using UiPath Test Suite series, part 2UiPath Test Automation using UiPath Test Suite series, part 2
UiPath Test Automation using UiPath Test Suite series, part 2
 
Structuring Teams and Portfolios for Success
Structuring Teams and Portfolios for SuccessStructuring Teams and Portfolios for Success
Structuring Teams and Portfolios for Success
 
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdfIntroduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
 
Connecting the Dots in Product Design at KAYAK
Connecting the Dots in Product Design at KAYAKConnecting the Dots in Product Design at KAYAK
Connecting the Dots in Product Design at KAYAK
 
Measures in SQL (a talk at SF Distributed Systems meetup, 2024-05-22)
Measures in SQL (a talk at SF Distributed Systems meetup, 2024-05-22)Measures in SQL (a talk at SF Distributed Systems meetup, 2024-05-22)
Measures in SQL (a talk at SF Distributed Systems meetup, 2024-05-22)
 
IESVE for Early Stage Design and Planning
IESVE for Early Stage Design and PlanningIESVE for Early Stage Design and Planning
IESVE for Early Stage Design and Planning
 
The Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdf
The Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdfThe Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdf
The Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdf
 
FDO for Camera, Sensor and Networking Device – Commercial Solutions from VinC...
FDO for Camera, Sensor and Networking Device – Commercial Solutions from VinC...FDO for Camera, Sensor and Networking Device – Commercial Solutions from VinC...
FDO for Camera, Sensor and Networking Device – Commercial Solutions from VinC...
 
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo DiehlFuture Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
 
PLAI - Acceleration Program for Generative A.I. Startups
PLAI - Acceleration Program for Generative A.I. StartupsPLAI - Acceleration Program for Generative A.I. Startups
PLAI - Acceleration Program for Generative A.I. Startups
 
Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptx
Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptxUnpacking Value Delivery - Agile Oxford Meetup - May 2024.pptx
Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptx
 
10 Differences between Sales Cloud and CPQ, Blanka Doktorová
10 Differences between Sales Cloud and CPQ, Blanka Doktorová10 Differences between Sales Cloud and CPQ, Blanka Doktorová
10 Differences between Sales Cloud and CPQ, Blanka Doktorová
 
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya HalderCustom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
 
Strategic AI Integration in Engineering Teams
Strategic AI Integration in Engineering TeamsStrategic AI Integration in Engineering Teams
Strategic AI Integration in Engineering Teams
 
Extensible Python: Robustness through Addition - PyCon 2024
Extensible Python: Robustness through Addition - PyCon 2024Extensible Python: Robustness through Addition - PyCon 2024
Extensible Python: Robustness through Addition - PyCon 2024
 
UiPath Test Automation using UiPath Test Suite series, part 1
UiPath Test Automation using UiPath Test Suite series, part 1UiPath Test Automation using UiPath Test Suite series, part 1
UiPath Test Automation using UiPath Test Suite series, part 1
 
AI presentation and introduction - Retrieval Augmented Generation RAG 101
AI presentation and introduction - Retrieval Augmented Generation RAG 101AI presentation and introduction - Retrieval Augmented Generation RAG 101
AI presentation and introduction - Retrieval Augmented Generation RAG 101
 
IoT Analytics Company Presentation May 2024
IoT Analytics Company Presentation May 2024IoT Analytics Company Presentation May 2024
IoT Analytics Company Presentation May 2024
 

Design Patterns: From STUPID to SOLID code

Editor's Notes

  1. Tight coupling: criar objetos concretos dentro de métodos faz a classe ficar dependente  Dependency injection
  2. Uma classe deve ter uma e apenas uma responsabilidade Favorecer classes “pequenas” focadas num único aspeto/conceito do problema Todos os métodos da interface pública da classe devem fazer um conjunto coerente Permite melhor divisão de tarefas e maior facilidade de manutenção
  3. Uma classe deve ser aberta (open) para extensão mas fechada (close) para modificação Novos requisitos e comportamentos devem ser obtidos através da extensão da classe e não da sua modificação Ao criar a classe identificar (possíveis) pontos de futura variabilidade e desenhar a classe para poder ser estendida nesses pontos Template Method Strategy Decorator – veremos mais tarde Visitor – veremos mais tarde
  4. Don’t touch existing code (bug fixes excluded). You should have no reason to change the internals of a class to add new behaviour, instead you should extend the class with the new behaviour.
  5. Problema: Permitir que o cliente escolha de muitas alternativas, complexas, sendo que não se deseja incluir código para todas. Solução: Fazer muitas implementações da mesma interface, e permitir que o cliente seleccione uma e a devolva. Definir uma família de algoritmos, encapsular cada um deles, e torná-los permutáveis. Strategy permite que o algoritmo varie independentemente dos clientes que o usam.
  6. Problem: Allow functionally to be layered around an abstraction, but still dynamically changeable. Solution: Combine inheritance and composition. By making an object that both subclasses from anther class and holds an instance of the class, can add new behavior while referring all other behavior to the original class.
  7. Problem How to dinamically add new operations to existing data structures? Solution Separate the algorithm from the data structure it operates on by creating a visitor that traverses the desired object. the visitor design pattern is a way of separating an algorithm from an object structure on which it operates. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures. It is one way to follow the open/closed principle. In essence, the visitor allows one to add new virtual functions to a family of classes without modifying the classes themselves; instead, one creates a visitor class that implements all of the appropriate specializations of the virtual function. The visitor takes the instance reference as input, and implements the goal through double dispatch.
  8. Qualquer método que espere um objeto de um tipo A deve poder trabalhar com qualquer objeto derivado de A Classes derivadas devem cumprir o mesmo contrato (sem alterações semânticas) da classe base
  9. Muitas interfaces específicas são melhores que uma única genérica Classes clientes não devem ser forçadas a depender de interfaces que não necessitam (não usam)
  10. Deve depender-se de abstrações e não de concretizações Ex., List vs. ArrayList Criar uma camada de abstração que diminuirá o acoplamento entre módulos Abstrações tendem a modificar com menos frequência que as concretizações
  11. Clients should depend on abstractions, not concretions. I.e., program to an interface not a realization. DIP Deve depender-se de abstrações e não de concretizações Ex., List vs. ArrayList Criar uma camada de abstração que diminuirá o acoplamento entre módulos
  12. Problema: Como diminuir o acoplamento entre classes de camadas diferentes Solução: Colocar a interface do serviço num package e a implementação noutro Diminui o coupling entre classes do sistema evitando que classes de uma camada façam referência directa a outra Ex., componentes de lógica de acesso a dados chamarem métodos de classes de negócio
  13. Program to an interface not an implementation: Decreases coupling/dependencies among classes Favour composition instead of inheritance: Don’t inherit behaviour you don’t need. Allow for implementation changes Consider what should be variable in your design: hide what varies and allow for substitution via common interface Keep different responsibilities apart from each other: Don’t create big, fat classes Program to an interface and not to an implementation - Purring this more succinctly, you should define the top of any class hierarchy with an abstract class, which implements no methods, but simply defines the methods that class will support. Then, in all of your derived classes you have more freedom to implement these methods as most suits your purposes. Essentially this means considering the object you are dealing with as a black box. Do not consider how it does its tasks, just consider the interface (set of public methods) that it allows you to use. Favor object composition over inheritance - While many beginning OO programmers use inheritance to solve every problem when an alternative way is needed to accomplish something. This works well for handling one variation. However, if something else starts to vary you get an exponentially increasing number of possible combinations. Using inheritance alone requires a correspondingly large number of classes (one for each combination). As you begin to write more elaborate programs, the merits of object composition become apparent. Your new object can have the interface that is best for what you want to accomplish without having all the methods of the parent classes.  Consider what should be variable in your design - Focus on encapsulating the concept that varies. Allow substitution of variable implementations via a common interface.