HÖNNUN OG SMÍÐI HUGBÚNAÐAR 2015L22 DESIGN PRINCIPLES

Agenda▪ Why Principles?▪ SOLID Principle– 1. Single Responsibility Principle– 2. Open/Closed Principle– 3. Liskov Substitution Principle– 4. Interface Segregation Principle– 5. Dependency Inversion Principle

Reading▪ SOLID - the first five principles of Object Oriented Deign by Samuel

Oloruntoba

Big Ball of MudIs this your code?

Technical DeptReferring to the eventual consequences of poor system design

Hacks, fix it later, mistakes etc

Why Principles?Based on knowledge and research Encourage writing high quality code Promote better communication

Why Principles?Should not be taken as dogmatic

All design decision have context and specific set of problems to solve

SOLID PrinciplesPromotes Object Oriented Design and Development

S O L I D

Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle

Single Responsibility Principle (SRP)

A class should have one and only one reason to change, meaning that a class should have only

one job

Violating this principle leads to low cohesion and make the code brittle and loads to code bloat and confusion

It is not easy to spot

Single Responsibility Principle

Cohesion refers to the degree to which the elements of a module belong together

High cohesion: methods that serve the given class tend to be similar in many aspects

Increased understanding of modules Increased ease in maintaining a system Increased ease in reusing a module

Single Responsibility PrincipleExample: Rectangle has two responsibilities

The Open-Closed Principle (OCP)

Adding new functionality would involve minimal changes to existing code

Objects or entities should be open for extension, but closed for modification.

The Open-Closed Principle (OCP)

Most changes will be handled as new methods and new classes

Designs following this principle would result in resilient code which does not break on addition of new functionality

public class ResourceAllocator { ... public int allocate(intresourceType) { intresourceId; switch (resourceType) { case TIME_SLOT: resourceId = findFreeTimeSlot(); markTimeslotBusy(resourceId); break; case SPACE_SLOT: resourceId = findFreeSpaceSlot(); markSpaceSlotBusy(resourceId); break; ... } return resourceId; } ...

Resource Allocator Example

Resource Allocator Example

List resources = new ArrayList(); ... public int allocate(intresourceType) { int resourceId = findFreeResource(resourceType); markAsBusy(resourceId); return resourceId; }

Designed for extension

The Liskov Substitution Principle (LSP)

Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is

a subtype of T.

All code operating with reference to the base class should be completely transparent to the type of the inherited object

The Liskov Substitution Principle (LSP)

It should be possible to substitute an object of one type with another within the same class hierarchy

Inheriting classes should not perform any actions that will invalidate the assumptions made by the base class

LSP Examplepublic class Rectangle { protected int _width; protected int _height; public int getWidth() { return _width; } public int getHeight() { return _height; } public void setWidth(int width) { _width = width; } public void setHeight(int height) { _height = height; } }

LSP Example

public class Square extends Rectangle { public void setWidth(int width) { _width = width; _height = width; }

public void setHeight(int height) { _height = height; _width = _height; } }

Implementation convenience

LSP Example

import junit.framework.Assert; import org.junit.Test;

public class RectangleTests { @Test public void areaOfRectangle() {

Rectangle r = new Square(); r.setWidth(5); r.setHeight(2); // Will Fail - r is a square and sets // width and height equal to each other. Assert.assertEquals(r.getWidth() * r.getHeight(),10); } }

Interface Segregation Principle (ISP)

A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend

on methods they do not use.

Split large interfaces into smaller and more specific interfaces

Interface Segregation Principle (ISP)

The smaller the interface, the better

For fat or polluted interfaces clients are forced to depend on methods they do not use

Dependency Inversion Principle (DIP)

Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level

module, but they should depend on abstractions.

Low-level components should depend on high-level, not vice versa.

Dependency Inversion Principle (DIP)

The high-level components should be the one defining logic and enforcing change

High-level components depending on low-level components decreases the capability of the high-level components

Dependency Inversion Principle

Separated interface pattern

Program to interfaces

Dependency inversion is the very heart of framework design and loosely coupled design

SOLID PrinciplesPromotes Object Oriented Design and Development

S O L I D

Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle