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

Quicksort не лучше, чем сортировка с объединением. С O (n^2) (худший случай, который редко происходит), quicksort потенциально намного медленнее, чем O (nlogn) сортировки слиянием. Quicksort имеет меньше служебное, таким образом, с маленьким n и медленными компьютерами, это лучше. Но компьютеры так быстры сегодня, что дополнительные издержки сортировки с объединением незначительны, и риск очень медленного quicksort далеко перевешивает незначительные издержки сортировки с объединением в большинстве случаев.

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

16
задан 6 revs, 4 users 57% 25 May 2011 в 06:20
поделиться

18 ответов

For decades programmers have often spent time making software worse by applying practices they don't understand, rather than learning why that practice is good. The use of certain tools/keywords/frameworkes can make a programmer feel sophisticated, when they're just screwing things up. Some common examples:

  • Throwing in lots of try/catch/finally blocks can make a programmer feel like they have an error handling scheme, when in fact they don't.
  • Replacing sql with stored procedures can make programmers feel like they have a data access layer that magically gives them efficiency, reuseability, encapsulation, when in fact they don't.
  • Using classes makes many programmers believe they're engaging in object oriented programming, when in fact they aren't (or are only scratching the surface of OO).

This list could go on forever. This tendency has always been around and always will be, because we humans always look for shortcuts. We see this a lot with patterns now because patterns are currently popular. The root problem is the same: developers not having a respect for how complicated software development is, and thinking a blindly implemented pattern or practice is a substitute for learning and humility.

The solution? Difficult to say. You can't go to wrong though handing a junior developer Code Complete or some such, to help them understand this is all about applying principles to particular situations, and that great developers keep it simple.

17
ответ дан 30 November 2019 в 15:25
поделиться

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

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

0
ответ дан 30 November 2019 в 15:25
поделиться

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

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

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

0
ответ дан 30 November 2019 в 15:25
поделиться

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

0
ответ дан 30 November 2019 в 15:25
поделиться

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

TheEruditeTroglodyte

0
ответ дан 30 November 2019 в 15:25
поделиться

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

0
ответ дан 30 November 2019 в 15:25
поделиться

The software will get worse when you use design patterns as absolute building-blocks, instead of as blue-prints to help solve coding problems.

They weren't meant to be the blocks in which the problem is framed. They shouldn't show up in the Object naming conventions. Objects shouldn't be called *Factory or *Singleton, or any other pattern name. They shouldn't be locked to a specific pattern.

They are just really good "starting points" to help one build complex code more rapidly. You can (and should) mix and match the ideas as needed. Documentation? That's what the comments are for, not the Object namespace ...

Paul.

1
ответ дан 30 November 2019 в 15:25
поделиться

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

1
ответ дан 30 November 2019 в 15:25
поделиться

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

Я считаю, что

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

2
ответ дан 30 November 2019 в 15:25
поделиться

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

1
ответ дан 30 November 2019 в 15:25
поделиться

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

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

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

3
ответ дан 30 November 2019 в 15:25
поделиться

Если его имя singleton

4
ответ дан 30 November 2019 в 15:25
поделиться

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

21
ответ дан 30 November 2019 в 15:25
поделиться

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

1
ответ дан 30 November 2019 в 15:25
поделиться

A Design Pattern is simply a way of Naming and Documenting a common code structure. As such, you should not conclude that all patterns are good ones. The people that do a good job of documenting design patterns (eg the GoF) always include a section in the pattern description describing when you should, and should not, use the pattern. As such half the point of most design pattern books is to answer the question "When can a design pattern make your software worse?"

Many inexperienced developers never bother to learn the appropriate uses section and end up applying patterns where they are inappropriate. I think this is the cause of a lot of the negativity surrounding design patterns.

In conclusion the answer to this question should really be:- Go and read the design pattern and it will tell you.

3
ответ дан 30 November 2019 в 15:25
поделиться

Это называется анти-шаблоном, примеры см. В книге AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis.

1
ответ дан 30 November 2019 в 15:25
поделиться

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

0
ответ дан 30 November 2019 в 15:25
поделиться

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

1
ответ дан 30 November 2019 в 15:25
поделиться
Другие вопросы по тегам:

Похожие вопросы: