OOD设计原则之开篇词

        在我想记录些什么的时候，首先想到的就是这些OOD的原则。坦白的说，我自己对这些原则的理解也只能算是一知半解。自己做OOD也算有些年头了，但是在实际项目中，真正按这些原则所要求的那样去设计，我自知还没有达到那个高度。而这些原则就像是这几年年一直大热的设计模式一样，并不能拿来就用，“拼装”出合格的设计或代码；也不能拿着这些做标尺，一个个去检查那些设计和代码。但是，这些原则之所以能成立，能广为流传甚至被奉为圭皋，自然是有它的道理。记得Arthur J. Riel在《Object-Oriented Design Heuristics》一书中说过（原文不记得了），这些也不是法律或者圣经，违背它并不会遭受惩罚。但是应当把他们看作警铃，一旦触犯，警铃就会响起。大概是这个意思吧。

        其实，违背这些原则是真的会受到惩罚。不过，也许遭受惩罚的并不是最初的设计者。也许是你的合作伙伴，你的继任者，也有可能是你代他人受过。这样的情景常常发生在项目完成的时候，测试的时候，再次开发的时候，也许在某个你完全没有在意的时候忽然就跳出来。我看到做很多的项目，连最基本的UML图都没有，除了设计者本人，基本上别人很难了解系统的结构。而这些项目，都统统被称作使用OOA/OOD的项目。所以，夸张的说，现在很多实际项目之所以称为OO，只是因为使用了C++/Java这样的语言，代码里有一堆的class，如此而已。

       为什么会是这个样子呢？这个问题追究起来，恐怕不是我能说明白的。但以我的经验，有两条大约是不会错的。一是来源于教育，一是来源于实践。我教授过几个OO的班，坐在下面的多是根本就不知道程序是怎么回事的毛头小子。他们来学习的目的，只是为了学点儿东西，拿到证书，再出去找个工作。这样的课程，是不能称为OO的，勤奋点儿的学到的也仅是语言本身。将来他们到了工作中，实际的工作也只是coding，一堆做coding的人凑在一起，没有人去做OOA/OOD。就是这样。

        扯的太远了，打住。还说这些OOD原则。我也是做了若干项目，留了无数麻烦给别人也帮别人解决了无数麻烦之后，才真的认识到这些原则的重要。这样的原则其实很多，Riel在他的那本书里，提到了大约60几个。我想记录的，只是其中很小的一部分，那些广为人知，常常被放在嘴边又常常被忽略的几条。大约会有开闭原则、里氏代换原则、依赖倒转原则。接口隔离原则、单一职责原则等等。