1 / 41

SOLID Object Oriented Design

SOLID Object Oriented Design. Craig Berntson www.craigberntson.com craig@craigberntson.com Twitter: @ craigber. A little about me. Independent consultant in Salt Lake City Currently developing database software for sale to hospitals Microsoft MVP INETA Community Speaker Author.

kaleb
Télécharger la présentation

SOLID Object Oriented Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SOLID Object Oriented Design Craig Berntsonwww.craigberntson.com craig@craigberntson.com Twitter: @craigber

  2. A little about me • Independent consultant in Salt Lake City • Currently developing database software for sale to hospitals • Microsoft MVP • INETA Community Speaker • Author

  3. Today’s session • Review basic OOP and smells • SOLID principles • Other agile/OOP principles

  4. Basic OOP • Polymorphism • Encapsulation • Inheritance • Cohesion • Coupling

  5. Refactoring code smells • Duplicate code • Long method • Large class • Temporary field • Switch statements • Parallel inheritance hierarchies

  6. Design smells • Rigidity • Software is difficult to change • Fragility • Program breaks in many places when a change made in a single place • Immobility • Parts could be useful in other systems, but effort and risk to separate from original system is too great

  7. Design smells • Viscosity • Design-preserving methods are more difficult to use than the hacks • Development environment is slow and inefficient • Needless complexity • Contains elements that aren’t currently useful • Needless repetition • System has lots of repeated code elements • Opacity • A module is difficult to understand

  8. Why does software rot? • Waterfall methodology • Requirements change • Code wants to be chaotic • We don’t take time to refactor • We suck at OO design • Designs and practices are at fault

  9. Technical Debt • The cost to fix rotting code • Interest charges build over time • The longer we take to remove the smells, the more it will cost

  10. SOLID • Single Responsibility Principle (SRP) • Open-Closed Principle (OCP) • Liskov Substitution Principle (LSP) • Interface Segregation Principle (ISP) • Dependency Inversion Principle (DIP)

  11. Where does SOLID come from?

  12. Jenga

  13. A real example

  14. Single Responsibility Principle (SRP) A class should have only one reason to change

  15. Responsibility • What a class does • The more a class does, the more likely it will change • The more a class changes, the more likely we will introduce bugs

  16. Cohesion and Coupling • Cohesion – How closely related are the different responsibilities of a module • Coupling – How much one module relies on another • Goal is low coupling and high cohesion

  17. EXAMPLE CODESingle Responsibility Principle

  18. Demo • Single Responsibility Principle

  19. Open Closed principle (OCP) Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification

  20. Conforming to OCP • Open for extension • Behavior of the module can be extended • We are able to change what the module does • Closed for modification • Extending behavior does not result in changes to source, binary, or code of the module

  21. Does not conform to OCP Client is not open and closed

  22. Strategy pattern Client is both open and closed

  23. Conforming to OCP • Rely on abstractions • Interfaces • Abstract classes

  24. EXAMPLE CODEOpen Closed Principle

  25. Liskov Substitution Principle (LSP) Subtypes must be substitutable for their base types

  26. IS-A • Basic OOP discusses inheritance with “IS-A” • LSP says that “IS-A” refers to behavior • Behavior is what software is really all about

  27. Substitution • Calling code should not know that one module is different from its substitute

  28. EXAMPLE CODELiskov Substitution Principle

  29. Interface Segregation Principle (ISP) Clients should not be forced to depend on methods they do not use

  30. EXAMPLE CODEInterface Segregation Principle

  31. Dependency Inversion Principle (DIP) • High-level modules should not depend on low-level modules. Both should depend on abstractions • Abstractions should not depend on details. Details should depend upon abstractions

  32. EXAMPLE CODEDependency Inversion Principle

  33. Other principles • Keep It Simple Stupid (KISS) • You Ain’tGonna Need It (YAGNI) • Don’t Repeat Yourself (DRY)

  34. Today’s session • Review basic OOP and smells • Single Responsibility Principle (SRP) • Open-Closed Principle (OCP) • LiskovSubstutution Principle (LSP) • Interface Segregation Principle (ISP) • Dependency Inversion Principle (DIP) • Other agile/OOP principles

  35. Questions? • Motivational posters courtesy of Derick Bailey through the Creative Commons License • Contact me • Email: craig@craigberntson.com • Blog: www.craigberntson.com/blog • Twitter: @craigber

More Related