OO的设计模型，数学模型，物理模型

OO的设计模型，数学模型，物理模型2011-12-29 博客园发条橙子第一次看到OO这个概念是在一本C++的书里面。里面举了个动物的例子。讲禽类，哺乳类，昆虫等等动物的继承关系，多态，等等概念。想起大学时候读的C语言里面的一张程序逻辑图。感觉这个OO实在是太神奇了。再后来接触到.net 。开始基于.net平台，用C#语言编写程序。一开始感觉相当好，文件操作。用一个System.File 搞定。要扩充功能的话。自己自定义一个类，把System.File的功能拿过来就是。很舒服哦。这种感觉持续了两个月，等做到项目的中期，代码越来越多。结构越来月复杂。开始变的沮丧起来。原有功能保持不变，同时，要新增新的功能还要保持原有功能正常运转。我的天啊。我开始做起意大利面了。用更复杂的方法解决越来越多的问题。我开始反思这个OO了。OO到底是个什么概念。从设计到现在的意大利面。OO到底干了什么，我又干了什么。

设计阶段

用OO设计是一件很舒服的事，举例：两个人下棋

设计一个下棋的场景：拿生活中的例子看很容易看出至少三个对象，棋盘，下棋的人两个人如果再抽象点,就两个对象，下棋的人和棋盘。对这三个对象做一个分析，属性字段，值，方法，接口等等，是不是可以动手写代码了。好舒服。

和结构性设计比起来，简直太舒服了。Class player ,Class player,Class Chessboard……里面要填什么功能的话，加方法，加接口，就算你的对象面向扩展，面向修改全开放。都没关系。就算你不懂i/o,不懂cpu，没关系，.net 有现成的类库。拿来使就是了。好了，我们大功告成了。

伪代码

Public Class Player : Status: name,ID Function: Do（），Show（）,UserInterface（）;

Public Class Chessboard :Status: Color , Schema Function : Run（）; HandleError（）;

就这么简单吗？

如果我们就这么写，就又会发现很多的问题，棋盘规则需要建一个对象吗？用户接口需要建一个对象吗？还是当一个属性，用户是用抽象的类描述还是用实体类，棋盘呢？用form做用户接口吗？fom程序又怎么设计？等等。。。。。

等我们满头大汗的硬着头皮写完了。第二天，经理发话了。我们需要在这个设计中加一张凳子。那还不简单，再建一个凳子类，Class Stool.好。凳子给谁使用呢？放那呢？Stool怎么显示呢？是不是又要把棋盘的显示再抄过来，改几行代码。如果，显示又要换成浏览器呢？是不是又要考虑改动其它的代码？

等再过两天.经理又说了：我们要加个空调。而且要有一个用户的接口，我们这个空调还要有收电费的功能。

我的天啊。直接崩溃了。当你看着自己写的上万行甚至几万行恶心的代码。想死的心都有了。如果您耐心的读到这，肯定有些朋友会说：唉。你去读读设计模式吧。你的设计有问题，那么请问：有没有一种设计模式能在一开始就解决后面的扩展问题？就算你经验再丰富，设计水平再高。你就能保证你的模式能面对一个一个神奇的需求？只是加个接口加个属性或是价格对象就能解决问题？