s.o.l.i.d. software-engineering principles - a must know for developers

SOLID Software-Engineering Principles - A must know for developers -

Roland Petrasch

5th SET Meet-upJan. 6, 2016

Bangkok, Thailand

Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University

2 / 36

SET — Software Engineering Thailand

The Interest Group from & (not only) for DevelopersOpen Group: Members, Sponsors and Organizers welcomeNext topics: S.O.L.I.D., VR Game Design with Unity, IoT Show Case, Eye Tracking, SE Start-ups: Lessons LearnedContact

Roland PetraschThammasat University, Department of Computer Science, Rangsit Campus, Pathum Thani

[email protected]@gmail.com

mailto:[email protected]


3 / 36

SOLID Software-Engineering Principles

Agenda

A few Basics, e.g. dependency, coupling, cohesion

S.O.L.I.D. Software-Engineering Principles

SRP: Responsibilities and OO → OCP

Inheritance and Liskov

Substitution Principle

Modules, components & Interface Segregation

Dependency (Abstraction &) Inversion

Discussion

S O L I D

R C S S I

P P P P P

S O L I D

R C S S I

P P P P P


4 / 36

SOLID Basics

Modules & componentsModule → OO: class(es) + interface(s)

Component = module(s), package, service Provider → client, interface(s)

Encapsulation / information hiding

Can be OO (instantiation) or non-OO

DependencyInterdependence between software modules

Strong, e.g. inheritance, content

Weak, e.g. message passing, parameters

M D C C

S O L I D

R C S S I

P P P P P


5 / 36

SOLID Basics

CouplingInter-module aspect: Degree of (in)direct dependencies to other components / modules

ExampleTight coupling: Component uses implementation

Loose coupling: Component uses an abstraction

OO: Inheritance

Loose coupling is better thantight coupling … normally

Source: [4] Rodriguez et al., 2001

M D C C

S O L I D

R C S S I

P P P P P


6 / 36

SOLID Basics

CouplingExampleSurveillance App

M D C C

S O L I D

R C S S I

P P P P P


7 / 36

SOLID Basics

CohesionIntra-module aspect: Degree to which the elements of a module belong together

Behavior and attributes of a module should “work together” (calsule), i.e. the functions/method a class must use the attributes → high cohesion

Otherwise functions/method and attributes do not belong together → low cohesion

High cohesion is good, low cohesion is bad … normally

M D C C

S O L I D

R C S S I

P P P P P


8 / 36

SOLID Basics

CohesionExample:

class Camera {

String name; Integer fps; Integer resolution; Boolean motionTracking;

public String getName() { ... }}

class CameraController {

public String validateSettings() { ... if (fps >= 30 && resolution >= ... }}

Low or no cohesion

M D C C

S O L I D

R C S S I

P P P P P


9 / 36

SOLID SE Principles

SOLIDBertram Meyer described SE principles, DbC … [1]

5 Principles were introduced in 2000s by Robert C. Martin [3]

Principles can lead to better software qualityMaintainability

Understandability / Readability

Correctness

M D C C

S O L I D

R C S S I

P P P P P


10 / 36

SOLID SE PrinciplesSRP – Single Responsibility Principle

SRPA class should have only one reason to change

Responsibility relates to features and aspectsTechnological aspects, e.g. output device(s), persistence

Domain-oriented aspects, e.g. CRM, production, HR

Architectural aspects, e.g. cloud app, mobile client

Cohesion and coupling are important underlying concepts for SRP

M D C C

S O L I D

R C S S I

P P P P P


11 / 36


Example: entity class and persistenceM D C C

class Camera {

String name; Integer fps; Integer resolution; Boolean motionTracking;

public String getName() { ... }

public void save() { // some JDBC statements ... }}

class CameraDAO {

public void save( Camera camera) { ... }}

2 reasons for change: domain & persistence FW

class Camera {

...

Separation of concerns

POJO

Data AccessObject

S O L I D

R C S S I

P P P P P


12 / 36


DoDOO – Don't destroy Object-OrientationM D C C

class Camera {

String name; Integer fps; Integer resolution; VDOBuffer buffer;

public String getName() { ... } }

class CameraLogic {

public void record( Camera camera) { ... }

public void stream( Camera camera, Stream stream) { ... }}

OO Encapsulation: class consists ofattributes (data member) and behavior (methods / member functions)

S O L I D

R C S S I

P P P P P


13 / 36


DoMa – The domain mattersM D C C

class Camera {

String OEM; String name; Integer fps; Integer resolution; VDOBuffer buffer; Location location; IP ip;


object Camera1: OEM = “Yamunaki” name = “Y28” fps = 30 Resolution = “1 MPixel” location = “Office” Ip = 1.2.1.1

A camera (type) is not a camera (device)→ 2 domain responsibilities

object Camera1: OEM = “Yamunaki” name = “Y28” fps = 20 Resolution = “2 MPixel” location = “Floor” Ip = 1.2.1.2

Redundant data, semantic gaps

S O L I D

R C S S I

P P P P P


14 / 36


Use the OOA pattern „spec./product“, “model/exemplar”, “type/object“

M D C C

class Camera {

String OEM; String name; Integer max_fps; Integer max_resolution;


class CameraDevice {

Camera camera; Integer fps; Integer resolution; VDOBuffer buffer; Location location; IP ip;

public String record() { ... }

1 *

Camera type / spec Camera device / exemplar

Many-to-one association.NOT inheritance

S O L I D

R C S S I

P P P P P


15 / 36

SOLID SE PrinciplesOCP - Open/Closed Principle

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

Use some good 'ol design patterns, e.g.decorator, strategy, wrapper … ?

Yes and no: DP can be useful, but OCP goes deeper than that

Example: Camera that provides pan, tilt, and zoom functions. Need to change the Camera class?

M D C C

S O L I D

R C S S I

P P P P P


16 / 36


Camera class should be closed to modifications → „new features“

M D C C

class Camera {

String OEM; String name; Integer fps; Integer resolution; Angle pan; Angle tilt; Integer zoom; ...}

A camera should only be changed for one reason(core functionality / responsibility), not for new feature implementation (SRP).

S O L I D

R C S S I

P P P P P


17 / 36


Camera extension … so many possibilities

Inheritance Simple Wrapper Decorator

M D C C

class Camera { ...}

class PTZCamera extends Camera { ...}

class Camera { ...}

class PTZCamera { Camera camera; ...}

class IPCamera { ...}

class PTZCamera { Camera camera; ...}

interface Camera { record()}

S O L I D

R C S S I

P P P P P


18 / 36


OCP focuses on class design

Strong relationship to SRP, cohesion, and coupling

Cohesion should be high when OCP is applied

Coupling cannot be avoided, but maybe minimized

Avoid over-engineering

Coupling is not always so bad as it seems, e.g. domain / entity modeling

Using interfaces instead of implementations has advantages, but ask yourself: Do I need this here now or in the future?

M D C C

S O L I D

R C S S I

P P P P P


19 / 36

SOLID SE PrinciplesLiskov Substitution Principle

Derived types must be completely substitutable for their base types

Strong behavioral subtyping

Barbara Liskov and Jeannette Wing, 1994

Derived class can only override the methods of the superclass when the functionality is preserved

Example:A Person provides or “uses“ the surveillance system.

It can be the OEM, the home owner or an intruder

M D C C

S O L I D

R C S S I

P P P P P


20 / 36


Example: M D C C

Are we really interested in the birthday of the thief?

An OEM probably hasn't a first-name.

Does the home owner have attributes?

S O L I D

R C S S I

P P P P P


21 / 36


Example: problemsOEM→getFirstName() doesn't really make sense(OEM isn't substitutable for its base type Person)

Home owner doesn't have attributes? Really?

Intruder/Thief has unknown birthday, first-name etc.(we'll never know)

We mixed up 2 concepts: roles and persons

Violation of SRP and Liskov substitution principle

M D C C

S O L I D

R C S S I

P P P P P


22 / 36


Persons and Roles … so many possibilities

Inheritance Simple Role Pattern ...

M D C C

S O L I D

R C S S I

P P P P P


23 / 36


System Analysis / OOA is not OOD

OOA: “The system identifies intruder an other unwanted persons ...“

LSP applies to OOD, not to OOA

M D C C

OOAOOD

S O L I D

R C S S I

P P P P P


24 / 36

SOLID SE PrinciplesISP Interface Segregation Principle

ISP addresses high level architectural aspects

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

A clients shouldn’t be forced to depend on methods it doesn't use

Provide specific interfaces to clients (components)

Related pattern: facade pattern

Example: component interfaces to clients of the surveillance system

M D C C

S O L I D

R C S S I

P P P P P


25 / 36


Facade provides one common interface to clients→ Clients depend on methods they don't need/use

M D C C

The monitor doesn't need the configuration features.

S O L I D

R C S S I

P P P P P


26 / 36


Facade interfaces are specific for clients (SRP)

M D C C

Interfaces of the component are segregated

S O L I D

R C S S I

P P P P P


27 / 36


Camera forces clients to implement methods they don't use

M D C C

How to implement the CameraControl?

A control interface?

S O L I D

R C S S I

P P P P P


28 / 36


Camera interfaces should be client-specific,not implementation-specific

M D C C

Interfaces for different clients

S O L I D

R C S S I

P P P P P


29 / 36

SOLID SE PrinciplesDIP Dependency Inversion principle

High-level modules should not depend on low-level modules

Both should depend on abstractions.

Abstractions should not depend upon details

Details should depend upon abstractions

Good example is the DAO pattern

Data Access (low-level) depends on abstraction (and on technological modules = libs, FW etc.)

Entity classes (high-level) do not depend on DAO

M D C C

S O L I D

R C S S I

P P P P P


30 / 36


High-level modules should not depend on low-level modules

This is also true for inheritance, e.g.

Camera (superclass) should never „know“a subclass PTZCamera. It would detroy the whole hierarchie

PTZCamera depends on Camera already andis low-level from the superclass point of view.

M D C C

S O L I D

R C S S I

P P P P P


31 / 36


Architecture: Business logic is always high-level

M D C C

BL

BL

BLBL

BL

Controller

Controller

Controller

View

View

View

Persistence

Persistence

Persistence

Communication

Communication

VO

VO

Programming Language

S O L I D

R C S S I

P P P P P


32 / 36


Why it is called “inversion”? What is inverted?

High-level module need other low level modules

Example: domain objects need to be persisted, so they depend on these features of low-level module for persistence

This dependency (high-level module depend on low-level modules) is inverted, so only low-level modules depend on high-level modules,

Example: domain objects are independent of low-level module for persistence services

M D C C


33 / 36

Discussion

SOLID principles are important, butother principles and rules exist, e.g.

“No circular dependencies“ rule

Tight coupling often causes cyclic dependency

Ripple effect: small & local change → “global” effect

Source: Agustín Ruiz (espejo)


34 / 36

Discussion

SOLID is good, but not a simple formula(Principles are not just rules that can be applied)

Don't start with metrics, those numbers can be tricky(start with a goal and ideas and principles and …)

Check acceptance for SOLID in your team(A hot potato? Lost in Spaghetti code? Good things need time)

Maintainability, re-use and understandability are real cost-savers; go the extra mile for SOLID


35 / 36

SOLID Software-Engineering Principles

References

[1] Bertrand Meyer: Object-Oriented Software Construction. Prentice Hall, 1997

[2] Erich Gamma et al.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994

[3] Robert C. Martin: Agile Software Development, Principles, Patterns, and Practices. Pearson, 2002

[4] Daniel Rodriguez, Rachel Harrison: An Overview of Object-Oriented Design Metrics. RUCS/2001/TR/A, The University Of Reading, 2001

[5] Patkos Csaba: The SOLID Principles.http://code.tutsplus.com/series/the-solid-principles--cms-634

[6] Tigerfreak: Homer Simpson http://s450.photobucket.com/user/tigersafreak/media/homer-simpson-wallpaper-brain-1024-.jpg.html

http://code.tutsplus.com/series/the-solid-principles--cms-634

http://s450.photobucket.com/user/tigersafreak/media/homer-simpson-wallpaper-brain-1024-.jpg.html

http://s450.photobucket.com/user/tigersafreak/media/homer-simpson-wallpaper-brain-1024-.jpg.html

SOLID Software-Engineering Principles - A must know for developers -

Roland Petrasch

Thank you for your attention

s.o.l.i.d. software-engineering principles - a must know for developers

Presentations & Public Speaking