【发布时间】:2009-05-26 11:31:46
【问题描述】:
我正在开始一个全新的项目——我应该查看我的规范并决定应用哪些设计模式,还是只是想出一个组织的总体概念并让模式通过重构有机地出现?
根据您的经验,哪种技术效率最高,并且更有可能产生干净优雅的代码?
我还想知道是否存在 GoF 未定义但同样有价值的设计模式?如果是这样,有哪些有用的资源可以让自己了解这些?
【问题讨论】:
标签: design-patterns architecture refactoring
我正在开始一个全新的项目——我应该查看我的规范并决定应用哪些设计模式,还是只是想出一个组织的总体概念并让模式通过重构有机地出现?
根据您的经验,哪种技术效率最高,并且更有可能产生干净优雅的代码?
我还想知道是否存在 GoF 未定义但同样有价值的设计模式?如果是这样,有哪些有用的资源可以让自己了解这些?
【问题讨论】:
标签: design-patterns architecture refactoring
您应该有机地扩展您的代码,应用适合的模式。过早地匹配模式会导致大量不合适的代码和太多抽象层,从而使设计变得模糊。见证你见过的任何代码,这些代码是在有人第一次发现模式之后编写的;-)
【讨论】:
除非一个模式似乎明显超出了规范,否则我不一定会尝试从 GoF 中挑选一些东西并锤击问题,直到它符合该模式。
最好从概念上理解您脑海中的不同抽象级别,并为您将如何实现它制定一个计划(不一定是流行的设计模式)。有了经验,你会变得更好。虽然了解 GoF 模式将帮助您提高在代码设计方面思考问题的能力,但它们并不是每个问题的解决方案,并且人为地强迫您的问题适应设计模式可能意味着不必要的复杂化和混淆。
【讨论】:
我相信这里的主要目标是避免重新发明轮子。
PS。在您多次通过第 2 步并习惯之后,您将能够将该步骤整合到第 3 步中。
【讨论】:
如果我不确定我会开始编写代码。不久之后,结构将开始要求进行一些重构,而选择几乎总是显而易见的。
虽然我有时会受到某种特定模式的启发,但几乎总是代码能够为我指明正确的道路。
我也不怕烧毁和重建程序的某些部分。我非常喜欢 Scott Adams 的一句话——“创造力是允许自己犯错;艺术是知道要保留哪些。”有时,除非您以错误的方式尝试,否则正确答案并不明显。
【讨论】:
我会避免通过前期设计模式使用过多地对您的编码进行模式化。最好只编写简单的代码,并在需要时使用refactor towards a design pattern,这样可以最好地满足您的要求。
【讨论】:
您应该有机地扩展您的代码,应用适合的模式。
第二个!我见过的一些最糟糕的意大利面是带有很多模式的 OO C++。 Fluxbox 几乎无法忍受; Synergy (v2) 煮、烤和烤我的面条:(
我见过的一些最漂亮的代码是 OO C,其中 OO 是两个接口加上 4 个和 20 个实现,分别。
【讨论】:
在开始编码之前,您应该了解哪些模式适合该问题。如果没有,请制作一个原型,以便您了解您想要实现的目标。然后寻找模式并丢弃原型(结构)(并重用好的部分)。
【讨论】:
这里已经有了很好的建议。回答有关 GoF 书以外的有用模式的问题。有,您应该查看 Larman 的 Applying UML and Patterns,他在其中描述了 GRASP 模式。
【讨论】: