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-up
Jan. 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 Developers
Open Group: Members, Sponsors and Organizers welcome
Next topics: S.O.L.I.D., VR Game Design with Unity, IoT Show
Case, Eye Tracking, SE Start-ups: Lessons Learned
Contact
Roland Petrasch
Thammasat University, Department of Computer Science,
Rangsit Campus, Pathum Thani
roland.petrasch@cs.tu.ac.th
roland.petrasch@gmail.com

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 & components
Module → OO: class(es) + interface(s)
Component = module(s), package, service
Provider → client, interface(s)
Encapsulation / information hiding
Can be OO (instantiation) or non-OO
Dependency
Interdependence 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
Coupling
Inter-module aspect: Degree of (in)direct
dependencies to other components / modules
Example
Tight coupling: Component uses implementation
Loose coupling: Component uses an abstraction
OO: Inheritance
Loose coupling is better than
tight 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
Coupling
Example
Surveillance App
M D C C

S O L I D
R C S S I
P P P P P
7 / 36
SOLID Basics
Cohesion
Intra-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
Cohesion
Example:
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
SOLID
Bertram Meyer described SE principles, DbC … [1]
5 Principles were introduced in 2000s by
Robert C. Martin [3]
Principles can lead to better software quality
Maintainability
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 Principles
SRP – Single Responsibility Principle
SRP
A class should have only one reason to change
Responsibility relates to features and aspects
Technological 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
SOLID SE Principles
Example: entity class and persistence
M D C C
class Camera {
String name;
Integer fps;
Integer resolution;
Boolean motionTracking;
...
}
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
Access
Object

S O L I D
R C S S I
P P P P P
12 / 36
SOLID SE Principles
DoDOO – Don't destroy Object-Orientation
M D C C
class Camera {
String name;
Integer fps;
Integer resolution;
VDOBuffer buffer;
...
}
}
class CameraLogic {
public void record(
Camera camera) {
...
}
public void stream(
Camera camera,
Stream stream) {
...
}
}
OO Encapsulation: class consists of
attributes (data member) and behavior
(methods / member functions)

S O L I D
R C S S I
P P P P P
13 / 36
SOLID SE Principles
DoMa – The domain matters
M 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
SOLID SE Principles
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 Principles
OCP - 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
SOLID SE Principles
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
SOLID SE Principles
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
SOLID SE Principles
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 Principles
Liskov 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
SOLID SE Principles
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
SOLID SE Principles
Example: problems
OEM→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
SOLID SE Principles
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
SOLID SE Principles
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
OOA
OOD

S O L I D
R C S S I
P P P P P
24 / 36
SOLID SE Principles
ISP 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
SOLID SE Principles
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
SOLID SE Principles
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
SOLID SE Principles
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
SOLID SE Principles
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 Principles
DIP 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
SOLID SE Principles
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 and
is 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
SOLID SE Principles
Architecture: Business logic is always high-level
M D C C
BL
BL
BL
BL
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
SOLID SE Principles
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, but
other 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-wal
lpaper-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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie S.O.L.I.D. Software-Engineering Principles - a must know for developers

Ähnlich wie S.O.L.I.D. Software-Engineering Principles - a must know for developers (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

S.O.L.I.D. Software-Engineering Principles - a must know for developers