纵观当今的软件设计，无怪乎大家都提倡以UML为指引，面向对象的思想做为基础进行系统的设计，诚然这样的提法确实是正确的，因为一个软件不论大小，总存在一定的软件生命周期，如果一开始设计不好，只是为了图快，那么最后倒霉的肯定是自己，因为图快设计出来的软件结构肯定存在很多问题，最主要的就是业务分析不明确，架构黏合在一起，在软件信需求出现的时候或者需要改动的时候，这种改动做消耗的成本是惊人的。因此在设计软件的时候一定要有一个详细的规划，一个好的架构模式才行。
面向对象的设计方法目前被认为在IT界是最主要的设计方法论，基本上大型的，正规的公司都在使用，我个人也认为它是目前最好的设计理论。因为面向对象的思想理论可以对要做的东西进行抽象化，然后具体化，最后又抽象化，起始是在自然语言和机器语言中搭建了一个桥梁。情况也确实如此，现在基本80%以上的软件都在使用这种方法进行设计。我也是它的坚定支持者。
但现在就出现了一个问题，我的理解是 【伪面向对象】现象的存在。
什么叫【伪面向对象】？
面向对象是将业务需求的自然语言转化成遵循一定标准的可让参与者有共同理解的抽象化概念。因为对于一个业务需求的自然语言描述，100个人可能就有100中理解或者派生出不同的分支，因此将其抽象化成大家有共同理解的概念，至少能让这些分歧减少到最小，让大家都明白要做哪些，哪些隐形的可以不做，哪些隐形的确一定要做。其实这就是业务建模的一个过程，其包含了业务需求到业务模型的过程。
而【伪面向对象】呢？就是直接将业务需求转化成物理模型，而不是经由业务模型->技术模型的过程。
为什么这么说呢？面向对象是以对象间的关系来描述自然语言中的自然关系，而这种对象的关系是足够表达清楚这种抽象关系的，那么我们看物理模型，物理模型实际是集合类的数据排列，比如：某张表，某个视图。表间只能表达主外键关系，很难表达出集继承，多对多，一对多等等这样的关系，而对象关系就能轻易表达出来。打个比方：在一个数据库关系图上讨论对象间的关系，或在一个对象类图上讨论对象间的关系是否合适，哪个更清晰？很明显是后者。但很多人在设计系统的时候，往往直接由业务需求向物理模型转化（我们当然要排除那些牛人），我觉得这是非常不对的，这往往就是悲剧的开始。
那么应该怎么做呢？一个比较好的顺序是：业务需求->业务模型->技术模型->物理模型
即从上而下的流向设计。
用这样的顺序分析出来的系统，才能说是业务明确的（我不否认直接到物理模型的设计方法也可以做出好的系统，但看过上文应该清楚，可能做为系统设计人员能明白，但做为开发人员呢？不一定能明白物理模型中暗含的各种关系）
举例：
三种对象关系在对象图上明明白白，但如果在数据关系图上呢？
就是一个主外键关系，看这个图，恐怕当事人还要去仔细思考一下，到底是上面哪种关系呢？，如果稍微不注意，就可能导致出错（这还不包括中间表的情况，如果是中间表的情况，这个图就是错误的了）。
而【伪面向对象】设计方法就会造成以上的情况产生，真正的面向对象方法在对象设计的时候就已经确定了，因此根本不可能出现在物理表阶段出现的这种问题。
补充：
看下图
对象图上是一个组合模式，一看一目了然。以下是转化的物理模型图。（该转化采用了类表映射原理，即一个类或接口映射成一张表的模式）
哪个图可以更好的看清对象的关系，如果只看物理模型图，很难明白这是个组合模式的关系吧，直接看物理模型图开发代码，很容易把关系搞错的。对象图包含了继承，关联关系，而物理模型只有主外键关系。
