不管你是爸爸，儿子啥的,的确是角色的不同，但难道不是多态的表现么？
只要你的爸爸、儿子都指向了同一个实例，那么表现在实例身上的不是多态是啥的
你们都认为实例如果是爸爸，那么他同时也可以引用儿子的行为。把这个东西放到现实世界不就对应了你的角色问题么。在家可以做爸爸，公司里做老总。同样的一个实体，在不同的地方我就引用不同角色的行为。这很正确呀。相信大家都看过变形金刚，人家变来变去，可以说实体（一会机器人、飞机什么的）都发生了变化，但是这个实例是没变的，这不是多态么？

[代jdon007发言]
内容如下：

1、
多态，一般指不同的对象对同样的消息有不同的反应。同样，也可以指同一对象在不同的场景有不同的表现 ，这个是你对术语的含义进行泛化理解的部分。没错，多态这个词的含义如果放开解释的话，又何止这两种 ，至少我还可以说出两种以上的不同解释。但是，讨论问题时总得有一个上下文的约束。

2、你并没有涉及如何实现“同一对象在不同的场景有不同的表现”这一“多态”？如果是使用“多重继承机 制”来实现，可以做到，但与DCI相比，如果你认为多重继承解决得更好、更自然，我也不打算说服你。

3、类的多重继承有其合理的一面，也有其适用的情景。但在这一个问题上，我认为不如DCI解决得好。

TO lqtcts
大道若简，这可以说我们程序员在复杂问题中的一个原则。我们以前谈类的继承时，是在谈一个类“能”在领域中干什么，这如jdon007所言的“合”，高度集中只会降低系统的复用性和扩展性，实践中就是“臃肿”的类，为了追求更高的复用和扩展。所以才会把一部分“合”化为“分”——一个类在某场景“可以”干什么。

你所讲的多态是正确的，但只是一个方面来看待问题。该问题从其他角度，也有不错的理解。当角色类的行为大量重叠时，我们可以“合”，但当相互相互行为几乎无重叠的时候，明显“分”更合理。

回到问题上，父亲、儿子、孙子问题，考虑时，应该从我们系统所要实现的功能出发。当职能只是单单的打招呼之类，完全可以建立一个“人”类，通过继承实现。但当职能是照顾孩子，陪孙子玩，父亲与儿子一起打球，这些基本不重叠，用继承就会产生“万能类”。所以，一个问题，不是一个多态就搞定。

TO jdon007
你谈到的互补，可能是一个场景中使用领域思维，多个场景就像多个领域，而之前多个领域是通过消息来协调，正与多个场景通过事件来协调一样，殊途同归。但我们可以看一下MVC和DCI间的结构区别，MVC是注重纵向分层，DCI是注重横向分层（更多是领域上），某种意义上说的确是互补，但也得注意DCI对MVC的破坏，DCI把MVC中MC模糊起来了，本来Controller只是对用户操作作出响应的，不涉及领域的，但DCI中Context，拥有控制同时却与领域紧密联系，所以从结构上，DCI与MVC间存在很大冲突。若果并存起来，要么DCI就不是DCI，要么MVC就不是MVC了，要说互补的话，只能是“有损互补”（损得不少哦）。

设计模式，你说的除了“设计模式是在局部、微观层面的一种支持变化的机制”，其他都同意，既然涉及场景间的行为模式，就已经算是一种全局概念（大场景）。

好了，吃饭~~~

貌似很有道理！

对于MVC有很多种解释, 比如Model1、Model2、pull-based MVC、push-based MVC、HMVC、MVC++等等。

这里简单解释一下对MVC较常见的两个说法。
1）表现层、业务逻辑层（领域）、持久化层某种意义上可以理解分别对应V、C、M。只是MVC范式内容本身并没有关注持久化的问题，持久化可以作为一种记忆机制隐藏于模型之中，所以确切地说，这种说法并没有表达出MVC范式的本意。

banq的“数据库已死”的观点，我的理解是banq为唤起对领域模型的关注，取了一个夺眼球的标题，事实上数据库承载领域模型的记忆，不会死去，顶多是记忆机制与载体更新换代而已，比如从sql、RDBMS换成noSql、key/value数据库等等。

2）SSH框架集成中，Struts承担表现层MVC, Spring承担控制层IoC, Hibernate承担持久层ORM.此时表现层Struts代表的MVC，更接近MVC的本意，只是将MVC放在同一层了，一定程度上也隐藏了MVC的意义。

MVC最核心的意义在于将界面与模型分开，界面即V和C，模型即M。场合不同，MVC范式的应用和实现方式可能不同，而我们很容易将自己最熟悉的某种具体的实现方式理解为MVC的意义，而具体的实现包含了很多“个性”的东西，可能出现无意识地将MVC的“共性”忽略的现象。

事实上，CQRS范式，在我看来，也是MVC具体的一种实现方式，这个观点读者无须认同和反驳我，这仅仅是个人的理解。基于此，我认为CQRS的出现，只是一种MVC的实现方式代替另一种MVC的实现方式而已。

Trygve Reenskaug在介绍DCI时，是将model和controller中的一些东西抽离出来放入场景context与交互interaction中，这是说明两个范式含义的“联系”或“差异”，但不是说DCI范式与MVC范式不能“结合”。在Trygve Reenskaug的其他文章里，有介绍使用Squeak(Smalltalk的一种实现）编写的MVC与DCI范式结合的例子。

banq说的MVC已死的观点，我也同样理解为是一种“夺眼球”的宣传策略，不论CQRS还是DCI都不会使MVC死去，CQRS是MVC的一种实现方式，在GUI应用已经出现过了类似的方式，现在不过将一整套实现方式搬到Web应用上，并取了一个新的名字而已。DCI在MVC将界面与模型划分基础之上，对模型进一步划分，是对系统的“二次划分”，也没有取代MVC，随后会做出一些补充解释。

在回答前一段时间关于“领域建模的意义”与“OO的最初梦想”的问题之前。先陈述一些简单的常识，以便回答时使用。

banq曾说看“事物”的终极两种方式，这里我强调看“系统”的两种方式。

第一种方式是从系统的外部或整体看(Thinkig out of box)，将自己置于一个更广阔的背景来看系统或问题，比如看企业软件开发，不妨站在软件开发的角度，因为企业软件开发不过是软件开发的一种；看软件开发，不妨站在人类活动的角度，因为软件开发不过是人类活动的一种。这也是“象外行一样思考”的意义之一，寻求一个更广阔与深刻的视角。

第二种方式是从系统的内部或局部看(Thinking in box)，让自己亲临其境，进入系统或问题的内部，看清楚内在的结构与规则，分而治之，降低和控制问题的复杂度, 使自己的智力可以从容地掌握这局部有限的复杂性。这也是“像专家一样实践”的意义之一，寻求一个更简单与清晰的视角。

Thinking out of box, Thinking in box之间的相对及互相补充的关系，前面的讨论中已经有谈到了一些，不重复了。

Thinking outof box和Thinking in box，可以作为我们对系统进行思考的基本视角。这是常识，每个人都已经具备了，只要你意识到这点，就几乎不需要学习成本。下面对MVC、DCI、DDD等的解释就使用了这些常识。

鉴于细胞学或人体学专家flyzb已经在其帖子《对领域驱动设计的初步认识（九）》对我这个新手下了这个“逐客令”，幸亏flyzb不是banq，否则按他的话的意思我就必须离开jdon了，所以现在只好在自己的帖子说说自己对DDD的认识了。

领域建模（DDD)的意义与OO的最初梦想，简而言之，即在代码中捕捉用户的心智模型，代码是程序员的心智模型。用户的心智模型是从系统的外部看系统，程序员的心智模型是从系统的内部看系统，共同之处即系统的模型，包含两部分，系统是什么？系统能做什么? OO的最初梦想：软件和计算机作为人类的伴侣，是人类记忆与智力的一种延伸。对程序员而言，就是上面所说的使用代码捕捉用户的心智模型。

MVC的可贵之处，在于将系统的界面(VC)与系统的模型部分(M)分离，而DCI则是告诉我们如何在代码中捕捉用户的心智模型，将系统的模型分为两部分数据模型(Data)与场景(Context)，场景包含了数据模型之间的交互行为(Interaction)。由于数据模型之间的交互，其扮演了相应的角色(role)。数据模型表示“系统是什么”的部分，场景表示“系统能做什么”的部分。

DDD也是用来捕捉用户的心智模型。但远不如DCI简洁，个人以为DDD中最重要的概念只有两个：实体与服务，其他的概念都是围绕这个两个核心概念进行补充或组织的。我有一个比喻将实体比作演员，服务比作剧本，作为领域建模即拍一部电影最核心的两个要素。

实体与服务相当于DCI的数据模型与场景，DCI的可贵之处，在于表明数据模型扮演各种角色的原因：Interaction（交互行为或相互作用），并用场景这个概念捕捉了交互行为。

MVC与DCI是互补的范式，MVC将系统的界面(VC)与模型(M)切分开来，DCI将系统的模型中的数据模型(D)与场景(CI)切分开来。这是我说MVC与DCI互补的范式的最重要的原因之一。

对于MVC与DCI可以说的东西，远不止这些，我已经从不同的角度写了一些文章，不过因为是新手（所以请读者自行判断文中观点的合理性），其他的看法都不想公开了，作为自己个人感悟的日记，以后碰到合适的人、合适的场合，再拿出来分享了。

每个人在一定程度上都“生而知之”，上帝赋予每个人的智慧足以“与上帝对话”，如果我们足够真诚的话。先行者的存在意义之一在于帮助后来者更好地发现蕴藏在他们自己身上与大脑中的智慧，这使整个人类的智慧得以薪火相传。这是我对智慧的信仰。