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

52034cfb48ca73e13e130f2711ec41f0?s=128

Frank Neff

May 15, 2016
Tweet

Transcript

  1. Principles of Object Orientation Frank Neff

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

    • Premature Optimization • Indescriptive Naming • Duplication
  3. …GRASP SOLID

  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