breaking_dependencies_the_solid_principles__klaus_iglberger__cppcon_2020.pdf

Breaking Dependencies:
The SOLID Principles
Klaus Iglberger, CppCon 2020
klaus.iglberger@gmx.de

2
Klaus Iglberger
C++ Trainer since 2016
Author of the C++ math library
(Co-)Organizer of the Munich C++ user group
Regular presenter at C++ conferences
Email: klaus.iglberger@gmx.de

Soft
=
5
Easy to change and extend

6
”Coupling is the enemy of change, because it links together things that
must change in parallel.”
(David Thomas, Andrew Hunt, The Pragmatic Programmer)

7
”Dependency is the key problem in software development at all scales.”
(Kent Beck, TDD by Example)

8
Single-Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

9
Robert C. Martin Michael Feathers

11
I will introduce the SOLID principles …
… as guidelines not limited to OO programming
… as general set of guidelines

12
The Single-Responsibility Principle (SRP)

13
”The single responsibility principle states that every module or class
should have responsibility over a single part of the functionality
provided by the software, and that responsibility should be entirely
encapsulated by the class, module or function. All its services should be
narrowly aligned with that responsibility.”
(Wikipedia)

14
”Everything should do just one thing.”
(Common knowledge?)

15
”Orthogonality: … We want to design components that are self-
contained: independent, and with a single, well-defined purpose ([...]
cohesion). When components are isolated from one another, you know
that you can change one without having to worry about the rest.”
(Andrew Hunt, David Thomas, The Pragmatic Programmer)

16
”Cohesion is a measure of the strength of association of the elements
inside a module. A highly cohesive module is a collection of statements
and data items that should be treated as a whole because they are so
closely related. Any attempt to divide them up would only result in
increased coupling and decreased readability.”
(Tom DeMarco, Structured Analysis and System Specification)

17
”A class should have only one reason to change.”
(Robert C. Martin, Agile Software Development)

18
explicit Circle( double rad )
: radius{ rad }
, // ... Remaining data members
{}
double getRadius() const noexcept;
getCenter(), getRotation(), …
void translate( Vector3D const& );
void rotate( Quaternion const& );
private:
double radius;
// ... Remaining data members
class Circle
{
public:
void draw( Screen& s, /*...*/ );
void draw( Printer& p, /*...*/ );
void serialize( ByteStream& bs, /*...*/ );
};
// ...
// ...

19
: radius{ rad }
{}
getCenter(), getRotation(), …
void translate( Vector3D const& );
void rotate( Quaternion const& );
private:
double radius;
class Circle
{
public:
};
// ...
// ...

20
A Circle changes if …
… the basic properties of a circle change;
… the Screen changes;
… the Printer changes;
… the ByteStream changes;
… the implementation details of draw() change;
… the implementation details of serialize() change;
…
class Circle
{
public:
};
// ...
// ...

21
Circle
Overlap
Screen
Square
Printer ByteStream

22
Square
Overlap
Circle Screen
Drawing
Printer ByteStream
Printing Serialization

23
The design of the STL follows the SRP
std::vector follows the SRP
std::string does not follow the SRP
A function should not implement details of two orthogonal issues
void BankAccount::withdrawMoney( User user, long amount )
{
// Verify access for given user
// ...
// Verify balance in account
// ...
// Update amount in database
// ...
return;
}

24
The design of the STL follows the SRP
std::vector follows the SRP
std::string does not follow the SRP
A function should not implement details of two orthogonal issues
void BankAccount::withdrawMoney( User user, long amount )
{
// Verify access for given user
verifyAccess( user );
// Verify balance in account
verifyBalance();
// Update balance in database
updateBalance( amount );
return;
}

25
Guideline: Prefer cohesive software entities. Everything that does not
strictly belong together, should be separated.

27
The Open-Closed Principle (OCP)

28
”Software artifacts (classes, modules, functions, etc.) should be open
for extension, but closed for modification.”
(Bertrand Meyer, Object-Oriented Software Construction)

enum ShapeType
{
circle,
square
};
class Shape
{
public:
explicit Shape( ShapeType t )
: type{ t }
{}
virtual ~Shape() = default;
ShapeType getType() const noexcept;
private:
ShapeType type;
};
class Circle : public Shape
{
public:
: Shape{ circle }
, radius{ rad }
{} 29
OCP: A Procedural Approach

enum ShapeType
{
circle,
square
};
class Shape
{
public:
: type{ t }
{}
private:
ShapeType type;
};
{
public:
: Shape{ circle }
, radius{ rad }
{} 30

enum ShapeType
{
circle,
square
};
class Shape
{
public:
, type{ t }
{}
private:
ShapeType type;
};
{
public:
: Shape{ circle }
, radius{ rad }
{} 31

, type{ t }
{}
private:
ShapeType type;
};
{
public:
: Shape{ circle }
, radius{ rad }
{}
virtual ~Circle() = default;
// ... getCenter(), getRotation(), ...
private:
double radius;
};
void translate( Circle&, Vector3D const& );
void rotate( Circle&, Quaternion const& );
void draw( Circle const& );
class Square : public Shape
{
public:
explicit Square( double s )
: Shape{ square }
32

private:
double radius;
};
{
public:
: Shape{ square }
, side{ s }
{}
virtual ~Square() = default;
double getSide() const noexcept;
private:
double side;
};
void translate( Square&, Vector3D const& );
void rotate( Square&, Quaternion const& );
void draw( Square const& );
void draw( std::vector<std::unique_ptr<Shape>> const& shapes )
{
for( auto const& s : shapes )
{
switch ( s->getType() )
{
33

{}
private:
double side;
};
{
{
{
case circle:
draw( *static_cast<Circle const*>( s.get() ) );
break;
case square:
draw( *static_cast<Square const*>( s.get() ) );
break;
}
}
}
int main()
{
using Shapes = std::vector<std::unique_ptr<Shape>>;
// Creating some shapes
Shapes shapes;
shapes.push_back( std::make_unique<Circle>( 2.0 ) );
shapes.push_back( std::make_unique<Square>( 1.5 ) );
34

{
{
{
case circle:
break;
case square:
break;
}
}
}
int main()
{
Shapes shapes;
// Drawing all shapes
draw( shapes );
}
35

, type{ t }
{}
private:
ShapeType type;
};
{
public:
: Shape{ circle }
, radius{ rad }
{}
private:
double radius;
};
{
public:
: Shape{ square }
36

enum ShapeType
{
circle,
square,
rectangle
};
class Shape
{
public:
: type{ t }
{}
private:
ShapeType type;
};
{
public:
: Shape{ circle }
, radius{ rad }
{}
38

: type{ t }
{}
private:
ShapeType type;
};
{
public:
: Shape{ circle }
, radius{ rad }
{}
private:
double radius;
};
{
public:
: Shape{ square }
39

private:
double radius;
};
{
public:
: Shape{ square }
, side{ s }
{}
private:
double side;
};
{
{
{
40

private:
double side;
};
{
{
{
case circle:
break;
case square:
break;
case rectangle:
draw( *static_cast<Rectangle const*>( s.get() ) );
break;
}
}
}
int main()
{
Shapes shapes;
41

42
”This kind of type-based programming has a long history in C, and one of
the things we know about it is that it yields programs that are
essentially unmaintainable.”
(Scott Meyers, More Effective C++)

class Shape
{
public:
Shape() = default;
virtual void translate( Vector3D const& ) = 0;
virtual void rotate( Quaternion const& ) = 0;
virtual void draw() const = 0;
};
{
public:
: radius{ rad }
{}
void translate( Vector3D const& ) override;
void rotate( Quaternion const& ) override;
void draw() const override;
private:
43
OCP: An Object-Oriented Approach

class Shape
{
public:
Shape() = default;
};
{
public:
: radius{ rad }
{}
private:
44

class Shape
{
public:
Shape() = default;
};
{
public:
: radius{ rad }
{}
private:
double radius;
};
{
public:
45

private:
double radius;
};
{
public:
: side{ s }
{}
private:
double side;
};
{
{
s->draw()
46

{}
private:
double side;
};
{
{
s->draw()
}
}
int main()
{
Shapes shapes;
draw( shapes );
}
47

private:
double side;
};
{
{
s->draw()
}
}
int main()
{
Shapes shapes;
draw( shapes );
}
48

class Shape
{
public:
Shape() = default;
};
{
public:
: radius{ rad }
{}
private:
49

51
Design Evaluation
Addition of
shapes (OCP)
Addition of
operations (OCP)
Separation of
Concerns (SRP)
Ease of Use Performance
Enum 1 7 5 6 9
OO 8 2 2 6 6
Visitor 2 8 8 3 1
mpark::variant 3 9 9 9 9
Strategy 7 2 7 4 2
std::function 8 3 7 7 5
Type Erasure 9 4 8 8 6
1 = very bad, …, 9 = very good
Type Erasure 9 4 8 8 6
OO 8 2 2 6 6

53
namespace std {
template< typename InputIt, typename OutputIt >
OutputIt copy( InputIt first, InputIt last, OutputIt dest )
{
for( ; first != last; ++first, ++dest ) {
*dest = *first;
}
return dest;
}
} // namespace std
The copy() function works for all copyable types. It …
… works for all types that adhere to the required concepts;
… does not have to be modified for new types.

54
Guideline: Prefer software design that allows the addition of types or
operations without the need to modify existing code.

56
The Liskov Substitution Principle (LSP)

57
”What is wanted here is something like the following substitution
property: If for each object o1 of type S there is an object o2 of type T
such that for all programs P defined in terms of T, the behavior of P is
unchanged when o1 is substituted for o2 then S is a subtype of T.”
(Barbara Liskov, Data Abstraction and Hierarchy)
Or in simplified form:
”Subtypes must be substitutable for their base types.”

58
Behavioral subtyping (aka “IS-A” relationship)
• Contravariance of method arguments in a subtype
• Covariance of return types in a subtype
• Preconditions cannot be strengthened in a subtype
• Postconditions cannot be weakened in a subtype
• Invariants of the super type must be preserved in a subtype

59
Which of the following two implementations would you choose?
//***** Option A *****
class Square
{
public:
virtual void setWidth(double);
virtual int getArea();
// ...
private:
double width;
};
class Rectangle
: public Square
{
public:
virtual void setHeight(double);
// ...
private:
double height;
};
//***** Option B *****
class Rectangle
{
public:
virtual void setWidth(double);
virtual void setHeight(double);
virtual int getArea();
// ...
private:
double width;
double height;
};
class Square
: public Rectangle
{
// ...
};

60
namespace std {
{
*dest = *first;
}
return dest;
}
} // namespace std

61
namespace std {
{
*dest = *first;
}
return dest;
}
} // namespace std
The copy() function works if …
… the given InputIt adheres to the required concept;
… the given OutputIt adheres to the required concept.

62
Guideline: Make sure that inheritance is about behavior, not about data.
Guideline: Make sure that the contract of base types is adhered to.
Guideline: Make sure to adhere to the required concept.

64
The Interface Segregation Principle (ISP)

65
”Clients should not be forced to depend on methods that they do not
use.”

66
”Many client specific interfaces are better than one general-purpose
interface.”
(Wikipedia)

class Shape
{
public:
Shape() = default;
};
{
public:
: radius{ rad }
{}
private:
67

68
Context
context()
Strategy
virtual algorithm() = 0
ConcreteStrategyA
virtual algorithm()
ConcreteStrategyB
strategy
virtual algorithm()

69
Shape
draw()
DrawStrategy
virtual draw() = 0
DrawStrategyA
virtual draw()
DrawStrategyB
strategy
virtual draw()

class Shape
{
public:
Shape() = default;
};
{
public:
explicit Circle( double rad, std::unique_ptr<DrawStrategy> ds )
: radius{ rad }
class Circle;
class Square;
class DrawStrategy
{
public:
virtual ~DrawStrategy() {}
virtual void draw( const Circle& circle ) const = 0;
virtual void draw( const Square& square ) const = 0;
};
70

class Shape
{
public:
Shape() = default;
};
{
public:
: radius{ rad }
class Circle;
class Square;
class DrawStrategy
{
public:
};
71

class Shape
{
public:
Shape() = default;
};
{
public:
: radius{ rad }
, drawing{ std::move(ds) }
{}
class Circle;
class Square;
class DrawStrategy
{
public:
};
72

public:
Shape() = default;
};
{
public:
: radius{ rad }
{}
private:
double radius;
std:unique_ptr<DrawStrategy> drawing;
};
{
public:
73

class Shape
{
public:
Shape() = default;
};
{
public:
: radius{ rad }
class Circle;
class Square;
class DrawStrategy
{
public:
};
74

class Shape
{
public:
Shape() = default;
};
class Circle;
class Square;
class DrawCircleStrategy
{
public:
virtual ~DrawCircleStrategy() {}
};
class DrawSquareStrategy
{
public:
virtual ~DrawSquareStrategy() {}
};
75

{
public:
Shape() = default;
};
{
public:
explicit Circle( double rad, std::unique_ptr<DrawCircleStrategy> ds )
: radius{ rad }
{}
private:
double radius;
std:unique_ptr<DrawCircleStrategy> drawing;
};
{
76

77
namespace std {
{
*dest = *first;
}
return dest;
}
} // namespace std

78
namespace std {
{
*dest = *first;
}
return dest;
}
} // namespace std
The copy() function …
… only requires InputIt (minimum requirements) and …
… only requires OutputIt (minimum requirements)
… and by that imposes minimum dependencies.

79
Guideline: Make sure interfaces don’t induce unnecessary dependencies.

81
The Dependency Inversion Principle (DIP)

82
”The Dependency Inversion Principle (DIP) tells us that the most flexible
systems are those in which source code dependencies refer only to
abstractions, not to concretions.”
(Robert C. Martin, Clean Architecture)

83
”a. High-level modules should not depend on low-level modules. Both
should depend on abstractions.
b. Abstractions should not depend on details. Details should depend on
abstractions.”

Drawing
Geometry
84
Circle DrawCircle
High-level Low-level

Drawing
Geometry
85
DrawCircle
DrawCircle
<I>
Circle
Local Inversion of
Dependencies

86
Drawing
Geometry
Circle DrawCircle
<I>
DrawCircle

87

88
Model
View
Controller

89
Model
Dependencies
View
Dependencies
Controller
Architectural
Boundary
Inversion of
Dependencies!

90
Model
<Interface> <Interface>
Dependencies
View
Dependencies
Controller
Architectural
Boundary

91
namespace std {
{
*dest = *first;
}
return dest;
}
} // namespace std

92
namespace std {
{
*dest = *first;
}
return dest;
}
} // namespace std
The copy() function …
… is in control of its own requirements (concepts);
… is implemented in terms of these requirements;
… you depend on copy(), not copy() on you (dependency inversion).

93
Guideline: Prefer to depend on abstractions (i.e. abstract classes or
concepts) instead of concrete types.

94

95
Summary
The SOLID principles are more than just a set of OO guidelines
Use the SOLID principles to reduce coupling and facilitate change
Separate concerns via the SRP to isolate changes
Design by OCP to simplify additions/extensions
Adhere to the LSP when using abstractions
Minimize the dependencies of interfaces via the ISP
Introduce abstractions to steer dependencies (DIP)

breaking_dependencies_the_solid_principles__klaus_iglberger__cppcon_2020.pdf

More Related Content

Similar to breaking_dependencies_the_solid_principles__klaus_iglberger__cppcon_2020.pdf (20)

More from VishalKumarJha10 (6)

Recently uploaded (20)

breaking_dependencies_the_solid_principles__klaus_iglberger__cppcon_2020.pdf