Scribd
Upload
23 views18 pages

Lecture 6 - SOLID

The document outlines the SOLID principles of software design, introduced by Robert Martin, which aim to create flexible and maintainable code. It details each principle: Single Responsibility, Open Closed, Liskov’s Substitution, Interface Segregation, and Dependency Inversion, emphasizing the importance of high cohesion and low coupling in software architecture. Additionally, it advises using these principles as guidelines rather than strict rules to achieve better maintainability and extensibility in software projects.

Uploaded by

tom210979
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
23 views18 pages

Lecture 6 - SOLID

The document outlines the SOLID principles of software design, introduced by Robert Martin, which aim to create flexible and maintainable code. It details each principle: Single Responsibility, Open Closed, Liskov’s Substitution, Interface Segregation, and Dependency Inversion, emphasizing the importance of high cohesion and low coupling in software architecture. Additionally, it advises using these principles as guidelines rather than strict rules to achieve better maintainability and extensibility in software projects.

Uploaded by

tom210979
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

Askar Khaimuldin

Senior-lecturer
[email protected]
Astana IT University
▪ Introduction to design principles
▪ Single Responsibility Principle
▪ Open Closed Principle
▪ Liskov’s Substitution Principle
▪ Interface Segregation Principle
▪ Dependency Inversion Principle
Robert Martin (Uncle Bob)
▪ Classes are blocks of your application
▪ Badly designed block can cause a problem (headache)
▪ Implementing unneeded methods, re-reading code to understand what
method does
▪ Adding new features : No time to worry about project structure
▪ The term "SOLID" is an acronym for a set of practices for designing
software code and building a flexible and adaptive program
▪ This term was introduced about 20 years ago by the famous American
programming specialist Robert Martin, better known as "Uncle Bob"
▪ Rigidity – every change affects many other parts
▪ Fragility – things break in unrelated places
▪ Immobility – cannot reuse code outside of its original context
▪ Low cohesion and tight coupling
▪ Cohesion describes how much a function has a relation within a
single module
▪ Coupling refers to the interdependencies between modules
S

▪ A class should have only one reason to change *


▪ This means that class should have only one job (responsible for
one thing)
▪ There is a place for everything, and everything should be in its
own place (Clean room example)
▪ Expectations are often exaggerated
▪ By following the Single Responsibility Principle, you make sure
that your class or module has high cohesion, which means that
your class does not do more than it should
S
O
▪ You should be able to extend a class without modifying it *
▪ Objects or entities should be open for extension, but closed for
modification
▪ Extend functionality by adding new code, instead of changing
existing one
▪ Separate the behaviors, therefore, the system will not be
broken and easily extended
▪ The same as you`ve used packages and libraries. One can use
its functionalities but never change.
O
▪ What if we add Circle?
▪ It leads to change the class
AreaCalculator.
▪ It needs an interface or an
abstract class Shape with its
abstract method area().
▪ Several classes like Rectangle,
Triangle, Circle, etc. which
implements/extends Shape and
provide their own area method
implementation
L
▪ Derived classes must be substitutable for their base classes
without consumer knowing it *
▪ Let 𝜑(𝑥) be a property provable about objects of 𝑥 of type T.
Then 𝜑(𝑦) should be provable for objects 𝑦 of type S where S is
a subtype of T.
▪ Every part of code should get the expected result whatever
class instance is sent (knowing that this class implements the
same interface)
▪ In short, this principle says that to build software systems from
interchangeable parts, those parts must adhere to a contract
that allows those parts to be substituted one for another.
L
L

▪ In the first example a bird (Ostrich) which cannot fly will have some
problems. Since it is a bird, it would inherit fly method as well. But a
programmer did not consider birds which cannot fly
▪ The same inconvenience we confronted with was in previous task
(Shape, Rectangle, Square). On that example we had Square class
which had setLength() and setWidth() methods which were
unneeded for class Square
▪ A Square is NOT a Rectangle in terms of substitution rule
I
▪ Make fine-grained interfaces with specific methods *
▪ 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.
▪ A client should never depend on anything more that the
method which is used
▪ Changing a method should not affect on unrelated class
▪ Fat interface should be changed to several small and specific
ones
I
D
▪ 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
▪ It should be possible to change an implementation easily
without altering high-level code
▪ The code that implements high-level policy should not depend
on the code that implements low-level details. Rather, details
should depend on policies
D

This also applies to the


services that you create
in your projects
▪ You need to feel the balance. Use SOLID as design principles
but not as rules!
▪ Use common sense when you want to apply SOLID
▪ Avoid over-fragmenting when you apply Singular
Responsibility Principle
▪ You need to understand where to stop
▪ DON`T try to obtain SOLID, since it is the thing that helps you to
obtain maintainability
▪ The goals are easier maintainability and extensibility
▪ For a man with a hammer, everything looks like a nail
Clean Architecture: A Craftsman's Guide to Software Structure
and Design, 2018, by Robert C. Martin, Prentice Hall
▪ Part III, Chapters 7-11

You might also like