Модели проектирования увеличивают или уменьшают сложность приложения?

Question

Я только что посмотрел на этот вопрос о SQL и перешел по ссылке о DAO на википедию . И это упоминает как недостаток:

«Как и во многих шаблонах проектирования, шаблон проектирования увеличивает сложность приложения». - Википедия

Что неожиданно заставило меня задуматься, откуда взялась эта идея (потому что в ней нет цитирования). Лично я всегда считал, что шаблоны сводят к сложности приложения, но я могу быть бредовым, поэтому мне интересно, основана ли эта сложность на чем-то или нет.

Спасибо.

Answer 1

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

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

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

Answer 2

Существует печально известная болезнь, известная как «Маленький мальчик с синдромом паттерна», которая обычно поражает того, кто недавно прочитал книгу GoF впервые и внезапно видит паттерны повсюду. Это может добавить сложность и ненужную абстракцию.

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

Answer 3

Шаблоны проектирования часто приводят к дополнительным уровням абстракции вокруг проблемы, и если их неправильно обрабатывать, слишком большая абстракция может привести к сложности.

Однако, поскольку шаблоны проектирования предоставляют общий словарь для передачи идей, они также уменьшают сложность и повышают удобство обслуживания.

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

Answer 4

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

Некоторые люди могут чувствовать, что шаблоны уменьшают сложность из-за преимуществ, которые они приносят с точки зрения нефункциональных требований программного обеспечения, таких как ремонтопригодность, расширяемость, возможность повторного использования и т. Д. Однако я не согласен и рассматриваю преимущества как возврат на сложность вложения . Возможно, в некоторых случаях закономерности уменьшают сложность, но теоретическое обсуждение такого рода дает больше тепла, чем света. Почти ни один из ответов до сих пор не использовал конкретные примеры, кроме https://stackoverflow.com/a/760968/1168342.

Чтобы быть точным, многие шаблоны увеличивают случайную сложность проекта путем введения новых структур (интерфейсов, методов и т. Д.), Которых не было в проекте до шаблона. был применен.

Давайте используем Посетитель в качестве примера.

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

После применения шаблона Visitor существует дополнительная иерархия классов посетителей, которая инкапсулирует операции. Поток контроль в решении определенно более сложный, и будет сложнее для отладки (любой, кто реализовал Visitor и пытался следовать программа дважды отправит звонков с принять / посетить будет знать это).

Понимание и поддержание функций посетителя с точки зрения связные единицы менее сложны, чем альтернатива кодирования функции в каждом из элементов в фиксированной структуре, которая посетил. Это преимущество шаблона.

Трудно сказать количественно, насколько велика случайная сложность или насколько проще добавлять новые операции. Я, конечно, не согласен с ответами, которые делают общее заявление о том, что в долгосрочной перспективе сложность уменьшается с применением шаблона. Не похоже, что ваш дизайн «забывает» двойную диспетчеризацию, добавленную подходом Visitor, просто потому, что у вас есть код, который позволяет легко добавлять операции. Сложность - это цена (или налог), которую вы платите, чтобы получить преимущество в ремонтопригодности.

Шаблоны все еще должны применяться

Независимо от предполагаемого знакомства с шаблонами, любой данный шаблон должен применяться к решению. Это приложение будет отличаться каждый раз (Мартин Фаулер сказал, что паттерны - это всего лишь полуготовые решения ) Разработчики всегда должны понимать, какие классы играют, какие роли в существующем дизайне, что обусловлено существенной сложностью (сложность проблемы приложения), которая часто является нетривиальной.

В лучшем случае, понимание шаблона проектирования, примененного в уже сложном приложении, может быть тривиальным, но это не 0 усилий:

• Шаблоны не всегда применяются одинаково. Есть много вариантов паттернов - на ум приходит Proxy. Я не уверен, что все согласны с тем, как следует применять тот или иной шаблон.
• Введение одного шаблона (например, Стратегия для инкапсуляции алгоритмов) часто приводит к другим шаблонам для правильного управления вещами (например, Фабрика для создания конкретных Стратегий).
• Введение шаблона часто приводит к увеличению ответственности. Очистка объекта при использовании Factory не тривиальна (а также не документирована в GoF). Кто из вас знает о так называемой проблеме Lapsed-listener ?
• Что произойдет, если произойдут изменения в предположениях о необходимости шаблона (например, больше не будет необходимости иметь несколько инкапсулированных алгоритмов, предоставляемых шаблоном Strategy)? Это будет дополнительная работа, чтобы удалить шаблон позже. Если вы не удалите его, новые разработчики могут быть обмануты его присутствием, когда они появятся на борту. Шаблоны переплетаются между классами, играющими роли в шаблоне. Удаление не тривиально.

Эрих Гамма представил на ECOOP 2006 * анекдот, в котором один из дизайнеров решил удалить абстрактный шаблон фабрики из коммерческой многоплатформенной среды графического интерфейса (классический пример абстрактной фабрики!). Оказалось, что многоуровневая косвенность (полиморфные вызовы) в сложных графических интерфейсах была значительным ударом по производительности в клиентском коде. Клиенты жаловались на медлительность графического интерфейса, и «оптимизация» заключалась в удалении косвенных указаний. В этом случае производительность превысила ремонтопригодность; шаблон только радует кодеров, а не конечных пользователей.

DAO пример

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

метафора с вращающейся дверью

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

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

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

Answer 5

Я провел некоторое исследование на эту тему в рамках паттернов GoF. Я наблюдал колебания значений метрик OO после рефакторинга шаблона проектирования, вы можете проверить это, используя эту ссылку .

Answer 6

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

Если бы я сказал вам, что X использует связанный список с сортировкой по пузырям, было бы намного легче следовать тому, что делал программист.

Answer 7

Я думаю, что это зависит от «аудитории», то есть от разработчиков, поддерживающих кодовую базу. Если они неграмотны, то да, это может увеличить сложность, потому что большинство вещей, которые вы не понимаете, являются «сложными».

Если команда грамотна по шаблонам проектирования, то есть они понимают основы и понимают предпосылку, почему шаблоны проектирования полезны (и так важны, когда их нет), тогда я думаю, что они уменьшают сложность.

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

Мне скорее нравится это юмористическое объяснение Дилан Битти . Я рекомендую прочитать (если больше ничего не потеряйте пять минут в пятницу утром!)

Answer 8

Шаблоны проектирования увеличивают код и делят его на несколько частей. Если шаблон и концепция дизайна известны, то это не звучит сложно, но код, основанный на шаблоне дизайна, которого вы не знаете, выглядит сложным.

Answer 9

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

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

Компромисс заключается в том, что было бы справедливо сказать, что он лишил простоту (реализации), но в свою очередь сделал ее более гибкой, исключив ответственность за итерацию из контейнера и придав ей объективность, которую можно использовать повторно.

Это шаблон дизайна для вас.

Answer 10

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

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