使用设计模式时，如何判断一个问题是否被“过度抽象”了？
2012-01-19 20:19:55   来源：   点击：

5 个答案

• 答案 1：

  我写过一篇《再抽象一点》，可供参考：techsingular.net/...然后，我推荐一篇很好的文章《ORM is an anti-Pattern》：seldo.com/weblog...抽象，是对原有接口的简化，或者说对原有接口常用模式的固化。C 就是汇编的 design pattern。在《再抽象一点》里，我把抽象分成 bottom-up 和 top-down 两种，源自Donald Knuth 的话。归结起来就是这么几条：

  Top-down 是常态。

  Bottom-up 是 top-down 的中断形式。

  纯粹的 bottom-up，要么是大公司的政治产物，要么失败。

  Top-down：不会过度抽象，因为先定 top。Bottom-up：绝对的过度抽象。《ORM is an anti-Pattern》的印证：

  ORM 就是 bottom-up 抽象。

  如果一个 app 采用 OOP 方式，必须用某种方式把 DB 映射成自己需要 object model。这是《ORM is an anti-Pattern》认可的。即 top-down 方式。

• 答案 2：

  设计模式是针对C++/Java这些静态面向对象语言总结的，对于动态语言来讲，很多模式已经是过度抽象了。对于Java这些静态语言，要扩展就要大量运用接口，往往搞得继承层次过深（看Spring的继承类WebXmlApplicationContext估计有7，8层），很多为扩展准备的中间层明显是多余的，属于过度抽象。很多模式从实现看已经过度设计了，实际上要求从语法程度上进一步抽象，以更见的方法实现该模式，这就是动态语言的威力所在。

• 答案 3：

  我习惯用的判断设计过度的简单方法是：

  没有抽象前做一个设计；

  抽象后做一个设计；

  拉一个无关人等过来讲解两个设计，让他/她记录自己听到的概念数目。如果1 > 2 则没有过度设计，反之则过度设计了。

  解释： 我想我们都能够达成一个共识，即抽象的首要作用是让程序员从细节里解放出来。那么当引入一个抽象时，我们得让程序员略去至少多于一个的概念，否则这个抽象就纯粹给我们添乱。如果兄台真的认为抽象的意义在于让我们写程序时需要理解更多的概念，那么咱们就不必谈了。我曾经见过一些自鸣得意的设计，把一个简单的调用DLL里一个函数跑测试的自动化程序分成"Test Definition", "Test Group", 和"Test Case"三个部分，还分别用一个XML文件表示，美其名曰代码组织合理化，而后果是每次调试的时候我们都必须在三个XML文件里来回跳着找环境定义。这种倒霉设计的混账之处在于其具备相当的迷惑性，因为那些稀奇古怪的抽象其实总能够在代码中用到，我们很难对写这种程序的人宣称其中某个抽象没有意义，因为他们总能给你举出例子反驳。但识破这种伪装的抽象并不困难：既然它们无法用于隐藏细节，那么它们要么将自己硬生生地插在已有的简单体系里，要么将某些个系统里原来就有的概念简单改头换面一下换上自己的新名词。所以遇到这个问题时犯不着和那个“架构师”废话，只要数一数开始写程序时需要知道的概念总数，它们自会露出狐狸尾巴。顺便说一句，我一直认为验证这一理论的绝佳实例就是我在 @冯东 的blog里提到的CertOpenStore()。标准的反面教材。

• 答案 4：

  比如有10个人一起讨论问题，当有5个人不知道你在说什么的时候（很茫然的表情），很可能就是过度抽象了。重申并简化自己的主张，必要时用图形表述，情况可能会好点...

• 答案 5：

  个人C语言经验：不要去过度思考这个问题，如果有一个团队，就在团队内充分讨论流程，通过模型图讨论。如果没有团队，在自己可以搞清楚的情况下，考虑未来的扩展。但是如果扩展至依赖于接口，相对还是弱了点。在架构上保持分散比在接口上保持抽象要有效的多。