Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Principles of Object Orientation

Principles of Object Orientation

Slides of my talk about GRASP and SOLID principles in object oriented software engineering


Frank Neff

May 15, 2016


  1. Principles of Object Orientation Frank Neff

  2. Don’t be STUPID… • Singleton • Tight Coupling • Untestable

    • Premature Optimization • Indescriptive Naming • Duplication

  4. S.O.L.I.D. • Set of principles defining “good code” • Coined

    by Robert C. Martin (aka. “Uncle Bob”) • Applicable in every object oriented language • Every character represents a different principle
  5. Single Responsibility Principle

  6. SRP • “A class should have only one single responsibility”

    • If a class does two or more different things, split it • Only one reason to change a class
  7. SRP

  8. SRP

  9. Open / Closed Principle

  10. OCP • “A class should be open for extension but

    closed for modification” • Define interfaces or abstract classed which should not change (modification) • Inherit them in concrete classes (extension) • When changes occur, inherit again with different concrete class (extension)
  11. OCP

  12. OCP

  13. OCP

  14. Liskov Substitution Principle

  15. LSP • “Supertypes can be replaced with Subtypes of them

    without changing any properties or methods” • If S extends/implements T, all instances of T can be replaced with S • No further changes to S or T should be needed to do so • If X extends/implements S, all instances of T can be replaces with X
  16. LSP

  17. Interface Segregation Principle

  18. ISP • “No client should be forced to depend on

    methods it does not use” • Split large interfaces into smaller / more specific ones • Think of interfaces as roles or maybe behaviours of an object • Classes can implement multiple interfaces, but should not implement unnecessary methods
  19. Dependency Inversion Principle

  20. 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 on abstractions.” • One concrete class should not depend on other classes • Concrete classes should depend on abstracts or interfaces
  21. DIP

  22. G.R.A.S.P. • Abbrev.: General Responsibility Assignment Software Patterns • Guidelines

    for assigning responsibility to objects in o.o. design • Applicable in every object oriented language
  23. High Cohesion • “High Cohesion is an evaluative pattern that

    attempts to keep objects appropriately focused, manageable and understandable.” • Defines that a class should only have one responsibility and methods / properties of a class should work together closely • The Single Responsibility Principle ensures high cohesion • Supports low coupling of components
  24. Low Coupling • Low Coupling is an evaluative pattern, which

    dictates how to assign responsibilities to support: • Lower dependency between classes • Lower impact on other classes • Higher reuse potential • Depends on high cohesion
  25. Polymorphism • “According to Polymorphism, responsibility of defining the variation

    of behaviors based on type is assigned to the type for which this variation happens.” • Provision of a single interface to entities of different types • Create an object from subtype, use interface of supertype
  26. Controller • “The Controller pattern assigns the responsibility of dealing

    with system events to a non-UI class that represents the overall system or a use case scenario.” • Responsible for handling a system event • Connection between UI and domain logic
  27. Creator • A class responsible for creating objects • Holds

    and creates instanced of another class • Deals with the interface of that class • Contains initialisation information for the created objects • Also called “Factory Pattern”
  28. Indirection • “The Indirection pattern supports low coupling (and reuse

    potential) between two elements by assigning the responsibility of mediation between them to an intermediate object.” • Object which “mediates” between two others • E.g.: Controller in MVC • Often referred as “Delegation Pattern"
  29. Information Expert • “Information Expert is a principle used to

    determine where to delegate responsibilities.” • A class must contain all information it needs for calculation • See also: “Information Hiding”
  30. Protected Variations • “This pattern protects elements from the variations

    on others by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.” • See also: Open/Closed Principle
  31. Pure Fabrication • “A Pure Fabrication is a class that

    does not represent a concept in the problem domain, specially made up to achieve low coupling, high cohesion, and the reuse potential thereof derived.” • Called “Service” in Domain Driven Design • E.g. an object which is connecting an internal library to a module (so there is no dependency between library and module) • Not to be confused with the Factory Pattern
  32. – Robert C. Martin (aka. Uncle Bob) “Of course bad

    code can be cleaned up. But it’s very expensive.”
  33. Thanks Frank Neff Twitter: @frank_neff Blog: frne.github.io Slides: speakerdeck.com/frne