L22 Design Principles

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

2. 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

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

4. Big Ball of Mud
Is this your code?

5. Technical Dept
Referring to the eventual consequences of poor
system design
Hacks, fix it later, mistakes etc

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

8. Why Principles?
Should not be taken as dogmatic
All design decision have context and specific set of
problems to solve

9. SOLID Principles
Promotes 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

10. 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

11. 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

12. Single Responsibility Principle
Example: Rectangle has two responsibilities

13. 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.

14. 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

15. 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

16. Resource Allocator Example
List resources = new ArrayList();
...
public int allocate(intresourceType)
{
int resourceId = findFreeResource(resourceType);
markAsBusy(resourceId);
return resourceId;
}
Designed for extension

17. 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

18. 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

19. LSP Example
public 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;
}
}

20. 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

21. 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);
}
}

22. 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

23. 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

25. 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.

26. 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

27. Dependency Inversion Principle
Separated interface pattern
Program to interfaces
Dependency inversion is the very heart of
framework design and loosely coupled design

29. SOLID Principles
Promotes 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