Review OOP design patterns and principles

Reviewing OOP design patterns
Olivier Bacs
@reallyoli

Introduction
Deﬁnition
In software engineering, a software design pattern is a general reusable
solution to a commonly occurring problem within a given context in
software design.
It is not a ﬁnished design that can be transformed directly into source
code.
The implementation approaches tend to be slightly different.

Why spend the time?
- From framework user, to framework creator in a software engineer
career
- Where to direct our attention: brush up on foundations, not
frameworks
- … And time is ﬁnite. Why spend too much time on a problem that has
been solved already?

History
1977: Christopher Alexander introduces the idea of patterns: successful
solutions to problems. (Pattern Language)
1987: Ward Cunningham and Kent Beck leverage Alexander’s idea in the
context of an OO language.
1987: Eric Gamma’s dissertation on importance of patterns and how to
capture them.
1994: The book =>

Core principles of OOP:
Encapsulation
const account = { balance: 1000, owner: 13466 }
example: a bank account object

Encapsulation
-> Encapsulate the properties
! Manipulating properties directly
example: a bank account object

Encapsulation
class Account {
private balance: number
private owner: Customer
public withdraw(amount: number) { // can validate }
public deposit(amount: number) {}
}
Its public API
The object’s internals, what you hide / protect

connectToRemoteServer(){}
validateTokenLength(){}
disconnectFromRemoteServer(){}
moreAndMoreSteps(){}
Abstractions
example: an email distribution API SDK

connectToRemoteServer(){}
validateTokenLength(){}
disconnectFromRemoteServer(){}
moreAndMoreSteps(){}
Abstractions
-> Abstract those activities
! Remove lower level concerns
! Protect from breaking changes in API
example: an email distribution API SDK

class EmailService {
private connectToRemoteServer(){}
private validateTokenLength(){}
private disconnectFromRemoteServer(){}
public sendEmail(){ // leverages all the above }
}
Abstractions
Things that might be extended/removed
be quite complex...
A neat public API

Inheritance
class Rectangle {
fillShape(){ // }
}
example: an design app
class Circle {
fillShape(){ // }
}

Inheritance
class Rectangle {
fillShape(){ // }
}
class Circle {
fillShape(){ // }
}
! Make your code more DRY by avoiding repetitions
-> Add logic to a common ancestor

Inheritance
class Shape {
public fill(colour: string){ //behaviour }
}
class Circle extends Shape {}
const circle = new Circle()
circle.fill(”#FF0000”)
A way to write logic once and update it
downward

Quick recall: the concept of interfaces
An interface is a reference type in OOP.
A reference Type is a “specification type”. We can’t explicitly use it, but it is used
internally by the language.
It enforces a contract that the derived classes will have to obey
Interfaces are an “ideal”

Polymorphism( “Can take many forms” )
example: an animal game for children
interface IAnimal {
makeSound(): string
}
abstract class AbstractAnimal {
abstract makeSound(): string
}
the prefix I is a Convention

Polymorphism( “Can take many forms” )
example: an animal game for children
class Cat implements IAnimal {
public makeSound():string { return “Miaou” }
}
class Cat extend AbstractAnimal {
public makeSound():string { return “Miaou” }
}

Your “API” to other classes
Quick recall: access modifiers

Design principles
of construction

Fundamental principles
Avoiding duplication
A common name, and enough similarities might trump misleading
if(customer !== null && customer.length !== 0) {
// logic
}
if(customer !== null && typeof customer !== “undefined”) {
// logic
}
34
156
Code can drift over time

Avoiding tight coupling
A loosely coupled system
Fixing tire !== fixing dashboard or seatbelt
An architectural ideal

Single responsibility principle, see your code as modular black boxes
Easier to explain
Less surprising
Class is much less likely to
change often
The name should be able to
tell you what it does

Open-Close principle
Open to extension, closed for modification
class CoffeeMaker {
final grindCoffee(): void
final runJob(program: string): void
}
class FancyCoffeMaker extends CoffeeMaker {
runJob(program: string, callback: Function): void
}
Inheritance bring tight coupling
New features should not change the
base class
! Open
!! New feature !!
Don’t change

Dependency Injection
High level modules should not depend upon low level modules.
class EmployeSearchService {
private employeesTable = new DBConnection(3306, “somewhere.”, “admin”, “admin123”, “employees”);
public getById(id: string) {
return this.employeesTable.findbyId(id);
}
}

private employeesTable = new DBConnection(3306, “somewhere.”, “admin”, “admin123”, “employees”);
return this.employeesTable.findbyId(id);
}
}
!! New feature !! Extended search

private employeeDataStore: EmployeeDataStore
constructor(dataStore: EmployeeDataStore) {
this.employeeDataStore = dataStore
}
return this.employeeDataStore.findbyId(id);
}
}
new EmployeeSearchService(new EmployeeNapkins())
new EmployeeSearchService(new ExmployeeExcel())
new EmployeeSearchService(new EmployeeCSV())
Give the stores a common interface
Make your code more flexible

- LSP: Liskov Substitution Principle.
Derived classes must be substitutable for their base classes
- ISP: Interface Segregation Principle
Client should not be forced to depend upon interfaces they do not use

Recall: UML
A visual, language agnostic way to map OOP: Unified Modelling Language
Access:
+ public - private # protected
Properties
class name
Methods

The Five Families of Design Patterns
Creational
Structural Foundational
Concurrency
Behavioural
Modern days design pattern families

The Three Main Families of Design Patterns
Behavioural
Structural
Creational
According to the Gang of Four
23 design patterns

Behavioural Patterns
Used to responsibilities between objects and manage algorithms
● Command
● Observer
● Strategy
● State
● Visitor
● Memento
● Mediator
● Iterator

Structural Patterns
Used to form large structures between many disparate objects
● Adapter
● Proxy
● Decorator
● Facade
● Aggregate
● Bridge

Creational Patterns
Used to construct object so that they can be decoupled from their
implementing system
● Singleton
● Factory Method Pattern
● Abstract Factory
● Builder
● Prototype

Command pattern: An object oriented replacement for callbacks
“Encapsulate a request as an object, thereby letting users parameterize
clients with different requests, queue or log request, and support
undoable operations”

example: configuring input on a game controller
Y
X B
A
Fire Gun
Jump
Duck
Swap weapon
You want to:
> Map inputs to actions in an OO way

example: game controller commands
class InputHandler {
static handleInput() {
if(isPressed(BUTTON_X) jump()
else if(isPressed(BUTTON_Y) fireGun()
else if(isPressed(BUTTON_A) swapWeapon()
else if(isPressed(BUTTON_B) duck()
}
}

Users usually like to map
their own controls to the
inputs
static handleInput() {
if(isPressed(BUTTON_X) jump()
else if(isPressed(BUTTON_Y) fireGun()
else if(isPressed(BUTTON_A) swapWeapon()
else if(isPressed(BUTTON_B) duck()
}
}

> You want to make the direct calls to jump() and fireGun() into something that we can swap
in and out.

interface ICommand {
execute():void
}
class JumpCommand implements ICommand{
execute(): void { jump(); }
}
class DuckCommand implements ICommand{
execute():void { duck(); }
}

private buttonA: Command;
private buttonB: Command;
private buttonX: Command;
private buttonY: Command;
public setButtonA(command: Command): void {this.buttonA = command;}
public setButtonB(command: Command): void {this.buttonB = command;}
public setButtonX(command: Command): void {this.buttonX = command;}
public setButtonY(command: Command): void {this.buttonY = command;}
}

...
public inputHandler():void {
if(isPressed(BUTTON_X) return buttonX.execute()
else if(isPressed(BUTTON_Y) return buttonY.execute()
else if(isPressed(BUTTON_A) return buttonA.execute()
else if(isPressed(BUTTON_B) return buttonB.execute()
return null
}
}

Y
X B
A
Fire Gun
Jump
Duck
Swap weapon

Bonus: Undoing things
interface ICommand {
execute():void
undo():void
}

class MoveUnit {
private x: number;
private y: number;
private xBefore: number;
private yBefore: number;
private unit: ArmyUnit;
constructor(unit: ArmyUnit, x: number, y: number){
this.x = x;
this.y = y;
}
public execute(){
this.xBefore = this.x;
this.yBefore = this.y;
this.unit.moveTo(this.x, this.y)
}
public undo(){
this.unit.moveTo(this.xBefore, this.yBefore)
}
}
CMD CMD CMD CMD CMD
Older Newer
An undo stack
example: a turn by turn strategy game
Undo Redo

Creational Patterns
Singleton pattern: There is power in ONE
“The singleton pattern ensures that only one object of a particular class
is ever created. All further references to objects of the singleton class
refer to the same underlying instance.’

Creational Patterns
example: a logger
> You want to create a logger that adds log lines to files from different locations and
potentially at the same time
> You logs have to maintain the order of the events
> You need to avoid “file already in use” and other lock related issues

Creational Patterns
example: a logger
Not just for a logger, but for most of the xManager, xEngine, xSystem classes of
objects.
Like
- DBConnectionManager
- FilesystemManager
- ...

Creational Patterns
A solution is provided by the singleton pattern:
Enforcing a single global instance that wraps resources you want to protect

Creational Patterns
example: a logger
class Logger {
private static _instance: MyClass;
private constructor() { // initialisation... }
public static getInstance() {
return this._instance || (this._instance = new this());
}
}
const logger = Logger.getInstance();

Creational Patterns
Singleton pattern: There is power is ONE
Global state
Not garbage
collected
There for the
entire life of
the program
*
*Once lazy loaded
Theoretically
accessible from
everywhere

Resources
Another take: The anti patterns http://www.laputan.org/mud/
Build your UML graphs with Lucid Charts
https://www.lucidchart.com/pages/examples/uml_diagram_tool
Readings
Tools

Review OOP design patterns and principles

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Review OOP design patterns and principles

Similar a Review OOP design patterns and principles (20)

Último

Último (20)

Review OOP design patterns and principles