Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Design Patterns: From STUPID to SOLID code

Good principles of OOP to follow and bad practices to avoid

  • Sé el primero en comentar

Design Patterns: From STUPID to SOLID code

  2. 2. Singleton Tight coupling Untestable Premature optimization Indescriptive Naming Duplication
  3. 3. Code smells Signs that the code is rotten and should be refactored 2
  4. 4. Single Responsibility Principle Open/Close Liskov Substitution Principle Interface Segregation Dependency Inversion
  5. 5. Single Responsibility Principle A class should have only one reason to change. 4
  6. 6. 5
  7. 7. 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
  8. 8. 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 *
  9. 9. Open/Close Principle A module should be open for extension but closed for modification. 8
  10. 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? 9
  11. 11. Polymorphism 10
  12. 12. Template Method Define an overall algorithm structure while allowing for certain operations (steps) to be tailored for concrete cases 11
  13. 13. 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
  14. 14. 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
  15. 15. Visitor Separate the algorithm from the data structure it operates on by creating a visitor that traverses the desired object. Source:
  16. 16. 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.
  17. 17. The circle/elipse dilemma 16
  18. 18. The circle/ellipse dilemma 17
  19. 19. Interface Seggregation Principle Many client specific interfaces are better than one general purpose interface. 18
  20. 20. Interface Seggregation Principle 19
  21. 21. Interface Seggregation Principle 20
  22. 22. Dependency Inversion Principle Depend upon Abstractions. Do not depend upon concretions. 21
  23. 23. Dependency Inversion Principle 22
  24. 24. 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; } }
  25. 25. Separated Interface Defines an interface in a separate package from its implementation. source: Patterns of Enterprise Application Architecture
  26. 26. Closings 25
  27. 27. 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
  28. 28. References
  29. 29. Bibliography • Robert C. Martin. Design Principles and Design Patterns. iples_and_Patterns.pdf • William Durand. From STUPID to SOLID code!. solid-code/ • Allen Holub. Why extends is evil. 0801-toolbox.html • Erich Gamma, Richard Helm, Ralph Johnson, John Vissides. Design patterns : elements of reusable object- oriented software. Adisson-Wesley.