Что такое объектно-ориентированное программирование? Какие бонусы оно дает? А какие затраты? Это может выглядеть глупо, спрашивать подобные вопросы в то время, когда практически каждый разработчик программного обеспечения использует в каком-то виде объектно-ориентированные языки программирования. Однако этот вопрос важен, т.к. большинство из нас, использующих эти языки, применяют их без понимания Почему и без понимания Как получить наибольшие бонусы от их использования.

Из всего числа революций, которые происходили в нашей индустрии, две были настолько успешные, что они проникли в наш менталитет до такой степени, что мы принимаем их как должное. Структурное программирование и объектно-ориентированное программирование. Все современные языки программирования находятся под сильным влиянием этих двух дисциплин. Во всех современных языках нет конструкции goto и, следовательно, они подчиняются самому известному запрету в структурном программировании. Большинство основных языков программирования основаны на классах и не поддерживают функции или переменные, не входящие в класс, поэтому они, видимо, подчиняются наиболее очевидным атрибутам объектно-ориентированного программирования.

Программы, написанные на этих языках, могут выглядеть структурированными и объектно-ориентированными, но внешний вид может быть далеко не идеальным. Слишком часто сегодняшние разработчики не знают о принципах, лежащих в основе дисциплин, на которых построены их языки программирования. В другой статье я расскажу о принципах структурного программирования. В этой статье я хочу рассказать о принципах объектно-ориентированного программирования.

Эти принципы раскрывают аспекты управления зависимостями ООП в отличие от аспектов концептуализации и моделирования. Конечно, многие люди ценят эти аспекты объектно-ориентированного проектирования. Однако эти принципы очень сильно сосредоточены на управлении зависимостями.

Управление зависимостями - проблема, с которой сталкивалось большинство из нас. Всякий раз, когда мы выводим на свои экраны скверный кусок запутанного устаревшего кода, мы сталкиваемся с результатами плохого управления зависимостями. Плохое управление зависимостями приводит к тому, что код трудно изменить, он хрупкий и не подлежит повторному использованию. С другой стороны, при хорошем управлении зависимостями код остается гибким, надежным и многоразовым. Итак, управление зависимостями и, следовательно, эти принципы лежат в основе тех возможностей, которые желают применять разработчики программного обеспечения.

В программировании есть два определения, описывающих хорошую архитектуру: слабая связанность и сильная связность.

Слабая связанность означает, что модуль должен иметь как можно меньше зависимостей от других модулей. Такой модуль легко переиспользовать и удобно тестировать.

Сильная связность означает, что все классы и методы, отвечающие за близкую функциональность, должны быть сгруппированы друг с другом. Размазанная по проекту логика или, наоборот, слишком близко соседствующие методы для разных задач, превратят проект в запутанный клубок.

В основе SOLID - пять универсальных и применимых к любому объектно-ориентированному языку принципов. Все они направлены на то, чтобы привести ваш код к слаюой связанности и сильной связности.

• Принцип единственной ответсвенности  - SRP (The Single Responsibility Principle) - модуль должен отвечать только за одного пользователя или одну группу пользователей.
• Принцип открытости/закрытости - OCP (The Open Closed Principle). Программные сущности должны быть открыты для расширения, но закрыты для изменения.
• Принцип подстановки Барбары Лисков - LSP (The Liskov Substitution Principle). Функции, которые используют базовый класс должны иметь возможность использовать подтип базового класса. Наследники базового класса должны уметь делать тоже самое, что и их родители.
• Принцип разделения интерфейса - ISP (The Interface Segregation Principle). Программные сущности не должны зависеть от методов, которые они не используют.
• Принцип инверсии зависимостей - DIP (The Dependency Inversion Principle). Модули верхних уровней не должны зависеть от модулей нижних уровней.

Ознакомиться с этими принципами детальнее можно в соответствующем разделе нашего Блога.