OOD对现在的程序员来说并不陌生，甚至在不知不觉中使用着。

OOD，面向对象设计，关键在于对象的“设计”。一个对象，通常是数据+方法的封装，public对外接口，private或protect内部实现细节，必要情况下public出ReadOnly内部成员状态。

对象设计的过程，会碰到各种场景、问题。从而总结出各种“设计模式”。对于具体的各种设计模式和对象设计原则。这里就不作细说了。谈谈这个月来，碰到的一些问题。

最近在实现一种比较符合目前产品状况的撤销重做，是一种基于内存状态的撤销重做。这种撤销重做，只要求监视业务模型对象即可。所以要求程序架构要能满足MVP设计模式——Model-View-Present。Model只纯粹提供业务方面的对象数据，View为表示层提供各种展示方式，相当于关系数据库提供的表视图，而Present则是人机交互界面。

可能是因为实际实现过程中，并没有人严格意识到，Model-View之间的严格界限；又或者是“偷懒”缘故。很多本来应该是在View层面体现的东西，放在了Model。这种会造成什么影响？第一，首先的Model的可重用性，因为与具体的展示View产生了“依赖”；第二、View要求的变化，会影响到Model；第三、影响后续功能扩展，比如这次的撤销重做，不得不把这个View层面的东西，也纳入内存监视范畴。

总结，1、组内成员必须都能意识到整体的架构设计原则，清晰认识对象职责；2、代码评审，要能做到：检查每天提交的单元。

另外一个问题，这个比较细点——关于对象设计。很多时候，实现一个对象时，通常是把这个对象需要的东西，都作为其成员存在；Destroy时，再释放这些成员。咋看没什么问题。但是从另一个角度看的话，还是可以发现可以改进的空间——内存。

细致分析对象成员，原则上，只有反应对象状态的数据，才可以成为对象成员；而对于那些，在某几个方法内使用的，甚至只在一个方法内使用的，不应该提升为对象成员。有些程序员为了方便，把在几个方法内使用的数据，定义在类中，这样不必给每个方法定义参数。这样做不好的影响，首先太占内存了；有些子对象，本可以考虑作为单例模式提供服务的，却在对象内部创建出来；有些只需要特定方法内产生的，也被提升为对象成员，创建出来。其次，随着业务扩展，业务对象开始变得“臃肿”了。

目前，程序单元还存在几个“超级类”,基本是这样累积下来的。当然，这里面一部分原因是，架构的“迭代设计”一直没有执行。