Когда шаблон проектирования может ухудшить качество вашего программного обеспечения?[закрыто]

Question

Когда шаблон проектирования может ухудшить качество вашего программного обеспечения?

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

Answer 1

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

• Добавление множества блоков try/catch/finally может заставить программиста почувствовать, что у него есть схема обработки ошибок, хотя на самом деле это не так.
• Замена sql хранимыми процедурами может заставить программистов чувствовать, что у них есть уровень доступа к данным, который волшебным образом обеспечивает им эффективность, возможность повторного использования и инкапсуляцию, хотя на самом деле это не так.
• Использование классов заставляет многих программистов верить, что они занимаются объектно-ориентированным программированием, хотя на самом деле это не так (или только поверхностно изучают объектно-ориентированное программирование).

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

Решение?Трудно сказать.Вы не ошибетесь, поручив младшему разработчику Код завершен или что-то в этом роде, чтобы помочь им понять, что речь идет о применении принципов к конкретные ситуации, и что великие разработчики сохраняют простоту.

Answer 2

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

Answer 3

Когда его название singleton

Answer 4

Шаблон проектирования - это просто способ именования и документирования общей структуры кода. Таким образом, вы не должны делать вывод, что все шаблоны хороши. Люди, которые хорошо справляются с документированием шаблонов проектирования (например, GoF), всегда включают в описание шаблона раздел, описывающий, когда следует и не следует использовать шаблон. Таким образом, половина смысла большинства книг по шаблонам дизайна - ответить на вопрос «Когда шаблон дизайна может ухудшить ваше программное обеспечение?»

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

В заключение ответ на этот вопрос действительно должен быть: - Идите и прочитайте шаблон дизайна, и он скажет вам.

Answer 5

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

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

Для лучшего понимания шаблонов вам также необходимо узнать о Anti шаблон концепции и читать намного больше, чем книга GOF. Одно из предложений - прочитать штриховку шаблонов , чтобы дополнить концепции GOF.

Answer 6

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

Я считаю, что рефакторинг для шаблонов имеет огромное значение, потому что вы очищаете существующий код. Шаблоны также являются ценными коммуникационными инструментами, которые позволяют вам описать ваш код в терминах более высокого уровня. Но вставлять шаблоны проектирования в ваше программное обеспечение, потому что они классные и рыночные (a.k.a " Resume-Driven Development "), - плохая идея.

Answer 7

Что делает легким трудным (EJB)

Answer 8

Когда это неправильный шаблон для вашей проблемы.

Answer 9

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

Answer 10

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

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

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

Павел.

Answer 11

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

Answer 12

Вы можете прочитать, например, об антипаттернах здесь .

Answer 13

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

Answer 14

Леви, я бы использовал определенную шаблон, только если бы он облегчил мою жизнь (и те, которые отвечают за поддержание кода).Я считаю, что правильный выбор шаблона проектирования так же важен, как и комментарии. Может быть, комментарии важнее?Вы обнаружите, что шаблоны проектирования по большей части формально описывают методы, которые мы, разработчики, используем годами.

ЭрудитТроглодит

Answer 15

Любой шаблон, который неправильно понят или неправильно применен, может ухудшить код, а не улучшить его. Кроме того, любой шаблон, который применяется только для шаблона, например, "Теперь мы SOA!" Как правило, если шаблон вводит код-запах " тогда его использование должно быть подозрительным.

Answer 16

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

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

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

Answer 17

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

Возможно, есть и другие причины ...

Answer 18

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