Наименее любимый шаблон разработки

Singleton.

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

Сервисный Локатор лучше, Внедрение зависимости / Инверсия Управления лучше все еще.

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

Классы 'Менеджера'. например.

DataManager
BusinessLogicManager
WidgetManager

Что означает **** 'менеджер'? Будьте более конкретными! Если Ваш WidgetManager имеет столько обязанностей по Виджету, что нет никакого более собственного имени, то сломайте его.

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

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

Стратегия

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

Рассмотрите следующий код 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, дающего Вам неправильные абстракции для задания, которое необходимо сделать. Это нельзя считать нормальным или приемлемым.

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

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

MVP. Это - MVC, но поврежденный.

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

Обновление

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

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

Традиционное (Форма содержит предъявителя) реализация MVP имеет другие последствия. Один являющийся, что Ваш UI теперь имеет зависимость от кода, который выполняет логику, это означает, что также потребует ссылок на все, в чем логика нуждается (сервисы и т.д.).

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

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

"О, hai, вот Ваша форма, теперь пойдите и тягомотное отбрасывание Ваши средства управления и наполните логику в UI"

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

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

Это - мое взятие на нем так или иначе....

Для больших приложений я использую структуру сохранения объектов tiopf . Это позволяет мне работать с объектами, а не наборами данных, и легко менять базы данных. Большая часть моей бизнес-логики переходит в модель бизнес-объектов (BOM), и мои формы довольно тупые. У tiopf есть несколько способов связать спецификации с формами; элементы управления, поддерживающие постоянство, Ttidataset для элементов управления с учетом данных и классы Mogel Gui Mediator для подключения к обычным элементам управления.

Для небольших и быстрых приложений я просто использую модули данных и компоненты базы данных. Главное помнить следующее:

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