SOLID is a popular set of five design principles for object-oriented software development. The principles are: Single Responsibility Principle, which states that a class should have one responsibility; Open/Closed Principle, which states that code should be open for extension but closed for modification; Liskov Substitution Principle, which states that subclasses should not break the functionality of parent classes; Interface Segregation Principle, which states that clients should not depend on interfaces they do not use; and Dependency Inversion Principle, which states that high-level modules should not depend on low-level modules and abstractions should not depend on details.

1. SOLID DESIGN PRINCIPLES
SETS OF DESIGN PRINCIPLES IN OBJECT-ORIENTED SOFTWARE DEVELOPMENT

2. WHAT IS SOLID?
SOLID is one of the most popular sets of design principles in object-oriented software development. It’s a
mnemonic acronym for the following five design principles:
 Single Responsibility Principle
 Open/Closed Principle
 Liskov Substitution Principle
 Interface Segregation Principle
 Dependency Inversion

3. SINGLE RESPONSIBILITY PRINCIPLE
Robert C. Martin describes it as:
‘’A class should have one, and only one, reason to change.’’
Do you know Robert?
Robert C. Martin, colloquially known as "Uncle Bob", is an American software engineer and instructor. He is best known
for being one of the authors of the Agile Manifesto and for developing several software design principles.
Recommend to check his blog: http://blog.cleancoder.com/

4. SINGLE RESPONSIBILITY PRINCIPLE
Why should you use it and what happens if you ignore it?
 Frequency and effects of changes
 Easier to understand

5. SINGLE RESPONSIBILITY PRINCIPLE
A simple question to validate your design
‘’What is the responsibility of your class/component/microservice?’’
Here is an example

6. OPEN/CLOSED PRINCIPLE
“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for
modification.”

7. OPEN/CLOSED PRINCIPLE
It tells you to write your code so that you will be able to add new functionality without changing the
existing code. That prevents situations in which a change to one of your classes also requires you to adapt
all depending classes.
Here is an exmple.

8. LISKOV SUBSTITUTION PRINCIPLE
Child classes should never break the parent class' type definitions.
Or
Subtypes must be substitutable for their base types.

9. INTERFACE SEGREGATION PRINCIPLE
“Clients should not be forced to depend upon interfaces that they do not use.”

10. DEPENDENCY INVERSION PRINCIPLE
1. High-level modules should not depend on low-level modules. Both should
depend on abstractions.
2. Abstractions should not depend on details. Details should depend on
abstractions.

11. THANKS FOR YOUR ATTENTION
MAHMOUD ASADI . ASADI.PUB@GMAIL.COM