Неправильно используемые шаблоны разработки

Шаблон "одиночка".. глобальное состояние часто приводит к проблемам при тестировании

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

Шаблон "наблюдатель" довольно бесполезен в C#, потому что он имеет события.

На самом деле я сказал бы, что шаблоны разработки в целом злоупотребляются, когда KISS ( Keep, Это Простой, Глупый Сохраняет это Коротким и Простым ) решение - все, что это необходимо.

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

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

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

Просто мои 0.02.

аплодисменты,

Rob

Я также сказал бы шаблон "фабрика". Подобный опыт как Eoin. В моем случае проект имел тонны фабрик, потому что некоторые люди думали, что Вы, возможно, использовали объект для локального внедрения и объекта B для удаленного, и это было абстрагировано через фабрику (который является разумной вещью сделать).

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

На самом деле то, что я вижу чаще всего, отсутствие из использования соответствующего шаблона. Типичный сценарий: я: "Эй, модуль уже имеет часть кода, что циклы через ряд объектов и выполняют операцию базы данных X на них, почему Вы не снова использовали тот код?" кодер: "хорошо, но я должен был сделать операцию Y на тех объектах". я: "что относительно того, чтобы использовать рефакторинг его для использования Шаблона "команда" для выполнения X или Y как соответствующий?"

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

Шаблоны "фабрика"...

я был сброшен с парашютом в проект прежде, где каждый MyObject в системе имел эквивалент MyObjectFactory для генерации новых экземпляров. Не было никакого понятия абстракции или не расширило классы... просто старый ClassX & ClassXFactory.

И никто не мог объяснить почему... "Это был просто способ, которым вещи всегда делались"

Единственным (помимо вышеупомянутой Singleton и ее партнера в преступлении, Фабрике) не был бы GoF, это будут методы set и методы считывания при применении к собственным свойствам объекта.

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

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

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

существует несколько исключений, о которых я могу думать:

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

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

Бобы Java использовали для экранных компонентов: Да, не может выяснить лучший способ реализовать эти "шары свойства". Отражение пригождается для этого компонента, шаблоны полезны - это - вид hacky, но работ.

Бобовые объекты ДАО/DTO. Честно я думаю, что это сомнительное использование шаблона, но они шаблон. Это делает управление свойствами через метаданные вместо кода намного более трудным, чем это должно быть, так как это должно быть отражающим. Бобовые свойства всегда связываются с некоторым внешним источником (формат базы данных, формат передачи данных, свойства компонента...) итак, почему мы копируем работу определения каждой части?

Редактирование: Украденный от комментария kyoryu, принесенного до сообщения, потому что Это - действительно идеальная сводка того, что я говорил и мог скучаться в комментариях. Необходимый с тех пор не все, кажется, получают понятие, что добавляющие средства доступа на язык только шифруют плохой шаблон разработки OO:

Короткая версия -

if (account1.balance > 1000)
{
    account1.balance = account1.balance - 1000;
    account2.balance = account2.balance + 1000;
}; = BAD CODE. 

account2.deposit(account1.withdraw(1000)); = GOOD CODE. 

вторая не требует средств доступа... †“kyoryu (Немного измененный счетом k, потому что у меня есть немного больше комнаты, чем, он сделал в своем комментарии).

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

Только для избиения точки ЕЩЕ БОЛЬШЕ обратите внимание, что с "ХОРОШИМ КОДОМ" разрабатывают, довольно очевидно, что вывод .withdraw мог быть объектом Транзакции, который содержит информацию обо всей транзакции включая ее успех, источник и место назначения и регистрирующуюся способность. Как это произошло бы с кем-то, кто пишет их код в "ПЛОХОМ КОДЕ" стиль?

Также, как Вы осуществили бы рефакторинг ПЛОХОЙ КОД для ровного использования такого объекта? Это - просто путаница.

Шаблон «Посредник» определенно потенциально может быть неправильно использован, если все виды логики объединятся в один огромный класс.

Сначала , «это зависит» от языка - некоторые структуры в некоторых языках уменьшают потребность в определенных шаблонах проектирования.

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

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

Теперь со стороны веб-сервера постоянное соединение будет таким, которое позволяет ему «проталкивать» контент в веб-браузер. . Теперь HTTP не поддерживает это. Итак, есть несколько обходных путей с javascript, когда страница в основном обновляется через некоторое время.

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

Еще один момент, который я хотел бы отметить, это то, что мы на самом деле не видим никаких обновлений страницы из-за другого трюка, который позволяет только определенные части страницы, которые будут обновлены по запросу. (ПОДСКАЗКА: AJAX)

Еще один момент, который я хотел бы отметить, заключается в том, что мы фактически не видим никаких обновлений страницы из-за другого трюка, который позволяет обновлять только определенные части страницы по запросу. (ПОДСКАЗКА: AJAX)

Еще один момент, который я хотел бы отметить, заключается в том, что мы фактически не видим никаких обновлений страницы из-за другого трюка, который позволяет обновлять только определенные части страницы по запросу. (ПОДСКАЗКА: AJAX)

Очень полезно давать имена шаблонам и немного их формализовать, я вообще не жалуюсь на книгу. Если вы не видите необходимости в использовании почти всех шаблонов здесь, значит, вы просто не работаете над очень сложным кодом (или вы много дублируете код, что я считаю ГЛАВНЫМ грехом).

ВСЕ.

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

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