В чем разница между «открытым / закрытым принципом» и «принципом обращения зависимостей»? - PullRequest
5 голосов
/ 30 ноября 2011

Я читаю статьи о С.О.Л.И.Д. но я не вижу никакой разницы между OCP и DIP. Посмотрите на этот пример OCP:

http://www.oodesign.com/open-close-principle.html

Код, который содержит OCP, также выполняет DIP. Кто-нибудь может привести пример кода, который содержит OCP, а не DIP?

1 Ответ

4 голосов
/ 30 ноября 2011

Я нахожу, что объяснения внедрения зависимостей и открытия / закрытия также сбивают с толку. Так не должно быть. Давайте посмотрим на статью, на которую вы ссылаетесь: http://www.oodesign.com/open-close-principle.html

В их примере a есть класс GraphicsEditor и иерархия классов фигур. На диаграмме первого класса, которую они показывают, в GraphicsEditor есть куча методов для рисования каждого вида класса формы: drawShape; DrawCircle; DrawRectangle.

Что происходит, когда вы хотите добавить класс Parallelogram? Сначала вы создаете новый класс Parallelogram, а затем изменяете класс GraphicsEditor, добавляя новый метод с именем drawParallelogram.

Это «порок», о которой говорится в статье: добавление одной новой фигуры означает, что вы должны изменить существующий код. Вы добавляете новый подкласс Shape (Parallelogram) и добавляете новый метод в GraphicsEditor (drawParallelogram).

Это может показаться не таким уж большим делом, но оно не масштабируется. Представьте команду из 20 разработчиков, одновременно работающих над программным обеспечением. Во-первых, каждый разработчик, который добавляет новую форму, должен помнить, что он должен делать две вещи: обновлять выходной код и создавать новый код. Каждый новый разработчик, который присоединится к проекту, вероятно, усвоит этот трудный путь. Во-вторых, если каждый добавляет новые фигуры каждый день, это означает, что все пытаются редактировать класс GraphicsEditor. В то же время. Это головная боль. Спроси меня, откуда я это знаю. :-) (Существует также возможность внесения ошибки в существующий код при его изменении.)

Было бы идеально, если бы вы могли добавить новый Shape в систему, не касаясь ЛЮБОГО кода в классе GraphicsEditor. Это то, что статья хочет продемонстрировать.

Посмотрите на диаграмму второго класса в статье. Каждая фигура теперь реализует свой метод рисования. GraphicsEditor нужно только знать, что существует некоторый суперкласс Shape, и что все его подклассы реализуют метод draw. GraphicsEditor больше не заботится о том, сколько существует подклассов или как их называют. Разработчики могут свободно реализовывать новые фигуры без изменения класса GraphicsEditor. Класс GraphicsEditor теперь «закрыт». Таким образом, система «открыта для расширения» - не нужно изменять существующий код для создания новых фигур. Проблема решена.

Более простой способ понять все это - изучить Шаблон проектирования посетителей . Мне не нравится объяснение этого паттерна в Википедии, поэтому я укажу вам другое место: http://sourcemaking.com/design_patterns/visitor. Я думаю, что понимание паттерна посетителя заставляет все другие термины и понятия встать на свои места.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...