1 / 43

Object Oriented Design Principles

Object Oriented Design Principles. Arnon Rotem-Gal-Oz Product Line Architect. Preface. Nothing really new here Just a summary of other people’s work: D.L. Parnas M. Fowler R.C. Martin, B. Meyer, B. Liskov W.J. Brown, R.C. Malveau, H.W. McCormick, T.J. Mowbray GoF N. Malik A. Holub

glynn
Download Presentation

Object Oriented Design Principles

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. Object Oriented Design Principles Arnon Rotem-Gal-Oz Product Line Architect

  2. Preface • Nothing really new here • Just a summary of other people’s work: • D.L. Parnas • M. Fowler • R.C. Martin, B. Meyer, B. Liskov • W.J. Brown, R.C. Malveau, H.W. McCormick, T.J. Mowbray • GoF • N. Malik • A. Holub • And probably others I forgot

  3. Agenda • 7 Deadly Sins of Design • The Rules • Basic Stuff • Evil Stuff • More Stuff

  4. 7 Deadly Sins of Design • Rigidity – make it hard to change • Fragility – make it easy to break • Immobility – make it hard to reuse • Viscosity – make it hard to do the right thing • Needless Complexity – over design • Needless Repetition – error prone • Not doing any

  5. The Rules • Apply Common Sense • Don’t get too dogmatic / religious • Every decision is a tradeoff • All other principles are just that • Guidelines • “best practices” • Consider carefully if you should violate them - but, know you can.

  6. Basic Stuff • OCP open-closed principle • SRP single responsibility principle • ISP interface segregation principle • LSP Liskov substitution principle • DIP dependency inversion principle • Dependency Injection

  7. Open Closed Principle • Software entities ( Classes, Modules, Methods, etc. ) should be open for extension, but closed for modification. • Also Known As • Protected Variation • What Parnas meant when he coined “Information hiding”

  8. Why OCP • If not followed a single change to a program results in a cascade of changes to dependent modules. • The program becomes fragile, rigid, unpredictable and un-reusable.

  9. OCP Example Template Method

  10. OCP implications (examples) • Use private modifier for class members • Refrain from adding Getters automatically • Use abstractions • Extend by inheritance, delegation • Inversion of Control (IoC)

  11. Single Responsibility Principle • A Class should have one reason to change • A Responsibility is a reasons to change • Can be tricky to get granularity right

  12. Why SRP • Single Responsibility = increased cohesion • Not following results in needless dependencies • More reasons to change. • Rigidity, Immobility

  13. SRP Example (1/2) • The Rectangle has 2 responsibilities Algorithm Client Application Rectangle Draw() Area() DirectX Dependency Suddenly the Algorithm needs DirectX

  14. SRP Example (2/2) Client Application Rectangle Area() Rectangle Renderer Draw() Algorithm DirectX Dependency

  15. Interface Segregation Principle • Many client specific interfaces are better than one general purpose interface • Create an interface per client type not per client • Avoid needless coupling to clients

  16. Why ISP • Otherwise – increased coupling between different clients • Basically a variation on SRP

  17. ISP example IRectangle Area() IRectangle Renderer Draw() Client Application Rectangle Impl. Algorithm DirectX Realization Dependency

  18. Liskov Substitution Principle “What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.” (Barbara Liskov, 1988)

  19. Or in English • Any subclass should always be usable instead of its parent class. • Corollary - All derived classes must honour the contracts of their base classes • IS A = same public behavior • Pre-conditions can only get weaker • Post-conditions can only get stronger

  20. Why LSP • Failing to follow LSP result in a mess • OCP violations (if/then to identify types) • Superclass unit test will fail • Strange behavior

  21. Trivial Example Why is that an LSP violation?

  22. Real-Life Example .NET creates a transparent proxy and intercepts all calls to ContextBoundObjects Implementing IContextObjectSink On a class derived from ContrextAttribute lets you add a sink in the chain

  23. Real-Life Example ServicedComponents violates LSP: You cannot add your own sinks (it only uses its own)

  24. Dependency Inversion Principle • Higher level modules should not depend on lower level modules • Both should depend on abstractions • Interfaces or Abstract classes • Abstractions should not depend on details (Not to be confused with Dependency Injection and Inversion of Control)

  25. Why DIP • Increase loose coupling • Abstract interfaces don't change • Concrete classes implement interfaces • Concrete classes easy to throw away and replace • Increase mobility • Increase isolation • decrease rigidity • Increase testability • Increase maintainablity • Closely related to LSP

  26. Reminder - Procedural Design

  27. DIP

  28. DIP implications • Layers • Interface based programming • Separated Interface • put interface in separate package than implementation • Dependency Injection

  29. Old Way public class MyApp { public MyApp() { authenticator = new Authenticator(); database = new Database(); logger = new Logger(); errorHandler = new ErrorHandler(); } // More code here... }

  30. Dependency Injection • DIP says we should depend on an interface • how do we get the concrete instance

  31. New Way? public class MyApp { public MyApp() { authenticator = new IAuthenticator(); database = new IDatabase(); logger = new ILogger(); errorHandler = new IErrorHandler(); } // More code here... } OOPS

  32. Dependency Injection • Option 1 – Factory • User depends on factory • Factory depends on destination • Option 2 – Locator/Registry/Directory • The component still controls the wiring • Instantiation Sequence • Dependency on the Locator • Option 3 – Dependency Injection • An assembler controls the wiring

  33. DI Options • Setter Injection • The component is passive • Someone injects the dependency

  34. DI Options • Setter Injection • Constructor Injection • “Always” initialized • Better dependency visibility

  35. Other DI Options • Interface Injection • Variation on setter injection • Getter Injection • Needs AOP (not clean)

  36. Evil Stuff • Switch statements • If (type()) • Singletons / Global variables • Getters • Helper Classes

  37. More Stuff • Package principles • Not the core of this presentation • Smells • Anti-Patterns

  38. Package Principles • Reuse-Release Equivalency Principle • Common Closure Principle • Common Reuse Principle • Acyclic Dependencies Principle • Stable Dependencies Principle • Stable Abstractions Principle

  39. CodeSmells • Something that's quick to spot • Indication for a possible problem • Not always the problem it self • May not be a problem at all • CodeSmell example – Long Method

  40. DesignSmell (1) • Many CodeSmells can also apply to design • Long Parameter List • Large Class (Swiss Army knife / Blob) • Type Embedded in Name • Uncommunicative Name • Data Class • Refused Bequest (LSP violations)

  41. DesignSmell (2) • Inappropriate Intimacy • Lazy Class • Feature Envy (Managers) • Shotgun Surgery • Parallel Inheritance Hierarchies • Message Chains • Component Without Interface • Singletons

  42. Design Related Anti-Patterns • The Blob • Functional Decomposition • Poltergeist • Golden Hammer • Swiss Army Knife • Kevorkian Component (Dead End) (Other Anti-Patterns deal with Architecture, Management, Code)

  43. Thank you… Arnon Rotem-Gal-Oz arnon@rgoarchitects.com

More Related