SOLID
SOLID это пять принципов объектно-ориентированного программирования, которые задают архитектуру программы.
При правильной реализации это делает ваш код более расширяемым, логичным и легким для чтения.
В следующих постах я попытаюсь объяснить принципы SOLID на примере Python в как можно более простой форме, чтобы все смогли разобраться. Чтобы было очень легко взять представленные примеры и применить их на Python.
#solid @pythonnation
SOLID это пять принципов объектно-ориентированного программирования, которые задают архитектуру программы.
При правильной реализации это делает ваш код более расширяемым, логичным и легким для чтения.
В следующих постах я попытаюсь объяснить принципы SOLID на примере Python в как можно более простой форме, чтобы все смогли разобраться. Чтобы было очень легко взять представленные примеры и применить их на Python.
#solid @pythonnation
The Single Responsibility Principle
Принцип единой ответственности, то есть один класс решает одну задачу и у класса должна быть только одна причина для изменения. Если класс задает направление движения машины, то этот класс не должен выполнять какие-либо другие задачи. Таким образом, данный принцип помогает разбивать общую конструкцию на независимые модули и уменьшать межмодульную связью.
#solid @pythonnation
Принцип единой ответственности, то есть один класс решает одну задачу и у класса должна быть только одна причина для изменения. Если класс задает направление движения машины, то этот класс не должен выполнять какие-либо другие задачи. Таким образом, данный принцип помогает разбивать общую конструкцию на независимые модули и уменьшать межмодульную связью.
#solid @pythonnation
The Open Closed Principle
Принцип открытости/закрытости. Если понадобилось добавить новую функциональность к классу, то существующий класс не модифицируем, а создаем наследника класса с новыми возможностями. То есть у нас должна быть возможность расширять класс без изменения самого класса.
#solid @pythonnation
Принцип открытости/закрытости. Если понадобилось добавить новую функциональность к классу, то существующий класс не модифицируем, а создаем наследника класса с новыми возможностями. То есть у нас должна быть возможность расширять класс без изменения самого класса.
#solid @pythonnation
The Liskov Substitution Principle
Принцип подстановки Лисков, описывающий возможности заменяемости экземпляров объектов. Простыми словами: дочерний класс должен следовать принципам родительского класса и не изменять их. Пусть у нас есть класс
#solid @pythonnation
Принцип подстановки Лисков, описывающий возможности заменяемости экземпляров объектов. Простыми словами: дочерний класс должен следовать принципам родительского класса и не изменять их. Пусть у нас есть класс
Прямоугольник
с методами, задающими ширину, высоту и рассчитывающим площадь. Теперь мы захотели создать класс Квадрат
. Квадрат – тот же самый прямоугольник, но с одинаковыми сторонами. Класс Квадрат
наследуется от класса Прямоугольник
и переопределяет его методы: подставляем значения – все работает. Но если мы начнем использовать класс Прямоугольник
в качестве интерфейса, а работать будем с классом Квадрат
, мы разом изменяем оба параметра. Чтобы решить эту проблему, создается общий интерфейс для обоих классов и вместо наследования одного класса от другого использовать этот самый интерфейс.#solid @pythonnation
The Interface Segregation Principle
Принцип разделения интерфейсов. Создавайте узкоспециализированные интерфейсы и не вынуждайте клиента зависеть от неиспользуемых интерфейсов. Допустим есть класс Auto с методами комплектаций для всех автомобилей. Если мы наследуемся от интерфейса, то все методы реализованные в нем должны быть описаны в классе-потомке. В результате чего классы могут получить ненужные методы. Для решения этой проблемы мы разделяем интерфейсы.
#solid @pythonnation
Принцип разделения интерфейсов. Создавайте узкоспециализированные интерфейсы и не вынуждайте клиента зависеть от неиспользуемых интерфейсов. Допустим есть класс Auto с методами комплектаций для всех автомобилей. Если мы наследуемся от интерфейса, то все методы реализованные в нем должны быть описаны в классе-потомке. В результате чего классы могут получить ненужные методы. Для решения этой проблемы мы разделяем интерфейсы.
#solid @pythonnation
The Dependency Inversion Principle
Принцип инверсии зависимостей - зависимость должна быть от абстракций, а не от конкретики. Модули верхних уровней не должны зависеть от модулей нижних уровней. Классы и верхних, и нижних уровней должны зависеть от одних и тех же абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Наступает момент в разработке, когда наше приложение в основном состоит из модулей. Когда такое происходит, нам необходимо улучшать код используя внедрение зависимостей. Функционирование компонентов высокого уровня зависит от компонентов низкого уровня. Для создания определенного поведения вы можете использовать наследование или интерфейсы.
#solid @pythonnation
Принцип инверсии зависимостей - зависимость должна быть от абстракций, а не от конкретики. Модули верхних уровней не должны зависеть от модулей нижних уровней. Классы и верхних, и нижних уровней должны зависеть от одних и тех же абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Наступает момент в разработке, когда наше приложение в основном состоит из модулей. Когда такое происходит, нам необходимо улучшать код используя внедрение зависимостей. Функционирование компонентов высокого уровня зависит от компонентов низкого уровня. Для создания определенного поведения вы можете использовать наследование или интерфейсы.
#solid @pythonnation