Quicksort не лучше, чем сортировка с объединением. С O (n^2) (худший случай, который редко происходит), quicksort потенциально намного медленнее, чем O (nlogn) сортировки слиянием. Quicksort имеет меньше служебное, таким образом, с маленьким n и медленными компьютерами, это лучше. Но компьютеры так быстры сегодня, что дополнительные издержки сортировки с объединением незначительны, и риск очень медленного quicksort далеко перевешивает незначительные издержки сортировки с объединением в большинстве случаев.
, Кроме того, сортировка с объединением оставляет объекты с идентичными ключами в их первоначальном заказе, полезном атрибуте.
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:
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.
Я могу придумать множество способов, по которым шаблон дизайна может пойти не так. В книге GoF объясняются проблемы, решения и недостатки всех шаблонов, о которых говорится. - Выкройка - это решение проблемы. Если эта проблема не ваша проблема, то, вероятно, она станет антипаттерном. - У выкройки есть недостатки, о которых стоит знать. - Когда тебе это не нужно. Шаблон может включать в себя множество классов, и вы пытаетесь решить проблему, которая может возникнуть в будущем, но еще не решена. - Если вы не понимаете, как это работает, и неправильно реализуете, это тоже становится антипаттерном. У вас будет много бесполезных классов и кода. - Когда начинаешь увлекаться этим. Слишком глубокие иерархии, неправильное использование полиморфизма или синглтонов и т. Д. Могут представлять проблему.
Вероятно, есть и другие причины ...
Я бы сказал, когда вы выбираете шаблон, основанный на решении одной проблемы, а не всех проблем, которые ваше программное обеспечение намеревается решить.
И наоборот, попытка перестроить решение, чтобы оно соответствовало всем возможным возможным вариантам использования, может привести к использованию шаблона проектирования, который слишком громоздок для большинства ваших вариантов использования.
Таким образом, идеальный образец / уровень приверженности этому образцу должен быть чем-то, что находится между двумя крайностями.
Любой шаблон, который неправильно понимается или применяется неправильно, может сделать код хуже, а не лучше. Кроме того, любой шаблон, который применяется просто ради шаблона, например, «Мы - SOA now!». Как правило, если образец вводит « запах кода », то его использование должно вызывать подозрение.
Леви, Я бы использовал конкретный шаблон только в том случае, если он облегчил мне жизнь (и тех, кто отвечает за поддержку кода). Я считаю, что правильный выбор шаблона дизайна так же важен, как и комментарии - может быть, комментарии важнее? Вы обнаружите, что шаблоны проектирования по большей части формально описывают методы, которые мы, разработчики, использовали в течение многих лет.
TheEruditeTroglodyte
Я думаю, что шаблон стратегии может ухудшить программное обеспечение, если он не нужен. Шаблон стратегии в основном делает часть функциональности «подключаемой», что означает, что мы можем переключать различные реализации на лету. Но эта подключаемая функциональность часто усложняет настройку (а иногда и дополнительные накладные расходы), а если она не нужна, то это пустая трата. Я часто вижу, как этим шаблоном злоупотребляют.
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.
Интересно, что за последний год я потратил изрядное количество времени на изучение шаблонов проектирования и их реализаций - так же, как кажется, все больше и больше противодействуют шаблонам проектирования. Паттерны проектирования, справедливо или нет, пополнили ряды процессов и методологий, которые должны были сделать программное обеспечение навыком, поддающимся количественной оценке, т. Е. Заблуждение, что их использование заставит вас писать лучший код. Я думаю, что проблема шаблонов проектирования в том, что менее опытные программисты используют их как «золотой молоток». Они изучают паттерн стратегии - что очень ценно - но затем используют его везде , чрезмерно усложняя свой код и добавляя ненужные функции и «расширяемость».
Я считаю, что
имеет огромную ценность в рефакторинг в шаблоны, потому что вы очищаете существующий код. Шаблоны также являются ценными инструментами коммуникации, которые позволяют описывать ваш код в терминах более высокого уровня. Но вставлять шаблоны дизайна в ваше программное обеспечение, потому что они классные и востребованные (также известные как «разработка на основе резюме»), - плохая идея.
Шаблон проектирования может ухудшить ваше программное обеспечение, если вы его неправильно используете , применяя его в неправильной ситуации . Здравый смысл должен быть идеальным компаньоном для шаблона проектирования.
Неправильное использование шаблонов иногда связано с непониманием сил , связанных с проблемой, и шаблоном, предлагаемым решением этой проблемы. Также цель шаблона может быть неправильно понята, что приведет к неправильному использованию.
Для лучшего понимания шаблонов вам также необходимо узнать о концепции Анти-шаблон и прочитать гораздо больше, чем книга GOF. Одно из предложений - прочитать Штриховка по образцу , чтобы дополнить концепции GOF.
Когда вы используете его не по назначению, или, что еще хуже, когда вы используете узор без надобности. Последнее сводит меня с ума, потому что, когда я анализирую фрагмент кода, я, естественно, сначала предполагаю, что всему в нем есть причина, а когда я не вижу причины для чего-то, самым безопасным предположением по умолчанию является то, что я что-то упускаю. И поскольку я не хочу рисковать взломать код неизвестным или непредсказуемым образом, я трачу время на то, чтобы выяснить, почему он там, прежде чем возиться с ним.
В общем, когда кодировщик считает, что шаблоны - это кирпичики, похожие на лего, из которых строят программное обеспечение, вы получаете действительно странный код.
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.
Это называется анти-шаблоном, примеры см. В книге AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis.
Когда люди анализируют код и тратят больше времени на попытки понять шаблон, чем бизнес-логику. Шаблоны хороши, но только в том случае, если все участники умеют их читать.
Вы можете прочитать об антипаттернах , например, здесь .