Источники критики дизайна

Ответ 1

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

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

В качестве бонуса здесь немного мягкой критики Джеффа Этвуда и некоторые критические идеи от Марка Домина

Ответ 2

Одна большая критика в отношении шаблонов дизайна - это то, сколько "общих" моделей дизайна действительно. Например, реализация Strategy Pattern представляется более актуальной (и сложной) на языках, которые не имеют функций lambdas/first-class (сравните Java против Ruby или даже против функционального подхода С#, здесь).

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

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

Ответ 3

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

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

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

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

Ответ 4

Сам Алан Кэй очень критично относится к шаблонам, потому что он не считает, что программное обеспечение должно быть так превознесено. Вот интервью д-ра Доббса в 2012 году с Кей.

"Самая ужасная вещь в программировании - выбрать одну из 10 самых ужасных вещей в программировании - там очень популярное движение, основанное на языках шаблонов. Когда Кристофер Александр впервые сделал это в архитектуре, он смотрел 2000 лет пути что люди сделали себя комфортно, поэтому на самом деле было что-то, потому что он имел дело с геномом, который не так сильно изменился. Я думаю, что у него было несколько сотен ценных узоров. Но ошибка в попытке сделать что в вычислениях есть предположение, что мы вообще ничего не знаем о программировании. Поэтому извлечение шаблонов из сегодняшних программных приложений облагораживает их так, как они этого не заслуживают. Это на самом деле дает им больше информации".

Ответ 5

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

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

На мой взгляд, шаблоны проектирования отличаются спецификой языка (LISP имеет совершенно другой набор "шаблонов проектирования", чем Java) и специфические проблемы (в зависимости от проекта вы используете или не используете шаблон, хотя он "теоретически" применим к этому месту в вашем коде). Книга GoF - полезный компаньон для руководства по языку Java, но не набор вечных принципов о "программировании вообще".

Ответ 6

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