面向对象：我看所谓的充血模型和贫血模型

 

 

 

在网上看到这样一段关于对象设计的说法：

充血模型其实很简单，就是面向对象设计的本质：“一个对象是拥有状态和行为的”，比如说一个人，他眼睛什么样鼻子什么样这就是状态，人可以去打游戏或是写程序，这就是行为。为什么要有一个“人Manager”这样的东西存在去帮人“打游戏”呢？

举个简单的J2EE的例子，设计一个与用户（User）相关的功能，传统的设计一般是：
类：User+UserManager
保存用户调用：userManager.save(User user);
充血的设计则可能会是：
类：User
保存用户调用：user.save();
——User有一个行为是：保存它自己

 

 

User保存它自己，这是什么逻辑呢？我觉得非常奇怪。

 

用户用户可以保存自己，那么用户也可以删除自己了，这个和面向对象的最初思路就不一致了，因为在“用例”阶段，就没有用户“删除自己”的用例。

 

所以我的意见，就是一个“行为”到底放在哪里，肯定是要由用例决定的。

 

“人Manager”是一个不伦不类的概念，人自己“删除自己”更是荒谬。

 

我的理解：

 

“保存”和“删除”本身是系统提供的一个功能，它的宾语，或者说“作用对象”是User，而主语不是，面向对象的概念，封装、多态是手段，本质和神髓是用真实世界考虑问题的方法来分析来设计，那么，分清主语和宾语就是必须的。

 

一般来讲，方法调用应当是

 

主语.动作（宾语）

 

而不应当是

 

宾语.动作（）

 

从实际实现上来讲，好像也不会有什么大问题，就行“人删除自己”这样的行为，但是，如果把代码和设计当成一个场景或故事的陈述，那么，每一个句子，都缺失了主语，拿宾语当成了主语，这是典型的逻辑不清楚。

 

所以，所谓的“充血模型”、“贫血模型”只是设计领域里的概念，而且是纯粹设计和实现层面的概念，实际上讨论这些的意义和价值都很低的。面向对象分析，首先应当确定一个动作的发起者或者叫“源”是什么，被操作对象是什么。

 

我是一个比较质朴的程序员和设计师，有些偏执和执拗，但是我一般不会屈从于任何权威和流行的东西，我有我自己的方法论和价值取舍。我一向喜欢从事物的最最本质触发来分析问题，评判优劣取舍。所以，我的观点，可能很多人看了觉得怪怪的。其实我也是一家之言，一孔之见，写出来，希望能够整理自己设计方面的思路和心得、希望能给别人一些不同的观点和思路吧。

 

 

评论

4 楼 windshome 2013-07-18  

vavi 写道

程序是对业务的抽象，之间肯定是有差距的；只能更加的DSL化，这是个趋势，也需要注意平衡；在ruby中，很容易做到dsl；在java中，则比较困难。

在很多书籍中，将object.behavior 描述为 “向object对象发送一条消息behavior ”。  程序语言设计这方面的书籍我目前看的很少，只能是自己的一些粗浅理解了。

TOP-DOWN适合一个对整体比较熟悉的人，BOTTOM-UP则比较适合对陌生的领域，需要自己做很多摸索，总结，然后再得出结论。然后给老板汇报时，再是TOP-DOWN。

我看不少地方提到DSL，但是不理解是什么意思，兄弟能够解释一下吗？近年来名词太多了，实在需要好好学习。

另外，我的理解：一条语句，应该是主语.动词(宾语)我觉得是一个正确的语言规范，可以没有宾语，但是不能在主语上模模糊糊啊。

3 楼 vavi 2013-07-18  

程序是对业务的抽象，之间肯定是有差距的；只能更加的DSL化，这是个趋势，也需要注意平衡；在ruby中，很容易做到dsl；在java中，则比较困难。

在很多书籍中，将object.behavior 描述为 “向object对象发送一条消息behavior ”。  程序语言设计这方面的书籍我目前看的很少，只能是自己的一些粗浅理解了。

TOP-DOWN适合一个对整体比较熟悉的人，BOTTOM-UP则比较适合对陌生的领域，需要自己做很多摸索，总结，然后再得出结论。然后给老板汇报时，再是TOP-DOWN。

2 楼 windshome 2013-07-18  

vavi 写道

借LZ宝地,说下自己的看法:

1.一直对那些名字(buzzword只有恨了)既爱又恨,恨是因为不知道它什么含义,郁闷..爱是因为一旦了解后,很容易明白它的内涵外延,交流的时候很方便.

2.充血模型的对象是行为比较多,贫血对象则反之.user.delete可以理解程序员命令该对象自.杀了;service.delete(user)可以理解为程序员命令service(杀手)杀.死user

3.在java世界中,还是贫血;在rails世界中,必须充血.

所谓的 程序员命令该对象自.杀 和 程序员命令service(杀手)杀.死user 从业务角度是不合适的，因为设计和代码是陈述业务的，是设计师和程序员我他们的语言描述业务。


其实从下往上看，很容易理解这些名字，我只是觉得设计师大多数情况下，应该自顶向下来设计来分析，这符合人类的思维方式和习惯。从自顶向下设计的角度看，应该对业务一层层分析，不应该用设计干扰业务。

1 楼 vavi 2013-07-18  

借LZ宝地,说下自己的看法:

1.一直对那些名字(buzzword只有恨了)既爱又恨,恨是因为不知道它什么含义,郁闷..爱是因为一旦了解后,很容易明白它的内涵外延,交流的时候很方便.

2.充血模型的对象是行为比较多,贫血对象则反之.user.delete可以理解程序员命令该对象自.杀了;service.delete(user)可以理解为程序员命令service(杀手)杀.死user

3.在java世界中,还是贫血;在rails世界中,必须充血.