Спойлер: к игре 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-принципов, разрабу пригодятся паттерны проектирования, тестирование, виды сложности, абстракции и многое другое. Кстати, 9 февраля стартует наш курс «Архитектуры и шаблоны проектирования», на котором вы научитесь: строить архитектуры приложений, которые позволяют не снижать скорость разработки по мере развития проекта; писать модульные тесты на Mock-объектах; применять SOLID принципы не только в объектно-ориентированных языках; использовать CI и IoC контейнеры. Что нужно для старта? Для старта достаточно знать любой объектно-ориентированный язык программирования: Python, Java, PHP, C++, JavaScript, C# и др. Игра стоит свеч? Да, безусловно. Фундаментальные знания на земле не валяются. Интересно, хочу записаться
Не совсем. SOLID – пять принципов объектно-ориентированного программирования, которые задают архитектуру программы.
Разберем по буквам:
S (The Single Responsibility Principle) – принцип единой ответственности, то есть один класс решает одну задачу и у класса должна быть только одна причина для изменения. Если класс задает направление движения машины, то этот класс не должен выполнять какие-либо другие задачи. Таким образом, данный принцип помогает разбивать общую конструкцию на независимые модули и уменьшать межмодульную связью.
O (The Open Closed Principle) – принцип открытости/замкнутости. Если понадобилось добавить новую функциональность к классу, то существующий класс не модифицируем, а создаем наследника класса с новыми возможностями. То есть у нас должна быть возможность расширять класс без изменения самого класса.
L (The Liskov Substitution Principle) – принцип подстановки Лисков, описывающий возможности заменяемости экземпляров объектов. Простыми словами: дочерний класс должен следовать принципам родительского класса и не изменять их. Пусть у нас есть класс Прямоугольник с методами, задающими ширину, высоту и рассчитывающим площадь. Теперь мы захотели создать класс Квадрат. Квадрат – тот же самый прямоугольник, но с одинаковыми сторонами. Класс Квадрат наследуется от класса Прямоугольник и переопределяет его методы: подставляем значения – все работает. Но если мы начнем использовать класс Прямоугольник в качестве интерфейса, а работать будем с классом Квадрат, мы разом изменяем оба параметра. Чтобы решить эту проблему, создается общий интерфейс для обоих классов и вместо наследования одного класса от другого использовать этот самый интерфейс.
Прямоугольник
Квадрат
I (The Interface Segregation Principle) – принцип разделения интерфейсов. Создавайте узкоспециализированные интерфейсы и не вынуждайте клиента зависеть от неиспользуемых интерфейсов. Допустим есть класс Auto с методами комплектаций для всех автомобилей. Если мы наследуемся от интерфейса, то все методы реализованные в нем должны быть описаны в классе-потомке. В результате чего классы могут получить ненужные методы. Для решения этой проблемы мы разделяем интерфейсы.
Auto
D (The Dependency Inversion Principle) – принцип инверсии зависимостей. Сущности должны зависеть от абстракций, а не от чего-то конкретного. Допустим, у нас есть низкоуровневый класс HTTPService с логикой запроса и высокоуровневый класс HTTP, в конструктор которого мы передаем низкоуровневый модуль. После чего вызываем его методы и нарушаем принцип инверсии зависимости: высокоуровневый модель зависит от низкоуровневого. Для решения проблемы мы создаем отдельный интерфейс и передаем его в высокоуровневый интерфейс. Теперь наш класс не зависит от низкоуровневого модуля.
HTTPService
HTTP
Конечно. 20 января мы провели бесплатный вебинар «Простой рабочий алгоритм использования SOLID на практике», на котором подробно рассказали о принципах SOLID. Вот запись вебинара:
SOLID-принципы нужны, чтобы быть образованным. Знание аббревиатур и понимание смыслов, стоящих за ними, расширяет инструментарий разработчика и делает его конкурентноспособным.
Помимо SOLID-принципов, разрабу пригодятся паттерны проектирования, тестирование, виды сложности, абстракции и многое другое.
Кстати, 9 февраля стартует наш курс «Архитектуры и шаблоны проектирования», на котором вы научитесь:
Для старта достаточно знать любой объектно-ориентированный язык программирования: Python, Java, PHP, C++, JavaScript, C# и др.
Да, безусловно. Фундаментальные знания на земле не валяются.
Интересно, хочу записаться
ΠΠ°Ρ Π°Π΄ΡΠ΅Ρ email Π½Π΅ Π±ΡΠ΄Π΅Ρ ΠΎΠΏΡΠ±Π»ΠΈΠΊΠΎΠ²Π°Π½. ΠΠ±ΡΠ·Π°ΡΠ΅Π»ΡΠ½ΡΠ΅ ΠΏΠΎΠ»Ρ ΠΏΠΎΠΌΠ΅ΡΠ΅Π½Ρ *
Π‘ΠΎΡ ΡΠ°Π½ΠΈΡΡ ΠΌΠΎΡ ΠΈΠΌΡ, email ΠΈ Π°Π΄ΡΠ΅Ρ ΡΠ°ΠΉΡΠ° Π² ΡΡΠΎΠΌ Π±ΡΠ°ΡΠ·Π΅ΡΠ΅ Π΄Π»Ρ ΠΏΠΎΡΠ»Π΅Π΄ΡΡΡΠΈΡ ΠΌΠΎΠΈΡ ΠΊΠΎΠΌΠΌΠ΅Π½ΡΠ°ΡΠΈΠ΅Π².
Δ
ΠΡΠΎΡ ΡΠ°ΠΉΡ ΠΈΡΠΏΠΎΠ»ΡΠ·ΡΠ΅Ρ Akismet Π΄Π»Ρ Π±ΠΎΡΡΠ±Ρ ΡΠΎ ΡΠΏΠ°ΠΌΠΎΠΌ. Π£Π·Π½Π°ΠΉΡΠ΅, ΠΊΠ°ΠΊ ΠΎΠ±ΡΠ°Π±Π°ΡΡΠ²Π°ΡΡΡΡ Π²Π°ΡΠΈ Π΄Π°Π½Π½ΡΠ΅ ΠΊΠΎΠΌΠΌΠ΅Π½ΡΠ°ΡΠΈΠ΅Π².