11 принципов ООП от Роберта Мартина (дяди Боба)

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

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

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

В марте 1995 года я написал статью для comp.object, которая стала первым проблеском набора принципов ООП (OOD), о которых я с тех пор писал много раз. Вы увидите их опубликованными в моей книге PPP и во многих статьях на веб-сайте the objectmentor, включая известное резюме.

Эти принципы раскрывают аспекты управления зависимостями в ООП (OOD), а не аспекты концептуализации и моделирования. Это не означает, что объектно-ориентированный подход — плохой инструмент для концептуализации проблемной области или что это плохое место для создания моделей. Хотя, многие люди получают пользу от этих аспектов объектно-ориентированного программирования. Однако принципы больше сосредоточены на управлении зависимостями.

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

Первые пять принципов являются принципами проектирования классов . Вот они:

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)

Принцип инверсии зависимостей

Зависеть от абстракций, а не от конкретики.

Следующие шесть принципов касаются пакетов. В этом контексте пакет представляет собой итоговый бинарник, такой как файл .jar или dll, в отличии от понятия пространства имен, такого как пакет в java или пространство имен в C++.

Первые три принципа упаковки касаются связности пакетов, они говорят нам, что помещать внутрь пакетов:

REP (The Release Reuse Equivalency Principle)

Принцип эквивалентности повторного использования релиза

Гранула повторного использования — это гранула выпуска.

CCP (The Common Closure Principle)

Общий принцип закрытия

Классы, которые изменяются вместе, упаковываются вместе.

CRP (The Common Reuse Principle)

Общий принцип повторного использования

Классы, которые используются вместе, упаковываются вместе.

Последние три принципа касаются связей между пакетами и говорят о метриках, которые оценивают структуру пакетов в системе.

ADP (The Acyclic Dependencies Principle)

Принцип ациклических зависимостей

Граф зависимостей пакетов не должен иметь циклов.

SDP (The Stable Dependencies Principle)

Принцип стабильных зависимостей

Зависеть в сторону стабильности.

SAP (The Stable Abstractions Principle)

Принцип стабильных абстракций

Абстрактность возрастает со стабильностью.

Вы можете найти статьи, описывающие все эти принципы, в разделе «Старые статьи» на сайте cleancoder.com.