Software Architecture:

Meta and SOLID Principles

Elias Fofanov

http://engineerspock.com
What is SOLID?

SOLID stands for SRP, OCP, LSP, and DIP.

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle
Improve OO-programming Skills

• Meta principles on which all the other

development principles are based
• Symptoms of code defects
• Foundations of SOLID principles
• Detect the violations of SOLID principles and how to fix the
problems
• How meta and SOLID principles are related to each other
and how to find the balance between them
Why we need SOLID?

• Poor design is a regular case

• Powerful programming language doesn’t guarantee good design
• Designing skills are prerequisite for serious programming
Requirements

• Aimed at middle and senior developers

• Experience in C#
• Remark for Juniors:
have at least of half of a year of real-world experience in
enterprise development
Inside the Box

• Plenty of code examples

• Related Design Patterns
• Contradictions between Principles
• SRP, OCP, LSP, ISP, DIP
• Dependency Injection, Inversion of Control, IoC-Container
• How to build an IoC-Container
• Architectural Implications of DI
• DRY, KISS, YAGNI, SoC, CQS, Law of Demeter, PoLA
• Info Hiding and Encapsulation
• API Development Principles
• SOLID VS YAGNI
• OCP VS YAGNI
• What is Architecture and Design
Enroll!
SRP Outline

• Learn what SRP means in its essence

• Learn at what levels SRP can be applied
• Look at several examples of SRP violation
• Learn how to adhere to SRP
Every object should have a
single responsibility,
and that responsibility
should be entirely encapsulated
by the class.
“There should never be more than
one reason for a class to change.”

Robert C. Martin aka Uncle Bob

Calculating Responsibilities

• Axes of changing requirements

• API users are the source of changes
More responsibilities a class has,
the more likely it’s going to be changed.
Applying SRP we want to separate
different concerns.
A class should do one thing,
and do it well!
SRP can be applied at different levels:
• function
• object
• module
Classes with too many responsibilities
are hard to understand!
When SRP is violated, responsibilities
start to collate with each other.
They become coupled.
Gather all the same responsibilities
together and separate from each other
those which are different.
A set of functions or an interface
is considered cohesive
when each function
is closely related to another.
Coupling indicates
how dependent modules are
on the inner working of each other.
Common SRP Violation

• Mixing logic and infrastructure

• A class or a module serves different layers
Next Video
SRP Violation Demo
“There should never be more than
one reason for a class to change.”

Robert C. Martin aka Uncle Bob

Related Patterns

 Applying the SRP leads to appearance of many small classes

 It is hard to understand the API of too many small classes
 “Façade” design pattern may come to the rescue
The Façade’s responsibility
is to bring the functionality
required by a client together.
Reasons for applying Façade

• Provide for a client a simple API for interaction with a set of complex objects
• Provide for a client a cleaner API for interaction with poorly designed API
Façade Diagram
Related Patterns

• Façade
• Decorator
• Composite
Composite pattern allows to compose
objects into tree structures to represent
part-whole hierarchies, letting clients
treat individual objects and compositions
of objects uniformly.
Decorator allows the behavior to be
added to an individual object, either
statically or dynamically, without
affecting the behavior of other objects
from the same class.
SRP Conclusion

• Applying SRP we want to separate different concerns

A class should do one thing, and do it well!
• Apply SRP at different levels: function, object, module
• Classes with many responsibilities are hard to understand
• When SRP is violated, responsibilities start to collate with each other
• Don’t abuse the SRP
• Apply Façade pattern to simplify the API
• Modules that change frequently should be isolated
from the other parts of the system
SOLID and Meta Principles
Writing SOLID Code

Elias Fofanov

http://engineerspock.com
What is Design?

• Design of software is source code itself

• Architecture is the shape which code takes

https://www.flickr.com/photos/deapeajay/2267569368
Specification of Software?

• Source code specifies how software works

• Final product is a running program
 Building Software

• Big design upfront is

very expensive in software development
• No guarantee that we
take into account all the possible requirements
• Requirements tend to change very quickly
• Keep the design as clean as you can
https://cdn.pixabay.com/photo/2015/11/06/12/54/bill-1027378_960_720.jpg
 Design Smells
• Rigidity
• Fragility
• Immobility
• Viscosity
• Needless Complexity

https://cdn.pixabay.com/photo/2014/11/26/15/20/pig-546307_960_720.jpg
 Rigidity
• Software is rigid
if the cost of making a single change is very high
• Reason - tight coupling between modules

https://upload.wikimedia.org/wikipedia/commons/2/29/Rigid_bodies.jpg
 Fragility

• Software is fragile if small changes

in one module cause bugs appearance in other
• Reason – tight coupling between components

https://cdn.pixabay.com/photo/2017/02/16/19/41/package-2072221_960_720.jpg
 Immobility
• Software is immobile when
it’s components can’t be reused in other systems
• Reason - tight coupling between components

https://www.flickr.com/photos/timevanson/27895941531
 Viscosity

• The software is viscose when adding a single

feature evokes dealing with tons of aspects
• Reason - tight coupling between components

https://www.flickr.com/photos/shlevich/4564587901
Needless Complexity
• Software is needlessly complex if
developers are trying to forecast the future,
introducing excessive points of extension

• Concentrate on the current requirements,

constructing the supple architecture
which can bend to meet new requirements

https://www.flickr.com/photos/46183897@N00/7614916304
Dependency Management

• OO-languages can harness

the power of dynamic dispatch

• Proper dependency management - key to a good architecture

SOLID Principles
• SRP – Single Responsibility Principle
• OCP – Open/Closed Principle
• LSP – Liskov Substitution Principle
• ISP – Interface Segregation Principle
• DIP – Dependency Inversion Principle
SOLID Principles
• Not bound to any technology
• SOLID is not a goal
• “SOLIDness” is not measurable
Next Video
SRP Outline