it-swarm.cn

我什么时候应该使用(而不应该使用)设计模式?

我的上一个关于Stack Overflow的问题 中,在注释中提到了 FredOverflow

请注意,模式并不能神奇地提高代码质量。

您可以想象的任何质量度量。模式不是万能的。我曾经写过一个大约100个班级的俄罗斯方块游戏,其中包含了我当时所知道的所有模式。如果可以使用模式,为什么还要使用简单的if/else? OO很好,而且模式更好,对吧?不,那是一件糟糕的,过度设计的废话。

这些评论让我感到困惑:我知道设计模式有助于使代码可重用和可读,但是什么时候应该使用设计模式,也许更重要的是,什么时候应该避免对它们感到厌烦?

57
ashmish2

[[〜#〜] kiss [〜#〜] 首先,模式稍后,可能要晚得多。模式主要是一种心态。永远不要试图将您的代码强制为特定的模式,而要注意哪些模式开始从您的代码中浮现出来,并对其有所帮助。

决定“好吧,我要编写一个使用模式Y执行X的程序”是灾难的秘诀。它可能适用于Hello World类程序,该程序适合于演示模式的代码构造,但仅此而已。

99
jwenting

我认为主要的担忧是人们经常倾向于滥用设计模式。他们学习了一些知识,看到了它们的用处,但没有意识到这将这几种模式变成了一把金锤,然后将其应用于一切。

关键不一定是要学习模式本身。关键是要学会识别模式要解决的场景和问题。然后,应用模式只是为工作使用正确工具的问题。在选择工具之前,必须先确定和理解这一工作。

有时这是一个奇怪的设置,没有开箱即用的模式可以立即解决。在这一点上,需要更多地关注问题而不是解决方案。将其分解为各个组成部分的问题,确定与已知模式解决的问题具有共同特征的问题区域,调整模式以适应问题,等等。

52
David

当设计模式用作团队中的通用语言时,效果最好。

我的意思是,您可以说类似“此类是 Singleton ,它实现了我们的IHairyWidget (Abstract Factory,团队中的每个人都可以理解这意味着什么,而无需进行详细的解释。

设计模式失败的地方是团队不了解设计模式,或者当它们过度使用以至于他们停止使设计更清晰,而使理解实际情况变得更加困难。

24
GrahamS

也许有点偏离主题,但我认为它也涵盖了您的问题:我建议您读一本好书 重构为模式

本书介绍了模式导向的重构的理论和实践:低级重构的序列,允许设计人员安全地将设计移至,移向或移出模式实现。使用来自真实项目的代码,Kerievsky记录了基于两打基于模式的设计转换的思想和步骤。在此过程中,他提供了关于模式差异以及如何以最简单的方式实现模式的见解。

当可以很好地使用设计模式时,以及当您需要放弃它们而不是使应用程序变得过于复杂时,您将找到示例。是的,主要思想是使所有内容尽可能简单。

对您的问题的很好答案/建议是在文章 您是否认识到设计模式滥用的4个早期预警信号? ,但现在无法加载,错误500。它不大,所以我刚刚使用谷歌缓存来获取它:

软件设计模式确实会导致过度设计

工程过度是使某些事物过于复杂的过程。在进行编程的情况下,使您的代码比所需的更加复杂和灵活。更具体地说,在简单问题上实现复杂的软件设计模式。

1。开始简单而不复杂

这是怎么发生的?通常,您会编写预期会在将来使用或证明有用的额外功能。但是,如果这种需求从未实现,会发生什么呢?在大多数情况下,残留物会留在那里。它不会被删除。因此,软件系统的规模和复杂性不断增加,而这些功能从未使用过。

2。警惕这些迹象

也许每个人都不一样,但我怀疑在大多数情况下,这并不是一项有意识的努力。相反,这是由于害怕被笨拙,笨拙,不合适或简而言之,糟糕的设计所困;被一些不够灵活的东西所卡住具有讽刺意味的是,如果您到达过度设计或过度应用模式的地步,那您就回到了起点。

软件设计模式之所以吸引程序员或开发人员,是因为它们可以自然表达和创建漂亮的架构。这是享受创意编程的一部分。

3。考虑重构为模式而不是从一个开始

避免这种设计模式滥用的好方法是什么?考虑重构为一种模式,而不是从一个模式开始。不要一开始就试图将图案强加到您的设计中。没有它,您的设计可能会更简单。如果确实在以后的阶段中发现您的设计确实可以从结构化模式中受益,那么请进行重构以允许这样做。设计时,请以最简单的方法解决问题。简单轻巧的软件始终是一件好事。有更好的方法来避免设计不足的替代方案,在这种方案中,您会陷于不够灵活或不适合该问题的设计或解决方案。

4。不要强迫自己第一次做对

强迫软件设计模式或结构进入设计并不是解决之道,那只是糟糕的设计。但是,原型制作或构建初始构建(在实际产品开始生产之前先进行概念验证)可以帮助避免这种情况以及过度设计的问题。因为您不需要第一次就完美地完成它。

原始URL(现已失效): http://codelines.net.au/article/do-you-recognise-the-4-early-warning-signs-of-design-pattern-abuse/

14
Maxym

什么时候停止使用模式做所有事情?

问题是您何时开始使用模式进行一切?并非所有解决方案都能完美地适应现有的设计模式,而采用一种模式可能意味着您混淆了解决方案的清洁度。您可能会发现,不是通过设计模式来解决问题,而是通过尝试强制解决方案适应设计模式而产生了另一个问题。

显然,如果您针对特定场景选择正确的设计模式,那么您就不会有问题,但是选择正确的设计说起来容易做起来难。

我已经看到过在项目中不必要使用模式的情况,这些模式实际上是不必要的。

我认为关键是-尝试保持代码干净,模块化和可读性,并确保您的类不是 紧密耦合 =。最终,您可能会发现您无意中使用了标准设计模式的变体。也许您在开始编码之前就已经在项目的开始就意识到了这一点。如果您像大多数我认识的人(包括我自己)一样编码,那么可能就不是:)

9
El Ronnoco

好吧,最重要的是要知道您要解决的问题。比您需要决定引入某种模式是否会比不使用它获得一些优势(获得性能,简单性或其他优势)。相关问题: https://stackoverflow.com/questions/85272/how-do-you-know-when-to-use-design-patterns

5
sinek

没有原始/实际目标文本中提到的一些设计模式,即GoF需要相当多的经验,并且经常需要重读,并且需要有能力的同事进行头脑风暴。在此阶段之后,给定问题,给定架构,最自然的设计模式通常以相当明显的方式出现。但是,任何使设计模式强制适合问题或将问题映射到设计模式的尝试都充满了危险,在这种情况下,最好咨询专家,进行一些头脑风暴,并将其作为学习经验。除非您对常用的10多种设计模式非常满意,否则这将有些棘手,并且AFAIK不会提供任何快捷方式。

我已经遍及数百万个SLOC C++代码项目,其中包含大量的强制拟合设计模式示例,因此有很多错误。过度使用并不是很常见。

4
icarus74

任何需要您学习和应用规则的主题都是这样的:

  1. 如果您是新手,则需要遵守规则,因为您并不了解。
  2. 如果您是业余爱好者,请遵循这些角色,因为您知道为什么需要它们。
  3. 如果您是专业人士,则可以使用规则而不是违反规则,因为他们清楚该在何时何地不适用时使用什么。
  4. 如果您是专家,则可以忽略规则。
  5. 如果您精通艺术,则您更喜欢规则,因为代码也必须由1-3类人员查看。 :)

武术,绘画,写作,足球,机械,赛车等都是一样的...

作为第五名的人,您通常最终会教第一名至第四名的人如何成为顶级人,因此即使在竞争激烈的环境中,它也总是适用。

(如何超越和忽略规则 从广义上解释了这一点,但是可能还有更好的文章。)

4
Macke

规则是没有规则。您的经验(成功多于失败)将告诉您何时纯粹使用它们,何时进行调整或何时根本不使用它们。

丹·诺斯(Dan North)发表了 presentation ,他在其中谈到了学习和模式

3
Augusto

保持一切尽可能简单。但是,我必须解决一个问题,但是您可能想要使用一种设计模式,而不是重新发明轮子,因为许多设计模式都可以解决常见问题。但正如我所说:仅在真正需要时使用它们。

2
Puce

也许使用KISS DRY)SoC模式(是的,也许它不是模式,但是听起来很有趣))。

保持简单,愚蠢。
不要重复自己。
关注点分离。

我认为这三点对任何程序员来说都是鼓舞人心的。

2
Fredrik Norlin

“模式”的问题在于,任何事物都可以被视为一种模式,而且通常是这样。

在我第一次听到任何人谈论“模式”之前,我已经从事了很长时间的专业代码开发工作,这些年来我都做得很好。实际上,当我回头看时,我写的很多东西实际上至少在某种程度上遵循了一些众所周知的模式。

我的观点是,严格遵循任何给定的模式并不是真正的答案。了解新模式,但不要束手无策:它们会发生变化。今天的良好编码实践与十年前的良好编码实践并不相同,而且无论当今的程序员多么聪明,您都可以肯定,在未来十年内,今天被认为是良好实践的事情将被取代。

离题:就我个人而言,我真的很讨厌在这种情况下使用“模式”一词。它散发出不必要的行话。

1
Spudley

通常,设计模式通常用于向更广泛的用户解释您的代码真正做什么。这样,人们可以更轻松地了解您在做什么。人们很少将其用作提出解决方案的参考,因为实际上可以以多种方式实施模式。

0
Gaurav Sehgal

构建代码逻辑的方式应允许该代码的新手能够解释和修改它。如果您不完全了解该代码的使用方式,对象和位置以及可能使用的上下文,那么仅仅因为它是一种最佳实践而拥有一个模式将无济于事。

“保持简单”模式比模式更像是常识,它在创建代码时必须成为开发人员思考过程的一部分。假设每个人都有特定的模式也不一定是正确的。理想情况下,您需要一种无需太多了解即可读取和识别的模式。

0
Oscar Villarreal

天哪,你会知道的。我的意思是我什至在知道设计模式的定义之前就使用了设计模式。这只是很好的编码。有时您可以在编写项目要求时识别它,而有时您必须重构代码。

jwenting先说,然后再说图案。我认为模式是[〜#〜] kiss [〜#〜]项目的一种方法,因为您可以应用自己知道的工作原理,并且会节省很多时间您未来的时间。

唯一可能出错的是,即使使用相同的语言,也有很多方法可以实现单个设计模式,因此您需要完全理解问题所在

0
dierre