SOLID - luk6233/interview GitHub Wiki

S - (single responsibility)
program-code-template should should have single responsibility for some functionality or data.

O - (open/close)
program entities should be flexible for extension but forbidden for changing

L - (Liskov substitution)
Functions which use some parameters with base type T should also work with parameters with subtype of type T. Example: we have:

• T type
• S subtype of T
• function f(T)
• two reference x of type T and y of type S. Liskov substitution tells us that this function should work with x as well as with y.

I - (Interface segregation)
Separate interfaces by functionality. More specific interfaces is better than creation of general-purpose interfaces.

D - (Dependency inversion)
Uses for decreasing dependencies between modules. Try to create each module apart from another modules. Class members should be interfaces or abstraction All concrete class packages must connect only through interfaces/abstract classes No class should derive from a concrete class No method should override an implemented method

Single Responsibility Principle - принцип единственной ответственности
Класс должен быть ответственен лишь за что-то одно. Если класс отвечает за решение нескольких задач, его подсистемы, реализующие решение этих задач, оказываются связанными друг с другом. Изменения в одной такой подсистеме ведут к изменениям в другой.

Open-Closed Principle - принцип открытости/закрытости
Программные сущности (классы, модули, функции) должны быть открыты для расширения, но не для модификации

Liskov Substitution Principle - принцип подстановки Барбары Лисков
Необходимо, чтобы подклассы могли бы служить заменой для своих суперклассов.
Цель этого принципа заключаются в том, чтобы классы-наследники могли бы использоваться вместо родительских классов, от которых они образованы, не нарушая работу программы. Если оказывается, что в коде проверяется тип класса, значит принцип подстановки нарушается.

Interface Segregation Principle - принцип разделения интерфейсов
Создавайте узкоспециализированные интерфейсы, предназначенные для конкретного клиента. Клиенты не должны зависеть от интерфейсов, которые они не используют.
Этот принцип направлен на устранение недостатков, связанных с реализацией больших интерфейсов.

Dependency Inversion Principle - принцип инверсии зависимости
Принцип инверсии зависимости (Dependency Inversion Principle; DIP) утверждает, что наиболее гибкими получаются системы, в которых зависимости в исходном коде направлены на абстракции, а не на конкретные реализации В языках со статической системой типов, таких как Java, это означает, что инструкции use, import и include должны ссылаться только на модули с исходным кодом, содержащим интерфейсы, абстрактные классы и другие абстрактные объявления Никаких зависимостей от конкретных реализаций не должно быть
Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.