Principles of Object Orientation Frank Neff 

Don’t be STUPID… • Singleton • Tight Coupling • Untestable • Premature Optimization • Indescriptive Naming • Duplication 

…GRASP SOLID 

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 

Single Responsibility Principle 

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 

SRP 

SRP 

Open / Closed Principle 

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) 

OCP 

OCP 

OCP 

Liskov Substitution Principle 

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 

LSP 

Interface Segregation Principle 

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 

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

DIP 

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 

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 

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 

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 

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 

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” 

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" 

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” 

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 

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 

– Robert C. Martin (aka. Uncle Bob) “Of course bad code can be cleaned up. But it’s very expensive.” 

Thanks Frank Neff Twitter: @frank_neff Blog: frne.github.io Slides: speakerdeck.com/frne