Principles of Object Oriented Design

Marcus Bristol


Why do we care?

What do engineers produce?

"What is Software Design?" - Jack Reeves (1992)

They produce documents that specify how to build a product

Software Values

Secondary: Behaviour

Primary: Flexibility

“I need to you write a program that copies characters from the keyboard to the printer.”

Character Printer - Version 1

void copy() {
  int c;
  while ((c = ReadKeyboard()) != EOF) {
“Uhhh, yep. Ummm, sometimes we want to to read from the paper tape reader...”

Character Printer - Version 2

bool GptFlag = false;
// Remember to clear!

void copy() {
  int c;
  while ((c = (GptFlag ? reatPt() : ReadKeyboard())) != EOF) {
“Okay. Yeah. We need another change. Sometimes we'd like it to write to the paper tape punch”

Character Printer - Version 3

bool GptFlag = false;
bool GpunchFlag = false;
// Remember to clear!

void copy() {
  int c;
  while ((c = (GptFlag ? reatPt() : ReadKeyboard())) != EOF) {
    GpunchFlag ? writePunch(c) : WritePrinter(c);

This code is rotting

  • Rigidity
  • Fragility
  • Immobility
  • Viscosity
  • Needless Complexity

And before too long...

Uncle Bob has assembled eleven principles of
object oriented design, each of which involves an
aspect of dependency management.

The SOLID Principles

  1. the Single Responsibility Principle
  2. the Open-Closed Principle
  3. the Liskov Substitution Principle
  4. the Interface Segregation Principle
  5. the Dependency Inversion Principle

The Principles of Component Cohesion

  1. the Reuse Release Equivalency Principle
  2. the Common Closure Principle
  3. the Common Reuse Principle

The Component Coupling Principles

  1. the Acyclic Dependencies Principle
  2. the Stable Dependencies Principle
  3. the Stable Abstractions Principle

SRP: The Single Responsibility Principle

Tom DeMarco (1979) and Meilir Page-Jones (1988)
“There should never be more than one reason for a class to change.”

Just because you can, it doesn't mean you should

Strive for
low coupling and high cohesion!

Responsibilities are Axes of Change

OCP: The Open / Closed Principle

Bertrand Meyer (1988)
“You should be able to extend a classes behavior, without modifying it.”

Open to Extension
New behavior can be added in the future

Closed to Modification
Changes to source or binary code are not required

LSP: The Liskov Substitution Principle

Barbara Liskov (1988)
“Derived classes must be substitutable for their base classes.”

Its all about types!

LSP suggests that IS-A should be replaced with

ISP: The Interface Segregation Principle

Robert C. Martin (1996)
“Make fine grained interfaces that are client specific.”

Interface keyword/type

public interface IDoSomething { }

Public interface of a class

public class SomeClass { }


  • Keep interfaces small, cohesive, and focused
  • Don't force client code to depend on things it doesn't need
  • Refactor large interfaces so they inherit smaller interfaces

DIP: The Dependency Inversion Principle

Robert C. Martin (1996)
“Depend on abstractions, not on concretions.”

Three Primary Techniques

  • Constructor Injection
  • Property Injection
  • Parameter Injection



But it aint no silver bullet



Thanks to our sponsors

Thanks everyone

You've been awesome!