Наименее любимый дизайн шаблона - PullRequest
5 голосов
/ 26 сентября 2008

ОК, я не ищу анти-паттерны - я ищу вещи, которые на самом деле не являются паттернами, или, возможно, паттернами, которые злоупотребляли.

Мой личный наименее любимый - это шаблон "Помощник".

например. Мне нужно создать запрос SQL, поэтому вызовите SQLQueryHelper. Для этого нужно обработать некоторые строки, поэтому он вызывает StringHelper. И т. Д.

Понимаете, на самом деле это не совсем шаблон дизайна ...

[править] Неужели вы, люди, которые проголосовали за это, не думаете, что вам следует добавить конструктивное замечание?

Ответы [ 6 ]

25 голосов
/ 26 сентября 2008

Singleton.

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

Сервисный локатор лучше, инъекция зависимостей / инверсия управления еще лучше.

Большинство ссылок на статью в википедии о том, почему это зло.

11 голосов
/ 26 сентября 2008

«Менеджер» классов. например,

DataManager
BusinessLogicManager
WidgetManager

Что означает **** «менеджер»? Более конкретно! Если ваш WidgetManager имеет так много обязанностей Widget, что нет более конкретного имени, разбейте его.

Это разговор, который у меня был слишком много раз с самим собой, когда я смотрел на старый код.

5 голосов
/ 26 сентября 2008

Я думаю, что Шаблоны проектирования не следует использовать вслепую, реализуя их просто потому, что это круто: они имеют четко определенный КОНТЕКСТ, и их использование, когда это уместно, МОЖЕТ помочь, но в любом другом случае это просто трата времени , когда не помешает правильному функционированию системы.

4 голосов
/ 07 июня 2009

Мой наименее любимый шаблон - «Поместить« Помощник »или« Менеджер »в конец имени класса».

РЕДАКТИРОВАТЬ: И я доказал, что я неудачливый программист, как сказал Крис, забыв "Util".

2 голосов
/ 23 марта 2009

Стратегия

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

Рассмотрим следующий код на Haskell:

ascending = sortBy compare somelist
descending = sortBy (flip compare) somelist
pairsBySecondComponent = sortBy (comparing snd) somelist

Это шаблон стратегии в действии: compare, (flip compare) и (comparing snd) являются конкретными стратегиями в этом случае (это простые старые функции), а сигнатура функции a -> a -> Ordering является "интерфейсом" стратегии .

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

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

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

1 голос
/ 26 сентября 2008

MVP. Это MVC, но сломан.

О нет, но подождите, разработка приложения - это совсем другое, чем следование хорошей практике, такой как "Это просто представление".

Обновление

Я ссылаюсь на «Это просто взгляд» из книги «Прагматичный программист». Моя главная проблема заключается в том, что почти каждая реализация MVP имеет представление, держащееся за докладчика и говорящее докладчику, чтобы он что-то делал. Это концептуально задом наперед. Пользовательский интерфейс не должен зависеть от логики. Это просто вид. Логика является основной причиной для приложения, а то, как эта логика отображается, является второстепенной задачей. Я мог бы использовать одну winform, или я мог бы использовать много. Черт, я мог бы передать все это в текст ASCII или создать «представление», отправив обвинения по проводу, прикрепленному к художнику, который отображает представление посредством интерактивного танца.

Практически говоря, эта предпосылка имеет несколько жизнеспособных целей. Некоторые из контроллеров, которые я написал в прошлом, имеют МНОГИЕ представления, которые внешне доступны и могут быть вставлены в пользовательский интерфейс, если приложение сочтет нужным. Рассмотрим живой поток данных. Я мог бы представить это в виде статистики, линейных графиков, круговых диаграмм. Возможно, все одновременно! Тогда представление, удерживающее контроллер, выглядит довольно глупо, родитель - это контроллер, а потомки - это представления.

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

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

В конце дня кажется, что люди крутят вещи, пытаясь оправдать модель, которая сломана. Я лично убежден, что шаблон MVP существует просто как попытка рационализировать работу приложений Visual Studio Windows Forms. Они начинают с менталитета «Сначала форма».

"О, привет, вот твоя форма, теперь иди и перетащи свои элементы управления и добавь логику в пользовательский интерфейс"

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

Я утверждаю, что MVC - это просто MVC, MVP - это бастардизация паттерна. Фактически, все определение MVC является своего рода задом наперед. Важной частью этого является разделение интересов. Пользовательский интерфейс, логика, данные и / или услуги, которые вы потребляете. Держите это отдельно. Вы не реализуете MVC для этого, вы делаете это, и в результате вы получаете форму MVC . MVP не вписывается в это, потому что вы не в конечном итоге с MVP, если вы начинаете думать о разделении проблем, вы в конечном итоге с MVP, если вы застряли в земле "Form First", и вы чувствуете, что должны делать вещи немного больше MVCish.

В любом случае, это мое мнение ...

...