首先应该是什么 - 设计模式还是代码?

时间:2009-05-21 16:52:23

标签: design-patterns architecture refactoring

我正在开始一个全新的项目 - 我应该查看我的规范并决定应用哪些设计模式,或者只是想出一个组织的概念并允许模式通过重构有机地出现?

根据您的经验,哪种技术最有效率,并且更有可能获得干净优雅的代码?

我也想知道是否有没有GoF定义的设计模式,但可能同样有价值?如果是这样,有哪些有用的资源可以告知自己这些?

8 个答案:

答案 0 :(得分:18)

您应该有机地增加代码,在适合时应用模式。过早地与模式匹配会导致许多不适当的代码和如此多的抽象层,设计变得模糊不清。见证你看到的任何代码是在第一次发现模式之后写的; - )

答案 1 :(得分:6)

除非模式看起来明显超出规范,否则我不一定会尝试从GoF中挑选一些东西并解决问题,直到它符合模式。

最好从概念上理解你头脑中不同的抽象层次,并提出一个计划(不一定是流行的设计模式)来实现它。这是你在经验上会变得更好的东西。虽然了解GoF模式将有助于提高您在代码设计方面考虑问题的能力,但它们并不意味着能够解决所有问题,并且人为地强迫您的问题适应设计模式可能意味着不必要的复杂性和混淆。

答案 2 :(得分:3)

  1. 弄清楚用例。
  2. 在整个现有设计模式中考虑设计。
  3. 开始实施。
  4. 我认为这里的主要目标是避免重新发明轮子。

    PS。在您通过第2步并且习惯了它之后,您将能够将该步骤集成到第3步中。

答案 3 :(得分:2)

如果我不确定我只是开始编写代码。不久之后,该结构将开始乞求一些重构,并且选择几乎总是显而易见的。

虽然我有时会受到特定模式的启发,但几乎总是代码能够向我显示正确的路径。

我也不怕烧毁和重建程序的某些部分。斯科特·亚当斯(Scott Adams)很喜欢这句话 - “创造力让自己犯错误;艺术知道要保留哪些。”在你以错误的方式尝试之前,有时候正确的答案并不明显。

答案 4 :(得分:1)

我不会因为前期设计模式的使用而过多地模仿你的编码。最好只制作简单的代码,并在需要时refactor towards a design pattern,然后最好地捕获您的需求。

答案 5 :(得分:1)

  

你应该有机地增加你的代码,适当地应用模式。

借调!我见过的一些最糟糕的意大利面是带有很多图案的OO C ++。 Fluxbox几乎无法忍受; Synergy(v2)煮沸,烧烤和烤我的面条:(

我见过的一些最漂亮的代码是OO C,其中OO分别是两个接口加上4和20个实现。

答案 6 :(得分:0)

在开始编码之前,您应该掌握哪些模式适合问题。如果没有,请制作原型,以便了解您想要实现的目标。然后寻找模式并丢弃原型的结构(并重用好位)。

答案 7 :(得分:0)

这里已有好的建议。回答关于GoF书以外的有用模式的问题。有,你应该看看Larman的应用UML和模式,他描述了GRASP模式。