Upload
olafur-andri-ragnarsson
View
539
Download
0
Embed Size (px)
Citation preview
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