Спойлер: к игре Metal Gear Solid пять принципов объектно-ориентированного программирования отношения не имеют.
SOLID – это какая-то игра?
Не совсем. SOLID – пять принципов объектно-ориентированного программирования, которые задают архитектуру программы.
Разберем по буквам:
S (The Single Responsibility Principle ) – принцип единой ответственности, то есть один класс решает одну задачу и у класса должна быть только одна причина для изменения. Если класс задает направление движения машины, то этот класс не должен выполнять какие-либо другие задачи. Таким образом, данный принцип помогает разбивать общую конструкцию на независимые модули и уменьшать межмодульную связью.
O (The Open Closed Principle) – принцип открытости/замкнутости. Если понадобилось добавить новую функциональность к классу, то существующий класс не модифицируем, а создаем наследника класса с новыми возможностями. То есть у нас должна быть возможность расширять класс без изменения самого класса.
Что такое SOLID? Простыми словами о принципах ООП
L (The Liskov Substitution Principle) – принцип подстановки Лисков, описывающий возможности заменяемости экземпляров объектов. Простыми словами: дочерний класс должен следовать принципам родительского класса и не изменять их. Пусть у нас есть класс Прямоугольник с методами, задающими ширину, высоту и рассчитывающим площадь. Теперь мы захотели создать класс Квадрат.
Квадрат – тот же самый прямоугольник, но с одинаковыми сторонами. Класс Квадрат наследуется от класса Прямоугольник и переопределяет его методы: подставляем значения – все работает. Но если мы начнем использовать класс Прямоугольник в качестве интерфейса, а работать будем с классом Квадрат, мы разом изменяем оба параметра. Чтобы решить эту проблему, создается общий интерфейс для обоих классов и вместо наследования одного класса от другого использовать этот самый интерфейс.
I (The Interface Segregation Principle) – принцип разделения интерфейсов. Создавайте узкоспециализированные интерфейсы и не вынуждайте клиента зависеть от неиспользуемых интерфейсов. Допустим есть класс Auto с методами комплектаций для всех автомобилей. Если мы наследуемся от интерфейса, то все методы реализованные в нем должны быть описаны в классе-потомке.
В результате чего классы могут получить ненужные методы. Для решения этой проблемы мы разделяем интерфейсы.
D (The Dependency Inversion Principle) – принцип инверсии зависимостей. Сущности должны зависеть от абстракций, а не от чего-то конкретного. Допустим, у нас есть низкоуровневый класс HTTPService с логикой запроса и высокоуровневый класс HTTP, в конструктор которого мы передаем низкоуровневый модуль.
После чего вызываем его методы и нарушаем принцип инверсии зависимости: высокоуровневый модель зависит от низкоуровневого. Для решения проблемы мы создаем отдельный интерфейс и передаем его в высокоуровневый интерфейс. Теперь наш класс не зависит от низкоуровневого модуля.
Я так ничего и не понял, можно объяснить доступно?
Конечно. 20 января мы провели бесплатный вебинар «Простой рабочий алгоритм использования SOLID на практике» , на котором подробно рассказали о принципах SOLID. Вот запись вебинара:
Просто о SOLID (Принципы SOLID)
Слова, слова, слова… SOLID-принципы нужны, чтобы почувствовать себя умным? Какой профит?
SOLID-принципы нужны, чтобы быть образованным. Знание аббревиатур и понимание смыслов, стоящих за ними, расширяет инструментарий разработчика и делает его конкурентноспособным.
Чем дальше в лес, тем больше дров
Помимо SOLID-принципов, разрабу пригодятся паттерны проектирования, тестирование, виды сложности, абстракции и многое другое.
Кстати, 4 мая стартует наш курс «Архитектуры и шаблоны проектирования» , на котором вы научитесь:
- строить архитектуры приложений, которые позволяют не снижать скорость разработки по мере развития проекта;
- писать модульные тесты на Mock-объектах;
- применять SOLID принципы не только в объектно-ориентированных языках;
- использовать CI и IoC контейнеры.
Что нужно для старта?
Для старта достаточно знать любой объектно-ориентированный язык программирования: Python, Java, PHP, C++, JavaScript, C# и др.
Игра стоит свеч?
Да, безусловно. Фундаментальные знания на земле не валяются.
Источник: dzen.ru
Принципы SOLID, о которых должен знать каждый разработчик
Объектно-ориентированное программирование принесло в разработку ПО новые подходы к проектированию приложений. В частности, ООП позволило программистам комбинировать сущности, объединённые некоей общей целью или функционалом, в отдельных классах, рассчитанных на решение самостоятельных задач и независимых от других частей приложения. Однако само по себе применение ООП не означает, что разработчик застрахован от возможности создания непонятного, запутанного кода, который тяжело поддерживать. Роберт Мартин, для того, чтобы помочь всем желающим разрабатывать качественные ООП-приложения, разработал пять принципов объектно-ориентированного программирования и проектирования, говоря о которых, с подачи Майкла Фэзерса, используют акроним SOLID.
Материал, перевод которого мы сегодня публикуем, посвящён основам SOLID и предназначен для начинающих разработчиков.
Что такое SOLID?
Вот как расшифровывается акроним SOLID:
- S: Single Responsibility Principle (Принцип единственной ответственности).
- O: Open-Closed Principle (Принцип открытости-закрытости).
- L: Liskov Substitution Principle (Принцип подстановки Барбары Лисков).
- I: Interface Segregation Principle (Принцип разделения интерфейса).
- D: Dependency Inversion Principle (Принцип инверсии зависимостей).
Принцип единственной ответственности
«Одно поручение. Всего одно.» — Локи говорит Скурджу в фильме «Тор: Рагнарёк».
Каждый класс должен решать лишь одну задачу.
Класс должен быть ответственен лишь за что-то одно. Если класс отвечает за решение нескольких задач, его подсистемы, реализующие решение этих задач, оказываются связанными друг с другом. Изменения в одной такой подсистеме ведут к изменениям в другой.
Обратите внимание на то, что этот принцип применим не только к классам, но и к компонентам программного обеспечения в более широком смысле.
Например, рассмотрим этот код:
class Animal < constructor(name: string)< >getAnimalName() < >saveAnimal(a: Animal) < >>
Класс Animal , представленный здесь, описывает какое-то животное. Этот класс нарушает принцип единственной ответственности. Как именно нарушается этот принцип?
В соответствии с принципом единственной ответственности класс должен решать лишь какую-то одну задачу. Он же решает две, занимаясь работой с хранилищем данных в методе saveAnimal и манипулируя свойствами объекта в конструкторе и в методе getAnimalName .
Как такая структура класса может привести к проблемам?
Если изменится порядок работы с хранилищем данных, используемым приложением, то придётся вносить изменения во все классы, работающие с хранилищем. Такая архитектура не отличается гибкостью, изменения одних подсистем затрагивают другие, что напоминает эффект домино.
Для того чтобы привести вышеприведённый код в соответствие с принципом единственной ответственности, создадим ещё один класс, единственной задачей которого является работа с хранилищем, в частности — сохранение в нём объектов класса Animal :
class Animal < constructor(name: string)< >getAnimalName() < >> class AnimalDB < getAnimal(a: Animal) < >saveAnimal(a: Animal) < >>
Вот что по этому поводу говорит Стив Фентон: «Проектируя классы, мы должны стремиться к тому, чтобы объединять родственные компоненты, то есть такие, изменения в которых происходят по одним и тем же причинам. Нам следует стараться разделять компоненты, изменения в которых вызывают различные причины».
Правильное применение принципа единственной ответственности приводит к высокой степени связности элементов внутри модуля, то есть к тому, что задачи, решаемые внутри него, хорошо соответствуют его главной цели.
Принцип открытости-закрытости
Программные сущности (классы, модули, функции) должны быть открыты для расширения, но не для модификации.
Продолжим работу над классом Animal .
class Animal < constructor(name: string)< >getAnimalName() < >>
SOLID-принципы: что такое и зачем нужны. Разбираем по буквам
Спойлер: к игре Metal Gear Solid пять принципов объектно-ориентированного программирования отношения не имеют.
SOLID – это какая-то игра?
Не совсем. SOLID – пять принципов объектно-ориентированного программирования, которые задают архитектуру программы.
Разберем по буквам:
S (The Single Responsibility Principle) – принцип единой ответственности, то есть один класс решает одну задачу и у класса должна быть только одна причина для изменения. Если класс задает направление движения машины, то этот класс не должен выполнять какие-либо другие задачи. Таким образом, данный принцип помогает разбивать общую конструкцию на независимые модули и уменьшать межмодульную связью.
O (The Open Closed Principle) – принцип открытости/замкнутости. Если понадобилось добавить новую функциональность к классу, то существующий класс не модифицируем, а создаем наследника класса с новыми возможностями. То есть у нас должна быть возможность расширять класс без изменения самого класса.
L (The Liskov Substitution Principle) – принцип подстановки Лисков, описывающий возможности заменяемости экземпляров объектов. Простыми словами: дочерний класс должен следовать принципам родительского класса и не изменять их. Пусть у нас есть класс Прямоугольник с методами, задающими ширину, высоту и рассчитывающим площадь.
Теперь мы захотели создать класс Квадрат . Квадрат – тот же самый прямоугольник, но с одинаковыми сторонами. Класс Квадрат наследуется от класса Прямоугольник и переопределяет его методы: подставляем значения – все работает. Но если мы начнем использовать класс Прямоугольник в качестве интерфейса, а работать будем с классом Квадрат , мы разом изменяем оба параметра. Чтобы решить эту проблему, создается общий интерфейс для обоих классов и вместо наследования одного класса от другого использовать этот самый интерфейс.
I (The Interface Segregation Principle) – принцип разделения интерфейсов. Создавайте узкоспециализированные интерфейсы и не вынуждайте клиента зависеть от неиспользуемых интерфейсов. Допустим есть класс Auto с методами комплектаций для всех автомобилей. Если мы наследуемся от интерфейса, то все методы реализованные в нем должны быть описаны в классе-потомке.
В результате чего классы могут получить ненужные методы. Для решения этой проблемы мы разделяем интерфейсы.
D (The Dependency Inversion Principle) – принцип инверсии зависимостей. Сущности должны зависеть от абстракций, а не от чего-то конкретного. Допустим, у нас есть низкоуровневый класс HTTPService с логикой запроса и высокоуровневый класс HTTP , в конструктор которого мы передаем низкоуровневый модуль.
После чего вызываем его методы и нарушаем принцип инверсии зависимости: высокоуровневый модель зависит от низкоуровневого. Для решения проблемы мы создаем отдельный интерфейс и передаем его в высокоуровневый интерфейс. Теперь наш класс не зависит от низкоуровневого модуля.
Я так ничего и не понял, можно объяснить доступно?
Конечно. 20 января мы провели бесплатный вебинар «Простой рабочий алгоритм использования SOLID на практике», на котором подробно рассказали о принципах SOLID. Вот запись вебинара:
Слова, слова, слова… SOLID-принципы нужны, чтобы почувствовать себя умным? Какой профит?
SOLID-принципы нужны, чтобы быть образованным. Знание аббревиатур и понимание смыслов, стоящих за ними, расширяет инструментарий разработчика и делает его конкурентноспособным.
Чем дальше в лес, тем больше дров
Помимо SOLID-принципов, разрабу пригодятся паттерны проектирования, тестирование, виды сложности, абстракции и многое другое.
Кстати, 15 февраля стартует наш курс «Архитектуры и шаблоны проектирования» , на котором вы научитесь:
- строить архитектуры приложений, которые позволяют не снижать скорость разработки по мере развития проекта;
- писать модульные тесты на Mock-объектах;
- применять SOLID принципы не только в объектно-ориентированных языках;
- использовать CI и IoC контейнеры.
Что нужно для старта?
Для старта достаточно знать любой объектно-ориентированный язык программирования: Python, Java, PHP, C++, JavaScript, C# и др.
Игра стоит свеч?
Да, безусловно. Фундаментальные знания на земле не валяются.
Источник: proglib.io