blocks|key|1212693|text|我遇到的大多数对设计模式的批评都与他们认为只是好的面向对象实践的结构和标签的厌恶有关。大多数模式归结为对接口和其他SOLID+principles的编程。这种感觉是，当我们教授模式时，我们会导致开发人员，特别是初级开发人员，试图将所有问题都塞进他们所学到的模式集中，这可能会产生比他们采取更“简单”的方法更迟钝和麻烦的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1212694|我倾向于同意这样的观点，一旦你开始学习模式，你往往会过度使用它们，然而，通常情况下，你很快就会走出那个阶段，然后进入更有生产力和更专业的软件职业生涯。|1212695|作为奖励，here+is+a+bit+of+mild+criticism+from+Jeff+Atwood和some+critical+insights+from+Mark+Dominus|1212696|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/SOLID_(object-oriented_design))|1|http://www.codinghorror.com/blog/2007/07/rethinking-design-patterns.html|2|http://perl.plover.com/yak/design/samples/slide001.html^0|1L|G|0|0|0|5|1C|1|1I|14|2|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]|$A|12|B|13|1|14]]|C|$]]|$1|H|3|-4|5|6|7|15|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]|R|$5|K|L|M|C|$N|S]]]]

Most of the criticisms of design patterns that I have come across relate to a distaste for the structuring and labeling of what they consider to be just good object-oriented practices. Most patterns boil down to programming to interfaces, and other <a href="https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)" rel="noreferrer">SOLID principles</a>. The feeling is that when we teach patterns we cause developers, especially junior developers to try to cram all problems into the set of patterns that they have learned, which can create more obtuse and cumbersome problems than if they had taken a more 'straightforward' approach.

I tend to agree with the sentiment that once you begin to learn patterns you tend to overuse them, however, typically you very quickly move out of that stage, and into a much more productive and professional software career afterward.

As a bonus, <a href="http://www.codinghorror.com/blog/2007/07/rethinking-design-patterns.html" rel="noreferrer">here is a bit of mild criticism from Jeff Atwood</a>
and <a href="http://perl.plover.com/yak/design/samples/slide001.html" rel="noreferrer">some critical insights from Mark Dominus</a>

blocks|key|1962290|text|对设计模式的一大批评是，有些设计模式到底有多“通用”。例如，在缺少lambda/一流函数的语言中，策略模式实现似乎更相关(也更复杂)(比较Java，甚至与C#的“函数式”方法here)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1962291|但我认为这种观点忽略了这样一个事实，即设计模式确实存在(因为我们可以在代码中感知模式，任何代码)，并且它们也可以作为描述和理解软件体系结构的一种良好的、与语言无关的方式工作。因此，一些设计模式在某些编程语言中有更容易的实现(或直接由某些编程语言支持)的事实是值得注意的，但这与IMHO无关。|style|BOLD|1962292|当然，我也同意许多企业设计模式不适合纯函数式语言。但我也相信函数式世界也有自己的一套设计模式(就像Monad一样)。|1962293|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Strategy_pattern|1|http://en.wikipedia.org/wiki/Monad_%2528functional_programming%2529^0|2F|4|0|0|1P|2|0|1D|5|1|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|D|3|E|5|6|7|X|8|@$A|Y|B|Z|F|G]]|9|@]|C|$]]|$1|H|3|I|5|6|7|10|8|@]|9|@$A|11|B|12|1|13]]|C|$]]|$1|J|3|-4|5|6|7|14|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]|R|$5|M|N|O|C|$P|S]]]]

One big criticism against design patterns is about how much &quot;generic&quot; some design patterns really are. For instance, the Strategy Pattern implementation seems to be more relevant (and complex) in languages that lack lambdas/first-class functions (compare the Java vs. Ruby, or even vs. the C# &quot;functional&quot; approach, <a href="http://en.wikipedia.org/wiki/Strategy_pattern" rel="nofollow noreferrer">here</a>).
But I think this argument ignores the fact that design patterns do exist (because we can perceive patterns in code, any code), and that they can also work as a good, language-agnostic ways of describing and understanding software architecture. So the fact that some design-patterns have easier implementations in (or are directly supported by) certain programming languages is something to be aware of, of course, but it is not that relevant IMHO.
Of course, I do also agree that many enterprise design patterns would not fit in a pure functional language. But I also believe the functional world has its own set of design patterns too (like the <a href="http://en.wikipedia.org/wiki/Monad_%28functional_programming%29" rel="nofollow noreferrer">Monad</a>).

blocks|key|1962314|text|设计模式在大约十年前被大肆炒作；在我看来，大多数批评都是关于过度架构应用程序和在任何地方应用您能想到的所有模式。当你去掉抱怨的因素时，这场激烈的辩论是相当无聊的-是的，太多的东西都是不好的，对于没有经验的程序员来说，用锤子敲打一切看起来都像钉子。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1962315|有时，有人会发现，他一直在做的事情有一个名字和评论，它不值得有一个名字(忽略了设计模式是为了命名一些显而易见的东西，以便你可以谈论它们)。|1962316|除此之外，你基本上可以看到一些语言内置了一些模式，而另一些语言没有，以及一些模式如何随着时间的推移成为编程语言功能的学术争论。|1962317|除此之外，我没有看到太多与设计模式相关的有效批评。它们绝对存在，有时它们很有用，当有人在凌晨3点叫醒你时，你不需要知道所有的它们，仅此而已。:)|1962318|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Design patterns were hyped a lot about ten years ago; it seems to me that most of the criticism is about overarchitecting applications and applying all the patterns you can think of wherever you can. This heated debate is pretty boring when you take the rant factor out - yes, too much of anything is not good and to inexperienced programmer with a hammer everything looks like a nail.

From time to time, somebody will discover that something he's been doing for the whole time has a name and comment that it doesn't deserve to have a name (missing the point that design patterns are about naming sometimes obvious things so that you can talk about them).

Apart from that, you're basically left with the fact that some languages have a few patterns built-in, and some other don't, and academic debate about how with time some patterns become programming language features.

I haven't seen much valid criticism related to design patterns beside that. They definitely exist, sometimes they are useful, you don't have to know all of them when somebody wakes you up at 3 AM, and that's about it. :)

blocks|key|3392090|text|设计模式通常以特定编程语言(通常是Java或C%2B%2B+)中的一组技巧来表示。通常不会解释何时以及为什么需要使用模式，以及何时最好不要使用它。通常不会解释在完全不同的编程语言中会发生什么。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3392091|因此，人们得到的印象是:+1)设计模式来自于天，由天才发明，2)+GoF书需要被记住，3)模式需要在任何情况下总是被应用。|3392092|在我看来，设计模式是高度特定于语言的(LISP具有与Java完全不同的一组“设计模式”)和特定问题(根据项目的不同，您可以使用或不使用模式，即使它“理论上”适用于代码中的这个位置)。GoF一书是Java语言手册的有用补充，但并不是关于“一般编程”的一组永恒原则。|3392093|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Design patterns are usually presented as a set of tricks in a specific programming language, usually Java or C++. It is usually not explained when and why a pattern needs to be used, and when it is best not to use it. It is usually not explained what would happen in a totally different programming language. 

So one gets an impression that 1) design patterns come from the sky, invented by geniuses, 2) the GoF book needs to be memorized, 3) patterns need to be applied always and ever more in every situation. 

In my view, design patterns are highly language specific (LISP has a totally different set of "design patterns" than Java) and problem specific (depending on the project, you use or don't use a pattern even though it is "theoretically" applicable to this place in your code). The GoF book is a useful companion to a Java language manual, but not a set of eternal principles about "programming in general".

blocks|key|3392131|text|我确信设计模式有助于构建关于编程技术的教育课程，但我不认为它们成为软件行业的通用语言是有帮助的。作为一种沟通设计的方式，它们可能会适得其反，因为它们迫使设计符合既定的模式，它们允许设计被过于随意地描述，它们迫使任何试图理解设计的人阅读一本关于设计模式的书。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3392132|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I am sure that design patterns help to structure educational courses on programming techniques but I don't think it helpful that they become a lingua franca in the software industry. They can be counter productive as a way of communicating design because they force the design to conform with established patterns, they allow the design to be described too casually and they force anyone trying to understand the design to read a book on design patterns.

blocks|key|1962390|text|Alan+Kay本人对模式非常挑剔，因为他认为软件不应该被如此吹嘘。Here's+a+2012+Dr.+Dobbs+interview+with+Kay。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1962391|1962392|“编程最糟糕的事情--从编程的10件最糟糕的事情中挑选一件--有一种非常流行的基于模式语言的运动。当克里斯托弗·亚历山大第一次在建筑学上这么做的时候，他正在研究两千年来人类让自己感到舒适的方式。所以这实际上是有原因的，因为他处理的是一个没有太大变化的基因组。我想他从中得到了几百个有价值的图案。但试图在计算中做到这一点的错误是假设我们对编程一无所知。因此，从当今的编程实践中提取模式以一种它们不应得的方式提升了它们的价值。这实际上给了他们更多的威望。“|blockquote|1962393|1962394|entityMap|0|LINK|mutability|MUTABLE|url|http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442?pgno=4^0|Y|16|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|V|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|W|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

Alan Kay himself is very critical about patterns because he doesn't believe software should be so vaunted. <a href="http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442?pgno=4" rel="noreferrer">Here's a 2012 Dr. Dobbs interview with Kay</a>.

<blockquote>
 "The most disastrous thing about programming — to pick one of the 10 most disastrous things about programming — there's a very popular movement based on pattern languages. When Christopher Alexander first did that in architecture, he was looking at 2,000 years of ways that humans have made themselves comfortable. So there was actually something to it, because he was dealing with a genome that hasn't changed that much. I think he got a few hundred valuable patterns out of it. But the bug in trying to do that in computing is the assumption that we know anything at all about programming. So extracting patterns from today's programming practices ennobles them in a way they don't deserve. It actually gives them more cachet."
</blockquote>

blocks|key|4803179|text|在经历了GoF这本书出版(大约1995年)的时候，我记得我读到过一个主要的推动力(或者至少是一个引起如此关注的原因)，那就是面向对象设计对大多数开发人员来说仍然是新事物。对如何制作物体的理解是完全缺乏的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4803180|因此，这本书展示了一些常见的制作类的模式以及它们是如何协同工作的。|4803181|因此，对此提出批评:它现在可能不像当时那么相关了。当时和之后的几年里，没有像后来那样多的框架(特别是在Java中)。现在，您可以找到许多优秀的面向对象代码的示例。如果一些作者将非常好的OO代码库的快照放在一边，并写一些关于为什么他们认为自己如此出色的书，那不是很好吗？|4803182|对我来说，这些模式最好的用处是在你看到它们的时候知道它们，理解它们的缺点(参见‘访问者模式’，并注意系统的哪些部分更容易扩展)，并在编写自己的代码时吸取这些经验教训。|4803183|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Having lived through the times when the GoF book was published (ca 1995), I recall reading that a major impetus (or at least a reason for so much attention), was that OOD was still new to most developers. There was a dearth of understanding of how to make Objects at all.

So this book came out showing some common patterns of making classes and how they worked together.

So a criticism to this: it may not be as relevant now as it was then. Back then, and for a few years afterward there were not as many frameworks (especially in Java) as there would come to be in the years afterward. Now, you can find a lot of examples of good Object Oriented code. Wouldn't it be nice if some authors took snapshots of very good OO codebases aside, and wrote books about why they think they are so wonderful?

To me, the best use of these patterns is to know them when you see them, understand the drawbacks (see 'Visitor Pattern' and note which parts of the system are more easily expanded), and take those lessons as you write your own code.

I was reading the <a href="http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Criticism" rel="nofollow noreferrer">design patterns</a> page on Wikipedia, particularly the "Criticism" section.

Could you point me to some articles or books about shortcomings of design patterns?

Design patterns criticism sources

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我在看维基百科上的页面，特别是“批评”部分。你能给我推荐一些关于设计模式缺点的文章或书籍吗？

问设计模式批评来源
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问设计模式批评来源EN