One class - one task, one class should be responsible for one thing. It is better to organize the code in such a way that when changing, the least number of modules are used.

       Pros:

• modules appear, readability increases;
• it becomes easier to make changes, because the code becomes less connected;
• one class solves one problem;
• easier to conduct parallel development and work with GIT;
• easier to test;

Single responsibility principle

Class

getField

print

log

Class

getField

Logger

log

Printer

printToPdf

printToExcel

PrinterToPdf

printToPdf

PrinterToExcel

printToExcel

Single responsibility principle

       Entities must be open for extension but closed for modification.

       Changing existing code is bad because it is already tested and working. Therefore, it is better to add new functionality by adding a new entity, and not by changing an existing entity.

       Pros:

• there is no need for regression testing when adding new functionality;
• less error probability;

Open/closed principle

entity 1

entity 2

entity 3

entity 4

new functional

functional

functional

functional

new functional

Open/closed principle

      Entities that use the parent type must work the same way with child classes.

      Inherited class should complement, not replace, the behavior of the base class.

      The base class must have methods that are available to all child classes.

       Pros:

• reveals problematic abstractions and hidden connections between entities;
• make the behavior of modules predictable;

liskov substitution principle

Class 1

first()

second()

Class 2

extends

first()

second()

third()

Class 3

first()

second()

third()

uniqualMethod3()

Class 4

first()

second()

third()

uniqualMethod4()

Class 5

first()

second()

third() { return: null }

uniqualMethod5()

extends

liskov substitution principle

      Program entities should not depend on methods they do not use.

      It's related to the first and third principles.

      The principle is to divide large interfaces into smaller, highly specialized that solve one task.

        Pros:

• there are no methods that are not used;
• the code becomes less coupled (easier to maintain the code)

interface segregation principle

Interface1

method1()

method2()

Class1 implements Interface 1

method1()

method2()

method3()

method3()

Class2 implements Interface 1

method1()

method2()

method3()

Class3 implements Interface 1

method1()

method2()

method3()

interface segregation principle

Interface1

method1()

Class 1

method1()

method2()

Class 2

method1()

method2()

Class 3

method1()

method3()

method3()

Interface2

method2()

Interface3

method3()

Class 1 implements

Interface1, Interface2, Interface3

Class 2 implements

Interface1, Interface2

Class 3 implements

Interface1, Interface3

interface segregation principle

      High-level modules should not depend on low-level modules. 

All of them must depend on abstractions.

      Abstractions should not depend on details. Details must depend on abstractions.

        Pros:

        Pros:

• connections between higher and lower level software modules are broken;
• solves the problems of unsuccessful program design;

dependency inversion principle

dependency inversion principle

dependency inversion principle

Low level

High level