稍微讲两句关于OOD的闲话吧。。关于怎么学，扯淡，以及怎么用

家里有事，消失了一段时间，现在把当初说过的要总结的OOD补上

OOD，从表象上理解是用class来抽象和模拟事物之间的关系，实际上是借助接口与继承这种抽象机制来decouple(解耦合)代码，使得代码结构清晰易于维护。在实践中，大家发现有一些解耦合的方式经常出现，就把它们总结为Design Patterns (设计模式)。很多人在读设计模式这本书的时候会有一种“啊，原来这种写法叫做这个模式”的感觉——然而一本系统性的总结书籍是必须的，1大家总有没用过见过的模式，2设计模式给出了一个交流的基础，举例来说当你讨论一段代码的写法时的时候不用自己在组织内部发明一套语言，或者绕一个大圈子描述细节，而是可以简单地说，我们可以用xxx模式

学OOD，就两本书，一本是大名鼎鼎的Design Patterns: Elements of Reusable Object-Oriented Software，因为作者有四个所以又称GOF/四人帮

另外一本是Head First Design Patterns，相对来说浅显易懂

比较重要的常用的pattern只有：Factory, Singleton, Adapter, Composite, Observer(Listener), Template Method, Proxy, Visitor, Iterator. 如果是临阵抱佛脚的可以多多关注这几个pattern。State，Bridge和Strategy也可以大体看看。

具体的pattern这里就不去讨论了，大家静下心来看书就是。要达到的目标大体上是 1 能够回答，xxx模式如何实现的 2 为什么要使用xxx模式（其优点何在） 3 在什么场景下使用xxx模式。其实不单OOD，任何一项技术能够回答这三个问题，也就算是有一个big picture了。

下面说点关于OOD的闲话。

OOD刚刚被发明的时候，是被很多人认为是Silver Bullet的。大家觉得它从根本上解决了代码reuse(复用)的问题——低耦合高内聚的代码，使得代码的模块化、重复使用不再复杂，进而解决了软件界一直存在的重造轮子的问题——结果我们都看到了，软件界到今天也仍然在重造轮子。软件界没有银弹——OOD不是，SOA不是，PaaS不是，IaaS也不是。说点哲学的，软件的复杂是内秉的：因为人类的需求是基于人类的高阶逻辑的，而计算机至今能满足的是一阶逻辑演算，所以软件界在强AI出现之前不能解决软件的统一解决方案是非常正常的。

当然我们不能说OOD没有解决问题，它毕竟是一种proven technique，在代码层面解决代码的可维护性问题一直都是码农手中的得力工具。相比procedure，它提供了有力的抽象工具，能够使得代码不是一坨互相调用来调用去的函数，而是具有抽象的接口，各司其职；相比functional，OOD的代码可能会显得不够简洁，然而Object Oriented的形式使得它更加贴近人类的思维模式——functional编程虽然强大但至今不成主流，也就是因为这一点了。

另一方面，我这些年在软件业中发现新人普遍具有模式沉迷的问题。这是难免的，因为设计模式都是精炼的前人经验，确实有一些精妙之处。但是设计模式本身是提炼解决问题的方式，实际工作中千万不要用设计模式去解决并不存在的问题。当应用一个设计模式的时候，尤其是感觉到啊这个设计模式用在这里简直精妙的时候，就要警觉一点了。这时候必须谨慎地想清楚，为什么要用这种设计模式，使用这种模式是否多余。举例来说，在两种行为模式之间，是选择if else好，还是用strategy模式？在两个数据库实现之间切换，是否要用adapter模式？

(这样的问题其实并没有统一的答案，都是case by case分析的。)

另外滥用模式也逐渐成为了现在Java程序员的通病。比如用factory，不要直接new之类的已经成为了部分程序员的真理信条；搞个singleton到处用结果成了包了一层的全局变量这种更是比比皆是。一言以蔽之，为了模式而模式，认为使用了模式就提高了代码质量，都是误解。

那么跑题都跑到这里了，代码质量究竟是什么？我本人对代码大概有如下几个方面的要求（很多人也许有不同意见）：
1. 可读性——代码即使以后不被改动，也是有人要读的，如果一段代码三个月后作者自己都不知道写的是个什么玩意，必然不合格
2. 易扩展型——注意，是易扩展型，而不是扩展性。因为扩展性可能是一个不存在的问题，我们不应该为未来不存在的扩展浪费过多的时间，但是如果能够把代码组织成很容易改写成具有扩展性的代码，就可以在开发速度和维护性上做出一个平衡了。
3. 难改动性——想了想没有想到太好的词。这里的意思是说，通过组织代码的结构，使得未来的人难以做出危害代码质量的改动。举个简单的例子，在某个初始化函数里面我们初始化了三个有关联的成员变量，里面还夹了一坨逻辑，这时候把它们extract成一个method，给它一个有意义的名字，这样可以i)使得原有的逻辑不会因为后面的改动被打散，而变得不可读；ii)在增加逻辑的时候，后人会被这个method的名字所约束，不会破坏contract。当然如果你的初始化代码是纯逻辑的话这也是一个加入unit test的理想位置。
4. 无重复性——如果说写代码的时候有什么必须遵守的铁律，这就是其中一条。任何形式的重复代码都是绝不可取的，必须改掉。
5. 最后再推荐一本书，叫做《Refactoring: Improving the Design of Existing Code》，这本书并不是用来面试的，而是讲如何提高代码质量，避免写出烂代码。作为一名合格的程序员，不可不察。

所以回到主题上来，OOD要用，很好，然而你先要权衡用与不用之间，究竟利弊如何。

总结的很精练很到位，是一位干过真活的人

关于第四点，无重复性和低依赖有时是一对不可调和的矛盾
一段代码，如果有10个其他模块都需要用
，重用性是高了，却变成了single point failure，稍微一变整个系统就挂了，如果第十一个也要用但需要多加个参数，怎么测那10个模块就是门艺术了，这个代码就没法重用

无重复性很容易产生高依赖而违背OO低耦合这个目标，哪怕用重载多态解决也会产生相当多的重复，所以没有完美的solution，而是一种根据经验左右平衡的艺术

拜读了。

问一个问题。为什么 无重复性是铁律？我的理解是防止修改程序是只修改一处，导致还是有其他地方没改产生错误。不知道还有没有其他原因。
如果自动产生的程序，改动生成方法时所以程序都会自动生成，这种情况下出现重复总要吗？

对不要直接new的做法，我的理解是提供一个创建factory，用create函数通过factory来实现。好处是给了使用者替换和嵌入的机会。对设计库人还是很有用的。毕竟写lib的人永远无法估计其他人希望怎么用。
坏处是使code平白无故长了很多。要让程序员每个class都建一个factory估计很难。同上如果用程序来产生code。是不是应该自动的给每个class一个factory使使用者有更多的自由来改变程序?

膜拜一下lz

这个太棒了!学习了!

膜拜一下！

One of the GOF is my professor of OOP class

谢谢楼主的分享和分析。

说的不错，谢谢分享

楼主说的很好，谢谢分享

感谢楼主分享

谢谢分享，说得很中肯。确实有的时候感觉是pattern使用的default case，就会忘记思考是否真的合适。