大象进冰箱和软件设计的关联性

 怎么把大象放进冰箱里：打开冰箱门，大象进去，关上冰箱门。

 就从软件设计上讲，我觉得绝对不是笑话，而是很经典的一个成功的范例。

 首先，我们需要明确的一个问题是在设计阶段，我们需要的不是具体的实现方法的考虑，不需要太过于细节，特别是一些大型的项目，不然你会陷在某个技术要点里不能自拔，而拖延了整个项目的设计工作。在OOD中，我们需要抽象，在UML我们称之为建模。我们将需要的步骤进行抽象，于是得到这样的三步。

  如果我们仔细想来，这样的设计是很有道理的。比如打开冰箱门，为什么呢？我们在这里提供了一个很大的接口在这里，因为，我们不知道我们将要处理的冰箱是多大的冰箱，可能只是家用的超小冰箱，也可能是刚好大象大小的，更有可能能装下整个非洲平原的。我们并不知道，在设计阶段，我们也不需要知道。这为我们后续的工作留下了很多可以更改的空间。说不定我们会换冰箱的。

  至于大象进去，同样是有讲究的。如何让大象进去，虽然这个方法的实现是有点让人头疼得，但是我们不保证我们需要自己去实现。或许我们可以自己实现，或许我们可以先实现个不怎么样的，在将来找到良好的方法后再替换调他，又或者，干脆外包出去，用个第三方办法。管它呢，只要能让大象进去，就能满足我们的需求。

  最后，也是我觉得做的最好的部分。关上冰箱门！我曾经记得一句话叫做关上每一扇你所经过的门，这是生活哲理，不是软件工程的概念。但是他对软件来说是多么的重要啊。在这里，关门可以说是一语双关，不仅仅是整个设计的最后阶段，也是对整个软件开发过程的一个警钟。连后门都已经考虑到了，我敢说这个案例，比我做过的所有的作业都要好，我服输了。

  其实，就我个人的理解，大象和冰箱可以被理解成很多的东西。在过程化语言中，大象是数据，冰箱是子程序。在面对对象中，大象和冰箱都是对象，我们只是在使用他们的方法。

  再仔细想想吧，这设计对所有的冰箱，所有的大象都是适用的，他能够在任何场景适用，这不就是我们要的FrameWork嘛。 就比如B/S模式一样。

  说的比较搓，大家见谅。。。嘿嘿。。。轻拍。

  不要打脸。