说到设计模式的使用,我猜商店可以分为三种类型。那些不知道某个模式是否打在他们脸上的人 - 这些人通常更喜欢使用 Ctrl-C / Ctrl-V 方法来重用代码。那些每天花几个小时搜索遗留代码以希望实现一种更伟大的模式的人 - 这些人通常花在重构简单程序代码上的时间比一百年维护所花费的时间还要多。最后,那些走中间道路的人在有意义的时候使用模式,并为最小化暴露的代码而编码。

我想知道是否有人已经锁定了一种在软件开发生命周期中平衡地结合模式使用的好方法。另外,Web 上有关模式、其激励因素及其正确使用的最佳资源是什么?

谢谢。

有帮助吗?

解决方案

那里有很多不同的“模式”家庭,但就你的问题而言,它是最广泛的术语......

我建议:

离线(我的最爱):

离线(热门):

  • GoF 设计模式
  • 福勒的重构:改进现有代码的设计

其他提示

模式的良好使用取决于知识和经验;它没有公式。一件好事是让一个在明智地应用模式方面经验丰富的人定期审查团队中其他人的代码,以确保他们没有过度使用或未充分使用设计模式。它们不是预先烘焙好的食谱——它们需要有效应用的技能,而这是必须学习的。

我第一次也是最好的接触设计模式是 波特兰模式存储库.

“模式”的使用在很大程度上取决于

  1. 使用的语言
  2. 一个人喜欢实现的目标。

设计模式在 C++、Java 等语言中可能被高估了。它们隐藏了各种打字问题带来的不灵活性。以下是有关在限制较少的语言中“生存”的模式的链接:http://norvig.com/design-patterns/

另一个例子是面向方面的编程,其中花费了很大的努力,事物是用一种不是为其“设计”的语言“引入”的。

使用工具背后的哲学也有很大的影响。只需比较一下 Smalltalk、Common Lisp、Haskell 等中的普通 PHP 或 Visual Basic 程序和解决方案即可。

语法元素也有很大的影响。您会在 C、C++(迭代器)中看到大量类似的循环,但如果您研究支持高阶函数的语言,您只会发现一些循环。

然后,您必须了解人们访问编程的方式,自下而上还是自上而下,逐步增长或构建金字塔,或任何其他个人偏好

我建议阅读提到的链接,然后检查“不同”语言的实现......

关于弗里德里希的介绍

每个人都一直在使用模式。他们可能只是不知道而已。即使像“迭代列表”这样简单的事情也是一种模式。

我认为将模式纳入工作周期的最佳方法就是使用它们,并在讨论它们和注释代码时按名称引用它们。希望这将导致知识的传播。

举例来说,您发现您所做的事情非常适合观察者。你对你的同事说:“嘿,如果我们让这个对象成为观察者,让这个对象成为主题,这真的很容易做到。”

要么你的同事会立即理解——这是节省你时间的模式——要么你要教育他们,并且 下一个 当你提到观察者时,他们马上就会明白。

与此同时,您正在传播知识,他们会发现机会使用从您那里学到的新模式。当然,这是双向的。下次可能会是 他们 教学 一种新的模式。

所有这一切都依赖于你的同事不是那种在不明白的情况下点头并假装明白的人。你确实需要他们说“嘿,你提到了观察家,我想我不知道那是什么。”

我认为最好的网络资源包含有关模式和重构的信息 - http://sourcemaking.com

我是这个系列的忠实粉丝,读过很多他们的书,所以我推荐 首先设计模式. 。您可以通过 O'Reilly's 在线阅读 狩猎书架, ,但硬拷贝还附有精美的图案海报。

我非常同意上面的评论。我会尽可能地使用设计模式,但始终依赖团队的其他成员来真正理解特定模式的好处。否则,您最终会得到丑陋的代码和有点类似于该模式的轻量级包装器。

作为旁白 http://www.developer.com 每月有几篇关于设计模式及其应用的文章。祝你好运!

我想我必须推荐 重构:改进现有代码的设计.

Refactoring: Improving the Design of Existing Code
(来源: 2020ok.com)

有大量关于如何合理使用模式的示例。

定义和原始答案是概念的起源,在 设计模式. 。本书在理论层面上讨论这个概念,而不是渗透到该领域的管理言论。他们认为设计模式只是常见习语的名称;他们列举了一些并证明了自己的立场。

他们避免“我应该使用什么设计模式”类型的问题,而是将问题处理为“我自然会进入一个众所周知的领域吗?”如果是这样,其他人的经验可以帮助我吗?”。对我来说,设计模式并不像将预制组件粘合在一起以形成解决方案。它们只是当你遇到与其他人反驳的情况类似的情况时的指导存储库,并提供名称以允许人们在谈话中参考一般情况。

设计模式很有趣,因为只有当您完全理解适用的模式时,您才知道在哪里使用该模式。像策略、观察者、迭代器这样的东西,经过一些练习,你就可以不用费力地思考就可以使用。如果您使用 C#,您会一直使用迭代器 (IEnumerable...),而不将其视为一种模式。

在我看来,这些简单的模式就是最好的模式。你已经有一份工作要做,并且试图将你的问题硬塞进一个又一个的模式中,但实际上却没有 相当 fit 会浪费你的时间,并且会导致糟糕的代码。

我的建议是查看某个模式的 uml 图,如果它相当简单,那么尝试学好它,以便以后可以回忆起来。具有更简单契约的模式可能更常用。

我会亲自阅读《四人帮》的《设计模式》一书

我同意这些参考资料,但对新手不友好。要以简单的方式快速开始学习设计模式:

首先:设计模式

一旦你了解了整体情况,你就可以查看更高级的书籍(很多实际例子;-))

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