设计模式在现实世界中的渗透力如何?您是否在日常工作中使用它们 - 与同事讨论如何以及在何处应用它们 - 或者它们仍然更像是一个学术概念?

它们真的为你的工作提供了实际价值吗?或者它们只是人们谈论的听起来很聪明的东西?

笔记:为了这个问题的目的,忽略“简单”设计模式,例如 辛格尔顿. 。我正在谈论设计您的代码,以便您可以利用 模型视图控制器, , ETC。

有帮助吗?

解决方案

任何编写良好的大型程序都会使用设计模式,即使它们没有被命名或识别。这就是设计模式,反复进行的设计 自然 发生。如果你正在与一个丑陋的 API 交互,你可能会发现自己实现了一个 Facade 清理它。如果您需要解耦组件之间的消息传递,您可能会发现自己使用 Observer. 。如果您有多种可互换的算法,您最终可能会使用 Strategy.

了解设计模式是值得的,因为您更有可能识别它们,然后更快地收敛到一个干净的解决方案。然而,即使您根本不了解它们,您最终也会创建它们(如果您是一个不错的程序员)。

当然,如果您使用现代语言,您可能会被迫使用它们来做某些事情,因为它们已被纳入标准库中。

其他提示

在我看来,这个问题:“你 使用 设计模式?”,单独来说有点缺陷,因为答案普遍是肯定的。

让我解释一下,我们,程序员和设计师,都使用设计模式......我们只是并不总是意识到这一点。我知道这听起来很陈词滥调,但你不需要遵循模式,模式就会自动出现。你设计的东西,它可能看起来像一个现有的模式,你这样命名,这样每个人都明白你在说什么,并且你的设计决策背后的基本原理更强大,知道它已经被讨论过 令人作呕 前。

我个人使用模式作为沟通工具。就是这样。它们不是设计解决方案,不是最佳实践,也不是工具箱中的工具。

不要误会我的意思,如果您是初学者,有关模式的书籍将向您展示如何“使用”他们的模式而不是其他有缺陷的设计来最好地解决解决方案。您可能会从练习中学到东西。然而,你必须意识到,这并不意味着每种情况都需要相应的模式来解决。每种情况都有一个怪癖,需要你考虑替代方案,并在没有完美答案的情况下做出艰难的决定。 那是 设计。

然而,反模式属于完全不同的类别。你其实 积极地 避免反模式。这就是为什么反模式这个名字如此有争议。

回到你原来的问题:
“我使用设计模式吗?”,是的!
“我是否积极地倾向于设计模式?”,没有。

是的。如果使用得当的话,设计模式会很精彩。正如您所提到的,我现在在所有 Web 项目中使用模型-视图-控制器 (MVC)。这是网络空间中非常常见的模式,它使服务器端代码更加干净且组织良好。

除此之外,这里还有一些其他可能有用的模式:

  • MVVM(模型-视图-视图模型):与MVC类似的模式;用于 WPF 和 Silverlight 应用程序。

  • 作品:当您需要使用对象层次结构时非常有用。

  • 单例:比使用全局变量来存储真正需要单个实例的项目更优雅。正如您提到的,这是一个简单的模式,但它确实有其用途。

值得注意的是,设计模式还可以突出语言功能的缺乏和/或语言的缺陷。例如,迭代器现在作为较新语言的一部分内置。

一般来说,设计模式非常有用,但你不应该在任何地方都使用它们;就在它们最适合您的需求的地方。

我尝试着,是的。它们确实有助于代码的可维护性和可读性。然而,确实有人滥用它们,通常(据我所见)是通过强迫系统采用一种不存在的模式。

如果适用的话我会尝试使用模式。我认为看到开发人员只是为了实现设计模式而在代码中实现设计模式是一件令人悲伤的事情。不过,对于正确的任务,设计模式可能非常有用且强大。

除了简单的设计模式之外,还有许多在“现实世界”中使用的设计模式。Stackoverflow 使用模型视图控制器模式的好例子。我在我雇主的项目中多次使用了类工厂,并且我看到许多已经编写的项目也使用它们。

我并不是说所有的设计模式都在被使用,但很多都被使用了。

是的,当我们开始设计某些东西然后有人注意到它类似于现有模式时,通常会发生这种情况。然后我们看一下它,看看它如何帮助我们实现我们的目标。

我们还使用未记录但在大量设计中出现的模式。

请注意,我们不经常使用它们。

是的,工厂、责任链、命令、代理、访问者和观察者等都在我每天使用的代码库中使用。就 MVC 而言,这个网站似乎使用得很好,并且开发人员在 最新播客.

是的,我使用了很多众所周知的设计模式,但我最终也构建了一些软件,后来我发现它们使用了“命名”设计模式。大多数优雅、可重复使用的设计都可以称为“模式”。这很像舞蹈动作。我们都知道华尔兹和两步舞,但并不是每个人都知道“碰撞和滑行”的名字,尽管我们大多数人都会这样做。

MVC 非常出名,所以我们经常使用设计模式。现在,如果您询问四人帮模式,我会使用几种模式,因为其他维护人员会了解设计以及我们在代码中正在努力的方向。但有几个对于我们所做的事情来说仍然相当模糊,所以如果我使用其中一个,我就无法获得使用模式的全部好处。

它们重要吗?是的,因为它为您提供了一种以快速有效且普遍接受的方式谈论软件设计的方法。你能做更好的定制解决方案吗,是的(有点)?

最初的 GoF 模式是从生产代码中提取的,因此他们对已经在野外使用的模式进行了编目。它们不纯粹甚至主要不是学术性的东西。

我发现 MVC 模式对于隔离模型逻辑非常有用,可以重用或处理模型逻辑,而不会遇到太多麻烦。它还有助于解耦您的类并使单元测试更容易。我写过关于它的 最近 (是的,无耻的插件在这里......)

另外,我最近使用基类中的工厂模式来生成并返回我动态所需的正确 DataContext 类,使用 LINQ.

当尝试将两种不同的技术粘合在一起时(例如 可可和红宝石 以 Mac 为例)

然而,我发现每当我实现一个模式时,都是因为我事先就知道它。通常会考虑一些额外的想法,因为我发现我必须稍微修改原始模式才能满足我的需求。

你只需要小心,不要成为 建筑宇航员!

是的,设计模式在现实世界中大量使用——而且每天都被我的许多同事所使用。

在我看来,设计模式提供的最大价值是它们提供了一种通用的高级语言,让您可以将软件设计传达给其他程序员。

例如,您可以简单地说它是一个“基于输入条件的某种组合创建其他几个类之一的实用程序”,而不是将您的新类描述为 “抽象工厂” 每个人都会立刻明白你在说什么。

是的,设计模式或抽象模式是我生活的一部分,无论我往哪里看,我都会开始看到它们。因此,我被他们包围了。但是,如您所知,知识匮乏是一件危险的事情。因此,我强烈推荐你阅读GoF的书。

关于设计模式的主要问题之一,大多数开发人员只是不明白这一点,或者不相信它们。大多数时候,他们争论变量、循环或开关。但是,我坚信,如果您不会讲模式语言,您的软件将走不远,您会发现自己陷入维护噩梦中。

如您所知,反模式也是危险的事情,当您对设计模式缺乏专业知识时就会发生这种情况。重构反模式要困难得多。作为有关此问题的推荐书籍,请阅读“AntiPatterns:重构危机中的软件、架构和项目”。

是的。

我们甚至在我目前的工作中使用它们:使用 COBOL 和 PL/I 进行大型机编码。

到目前为止,我已经看到了适配器、访问者、外观、模块、观察者以及非常接近组合和迭代器的东西。由于语言的性质,它主要使用结构模式。另外,我并不总是确定使用它们的人是否有意识地这样做:D

我绝对使用设计模式。在这一点上,我理所当然地认为MVC是一种设计模式。我使用它们的主要原因是我足够谦虚,知道我可能不是第一个遇到特定问题的人。我很少在开始一段代码时知道我将使用哪种模式;我不断地观察代码,看看它是否自然地发展成现有的模式。

我也非常喜欢 马丁·福勒的 企业应用架构模式. 。当出现问题或任务时,我会翻到相关部分(主要是参考书)并阅读一些模式概述。一旦我对一般问题和现有解决方案有了更好的了解,我就会开始通过其他人的经验看到我的代码可能采取的长期路径。我最终做出了更好的决定。

设计模式无疑在我所有的“面向未来”的想法中发挥着重要作用。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top