Principles of Object Orientation

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

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