English 中文(简体)
设计模式批评来源[已关闭]
原标题:Design patterns criticism sources [closed]

我们不允许为书籍、工具、软件库等寻求推荐的问题。你可以编辑这个问题,以便用事实和引文来回答。

Closed 1 year ago.

我正在阅读维基百科上的设计模式页面,特别是“批评”部分。

你能给我指一些关于设计模式缺点的文章或书籍吗?

最佳回答

我遇到的大多数对设计模式的批评都与对他们认为只是良好的面向对象实践的结构化和标记的厌恶有关。大多数模式可以归结为对接口的编程,以及其他SOLID原理。感觉是,当我们教授模式时,我们会导致开发人员,尤其是初级开发人员,试图将所有问题都塞进他们所学的模式集中,这可能会比他们采取更直接的方法产生更迟钝和更麻烦的问题。

我倾向于同意这样一种观点,即一旦你开始学习模式,你往往会过度使用它们,然而,通常情况下,你会很快走出那个阶段,然后进入更高效、更专业的软件职业。

As a bonus, here is a bit of mild criticism from Jeff Atwood and some critical insights from Mark Dominus

问题回答

AlanKay本人对模式非常挑剔,因为他不认为软件应该如此引以为豪这是2012年多布斯博士对Kay的采访

“编程最灾难性的事情——从编程最灾难的10件事中挑选一件——有一场非常流行的基于模式语言的运动。克里斯托弗·亚历山大第一次在建筑领域这样做时,他正在研究2000年来人类让自己感到舒适的方式变化不大。我认为他从中得到了几百个有价值的模式。但在计算中试图做到这一点的错误在于,我们认为我们对编程一无所知。因此,从今天的编程实践中提取模式,使它们以一种不值得的方式变得崇高。这实际上给了他们更多的声望。”

对设计模式的一大批评是,一些设计模式实际上是多么“通用”。例如,策略模式实现在缺乏lambdas/一流函数的语言中似乎更相关(更复杂)(正如我们可能注意到的此处)。

但我认为这个论点忽略了一个简单的事实,即设计模式确实存在:我们可以感知代码中的模式,任何代码。一旦我们注意到它们,我们就可以开始使用它们作为描述理解软件体系结构的一种清晰的、与语言无关的方式。因此,一些设计模式在某些编程语言中(或直接受其支持)具有更容易的实现这一事实当然值得注意;但在我看来,将其作为反对设计模式的论据是荒谬的。

当然,我也同意许多企业设计模式不适合纯函数式语言。但我也相信功能世界也有自己的一套设计模式(比如Monad)。

最后,在黑客新闻线程。这篇来自用户@thom的帖子与我的观点相似:

重要的是要注意设计的技术机制和动机之间的差异。是的,很多语言都可以传递函数,所以您可能认为Strategy模式不适用于您。然而,我看到大量的API仍然使用大量的选项映射,并且不提供带有某种回调的配置,无论宿主语言多么简单。模式捕获设计选择技术实现

设计模式在大约十年前被大肆炒作;在我看来,大多数批评都是关于过度保护应用程序,并在任何可能的地方应用你能想到的所有模式。当你去掉咆哮的因素时,这场激烈的辩论是相当无聊的——是的,太多的东西都不好,对于没有经验的程序员来说,一切都像钉子。

有时,有人会发现他一直在做的事情有一个名字,并评论说它不应该有名字(忽略了设计模式是为了命名有时显而易见的东西,以便你可以谈论它们)。

除此之外,您基本上只剩下这样一个事实,即有些语言内置了一些模式,而另一些则没有,以及关于随着时间的推移,一些模式如何成为编程语言功能的学术争论。

除此之外,我还没有看到太多与设计模式相关的有效批评。它们确实存在,有时它们很有用,当有人在凌晨3点叫醒你时,你不必知道所有的它们,仅此而已。:)

设计模式通常以特定编程语言(通常是Java或C++)中的一组技巧表示。通常不会解释何时以及为什么需要使用模式,以及何时最好不要使用它。通常不会解释在完全不同的编程语言中会发生什么。

因此,人们会有这样的印象:1)天才发明的设计图案来自天空,2)GoF书需要记住,3)图案需要始终应用于任何情况。

在我看来,设计模式是高度特定于语言的(LISP有一套与Java完全不同的“设计模式”)和特定于问题的(根据项目的不同,您使用或不使用模式,即使它“理论上”适用于代码中的这个位置)。GoF这本书是Java语言手册的一本有用的配套书,但不是关于“一般编程”的一套永恒原则。

经历了GoF书出版的时代(约1995年),我记得读到一个主要的推动力(或者至少是引起如此多关注的一个原因)是OOD对大多数开发人员来说仍然是新的。人们对如何制作物体缺乏了解。

因此,这本书展示了一些常见的上课模式以及它们是如何协同工作的。

因此,对这一点的批评是:它现在可能不像当时那样重要。当时,以及之后的几年里,没有像之后几年那样多的框架(尤其是Java)。现在,您可以找到许多优秀的面向对象代码示例。如果一些作者把非常好的OO代码库放在一边,写一些书来说明他们为什么认为它们如此美妙,那不是很好吗?

对我来说,这些模式的最佳用途是在看到它们时了解它们,了解缺点(请参阅访问者模式,并注意系统的哪些部分更容易扩展),并在编写自己的代码时吸取这些教训。

我确信设计模式有助于构建关于编程技术的教育课程,但我认为它们成为软件行业的通用语言并没有帮助。作为传达设计的一种方式,它们可能会适得其反,因为它们迫使设计符合既定的模式,它们允许对设计的描述过于随意,它们迫使任何试图理解设计的人阅读一本关于设计模式的书。





相关问题
Choosing the right subclass to instantiate programmatically

Ok, the context is some serialization / deserialization code that will parse a byte stream into an object representation that s easier to work with (and vice-versa). Here s a simplified example ...

Design pattern for managing queues and stacks?

Is there a design pattern for managing a queue or a stack? For example, we are looking to manage a list of tasks. These tasks will be added to a group queue, users will then be able to pull off the ...

Organizing classes using the repository design pattern

I have started upgrading one of our internal software applications, written in ASP.NET Web Forms, and moving to ASP.NET MVC. I am trying to leverage the Repository design pattern for my classes, ...

Misuse of Observer Pattern?

I have a Car object which contains a latitude field and a longitude field. I use the observer pattern so that any time either of these fields change in my application, my car object is notified. I ...

How are Models (in MVC) and DAOs supposed to interact?

How are models and DAOs supposed to interact? I m in the process of putting together a simple login module and I m unsure where to put the "business logic." If I put the logic with the data in the ...

热门标签