为什么C#舍弃C++中的多继承而支持单一继承与多接口继承呢？-c#-CodeGo.net
为什么C#舍弃C++中的多继承而支持单一继承与多接口继承呢？
个人学习C#的，想不明白，是出于什么设计目的而改变这种继承方式的呢？
本文地址 ：CodeGo.net/1306304/
-------------------------------------------------------------------------------------------------------------------------
1.发完不能改。改句话。“也就是说在程序中，父亲是可以有不继承这一特性的”改为“也就是说在程序中，父亲是可以有无继承这一特性的”
1一个类从另一个类派生除纯虚函数，没有任何要求子类必须override它的virtual函数----------------------------------------------------------我想我并没有要求子类必须overide&virtual函数，我只是根据我的要求显式的指定draw函数的实现
之所以这么干，是因为我确定如何手工解决二义性
另：java里面的函数都类似virtual函数不知道c#是不是这样
2如果两个父类同名函数有几十个怎么办&（//这里只是研究语言，不要讲设计不合理 CodeGo.net，因为有可能父类是不同的人设计的）-----------------------------------------------------------那种情况你就要考虑设计是否合理，如果是一个拙劣的抽象导致的丑陋的设计
你需要重构而不是将就
另外，为什么要将设计层放到语言层面来解决呢？
class&AuxLottery:&public&Lottery&{public:virtual&int&lotteryDraw()&=&0;virtual&int&draw()&{&return&lotteryDraw();&}};class&AuxGraphicalObject:&public&GraphicalObject&{public:virtual&int&graphicalObjectDraw()&=&0;virtual&int&draw()&{&return&graphicalObjectDraw();&}};class&LotterySimulation:&public&AuxLottery,public&AuxGraphicalObject&{public:virtual&int&lotteryDraw();virtual&int&graphicalObjectDraw();...};scott&meyers&举的AuxLottery的例子，实际上为隐性的引用draw&而采用夹层+wrap的方式下放出两个纯虚接口
杀敌一个自伤两个，这个买卖不合算
我认为这是一种更糟糕的设计方式，而不是代替方案
其一，违反复用的原则，其中，没有复用到些什么，除对上保持draw接口的统一外，没有啥东西是复用的
其二，作为类体系来讲，为一个隐形的引用，多增加两个辅助接口，还下放到最底层的类实现
比起将冲突的继承特征重新显式的指定重新赋以新的涵义，这种方式更差劲，没必要为表单上的&多重继承&而束缚自己的手脚
so.这个不是合适的例子
在类(概念)体系中，处于上位的类(概念)，必定比下位类（概念）拥有更少的内涵，(下面将类等同于概念，建议对这些名字感觉迟钝的，自己去弄懂客体，特征，概念，内涵，外延这些名词的意思，当年我花半个月的时间才理清这些名字的概念和关系，这些逻辑学上的东西将更有助于作软件设计析)下位类是添加更多内涵的类，这是我们之所以用继承的方式进行复用的原因，对一个类的下位类，根据不同域可有好几种不同的划的标准，这些标准将会导致会有不同的侧重区特征的内涵加入子类
多重继承就是expect在同一划标准或者不同划标准中，能够拥有这些不同的上位类的概念特征，可以假想一下，每一个概念代表一个特征的集合，比如上位概念A&上位概念B&以及我们要的下位概念C不管上位概念A和上位概念B处于何种位置，相对于A和B来说，无非是A和B有交集，A和B没有交集A和B有交集的情况就没有任何异议，做为多重继承，不会存在任何的二义性
对于A和B有交集，那么A和B要处于一个同一颗树里（你大约知道菱形继承为什么会存在吧），否则，要么这个交集将不是我们需要关注的，要么，我们的抽象出问题
如果交集中的特征中，型和值都一致，那么，这是最好的情况，也不会产生任何的二义性问题因为不管是A的特征还是B的特征，都是同一个玩意儿，如果型相同，值不一样，这就存在冲突，那么我们需要考虑，到底是采用A的值，还是采用B的值，还是需要自己赋以新的值才能符合要求
(如果型不同...天，那不可能...)我们expect不做任何的改动就能将冲突部解决，这是不现实的，因为我们没有给编译器足够的信息，即使有这个信息也不知道如何传递给编译器，只能手工来解决。如果在问题域内，通过巧妙的设计，还是能避免二义性的
如果能达到这样一点，那将是最大程度的发挥多重继承的效用
如果我们能够完全利用父类的所有特征，而在用的过程又出现scott&meyers的所举的这个例子，那就可能出现两：优先，在该问题域内，某些层面的类划标准并不清晰,导致冲突出现
第二，层次抽象并不合理，我们可能对父类有太多的expect，加入太多的内涵
尽管scott&meyers是大师，但是思考是属于我自己的，我的想法不一定对，但目前我还没有能说服自己放弃自己的想法。不是狂妄，而是认真
今天酒有点喝多，姑且妄论之
to&be&continue...
我是这样理解的，C#并不是单一继承每个类都默认继承object这个就像是蚁后，然后能够初始的制造ant，然后有雄蚁（基类）两个结合又能产生新的ant（子类）继承接口就像是学会什么技能，新的ant继承搬东西接口，它就变成工蚁，当然或许还要继承吃饭接口等等
同样继承打架接口的，就变成兵蚁
这样在逻辑上就显现比较符合思维习惯多个继承的话，条理上就比较混乱，就像一只ant是由工蚁雄蚁加兵蚁雄蚁加蚁后产生
……这要怎么理解，而且为制造这样的东西，我们还不得不去做&工蚁雄蚁&和&兵蚁雄蚁，可是雄蚁中却又不存在这样的品种所以我个人觉得这样的继承是为更加符合逻辑，还有就是C#是结合Java衍生的
编码时优先考虑使用对象的合成/aggregation，而不是继承，这样有利于类的封装，当需要多重继承的时候不妨考虑用用合成aggregation
我觉得也是对面向对象一种取舍。一些不常用的函数就能自然就取消掉。
关于多重继承的二义性，是在编译期就可以检查出来的，也有，不能算是一个缺陷，只不过是复杂一点（主要集中在编译器的实现上，而不是设计和使用上），不过现实就是这么复杂的，他只是忠实的描述现实而已
==c++&编译器可以这么实现，因为c++是源代码级面向对象，C#确不行，.net&下所有对象都是继承与object，多重继承的避免不菱形继承，那样只有不让所有类继承于object，那么动态加载，垃圾回收所有基于运行时的面向对象部怎么实现？
ls的，我没有看过ec++我认为熟悉cpp语言，靠&cpp标准语言特别版&nbsp，&cpp设计与演化，&cpp&gotchas，就够，昨晚我特地花半个多小时的时间认真地读&ec++&43，通读一遍之后，我大致理解作者意思，但是实在太累，我就只针对优先部发表些看法，你再仔细，作者提出来的解决方法是否和我的一样
晚上有空再忽悠。
ec++&43中&scott&meyers&关于多继承的论述，我并不尽赞同cpp多重继承，但是不至于强大到为所欲为比如传说的人马，假设是从人和马两个继承下来的，那么人马到底是用人的方法跑还是用马的方法跑呢？我们人脑可以根据人马的形象，下半身是马，那是用马的方法跑，如果我以前都没有见过人马的形象，那我也判断不到底人马是用人的方法跑还是马的方法跑，人都无法判断，何况只拥有那点有限的规则的编…不同意别人观点，至少你要理解，别人的观点，书也是如此，你不同意ec++&43&,至少要把它读完
你所说的，书上早已经给出，但这种方式是非常awk的，1一个类从另一个类派生除纯虚函数，没有任何要求子类必须override它的virtual函数2如果两个父类同名函数有几十个怎么办&（//这里只是研究语言，不要讲设计不合理，因为有可能父类是不同的人设计的）以上只是一个小小如果是菱形继承怎么解决pubilc&class&a{public&virtual&void&test();}public&class&b:a{public&overrider&void&test(){}}public&class&c:a{public&overrider&void&test(){}}public&class&d:b,c{}a&temp&=&new&d();temp.test()&//??所以ec++43&给出的方案就是多重继承下要避免菱形继承
有些人说：“有些人之所以被称为，是因为他们在思想上走的更远。”那么---水晶剑锋.林公子---足已被称为，就算不是，至少也是一个“思想者”
因为他考虑问题比一般人站的都高问题比一般人更客观，对事物认识的比一般人更深。
ec++&43中&scott&meyers&关于多继承的论述，我并不尽赞同
cpp多重继承，但是不至于强大到为所欲为
比如传说的人马，假设是从人和马两个继承下来的，那么人马到底是用人的方法跑还是用马的方法跑呢？我们人脑可以根据人马的形象，下半身是马，那是用马的方法跑，如果我以前都没有见过人马的形象，那我也判断不到底人马是用人的方法跑还是马的方法跑，人都无法判断，何况只拥有那点有限的规则的编译器呢？没被足够的信息作判断，二义性是无法自动消除的
所以我觉得scott&meyers举的例子本身就不恰当
我不觉得我下面的代替方案有啥不妥
class&Lottery&{public:virtual&int&draw(){printf("\nlottery::draw");};};class&GraphicalObject&{public:virtual&int&draw(){printf("\n&GraphicalObject::draw");};};class&LotterySimulation:&public&Lottery,public&GraphicalObject&{public:virtual&int&draw(){printf("\n&assume&draw");return&GraphicalObject::draw();};};把&lottery&==&人,GraphicalObject==&马,LotterySimulation==&人马draw==&跑&就是我想要实现的东西
在冲突的地方我显式地指明，如果除跑这个动作外，如果我想用的其他的东西都没有逻辑上的冲突，那用隐式继承下来的东西，我想还是利还是大于弊，如果大部的东西都存在冲突，那么就需要考虑设计的合理性，也许那并不适合用多重继承来复用
to&be&continue......
sjjf兄写的太长，有没有中心句什么的放在段首，我看的头，就看一贴，相当有文采，能忽悠-------------------------------------------本来就在乱弹，何须中心？继续昨天的忽悠
在讨论oo之前，让我们回头我们人类的一些基本认知
以下观点纯属个人的扯淡，如有雷同，纯属偶合&:)几百万年之前，我们的祖先茹毛饮血，所见所闻也基本是口舌相传，知识的积累基本是新增和流失相对比例不会变化太大，也许新增比流失要多一点点，我认为在一段时期内，知识的新增和流失比例不会变化太多，因为人脑的内存和检索是有限制的
这种状况直到其中某一个聪明的祖先学会外物作为载体进行知识存储
例如木绳记事。这将使知识得以脱离口舌进行传承
从此在一个部落内，如果知识存储规则明确后，知识的流失量几乎成0
虽然知识已存储，但是受限于部落规则的制约，成为信息孤岛
知识孤岛之间不能流通和融合。可以想象一下当时的格局，在苍茫的大地上，遍布大大小小的原始部落，这些部落之间都有自己的知识储备，就像星星的火种，一点一点的顽强的闪着，随时都可能会随着部落的消亡而熄灭
随着进化，这些部落的学会沟通，的在局部地区，语言开始有交集或者开始统一。为部落之间的规则的流通提供可能
直到区域的部落之间统一的文字，规则的流通才畅通无阻，解读规则，也就能使知识融入在一起，从此，知识在区域之间开始雪球效应，那些星星之火终成燎原之势
发展到今天，已走向全局的文字和语言的统一，虽然不是表单上的统一，但是至少语言之间的同构关系已经建设起来，虽然没有全能的地球语翻译机，但各种语言之间大体已经能够互相翻译
人类在走过几千年的发展路程中，所见，所闻，所思，所说成淀下来的知识量日益庞大，不知道从何时起，知识量已经超过人脑的处理极限，一个人要想读完自己的国家的博物馆的所有书，估计也要穷其半生或者一生
人类的大脑在庞大的知识库面前开始感觉掌控无力，这是便开始研究大知识量下的掌控方法，这些方法无非也是在知识的量和深度方面做文章
在深度背后探索知识的规律，在量方面采用更有效的知识管理手段，例如牛顿三大定律使得宏观世界的运动得到统一，让人们抛弃纷乱复杂的运动现象，只需记住简单的但抽象的物理定律，这是知识深度的拓展，在知识管理的工具方面计算机技术的发展，使得人类在信息量的掌控方面得到极大的扩展
在知识管理的方法方面也发展出类理论，文献检索技术等其中类理论是我们所要关注的
类理论从现实中提取出具体事物的抽象描述(也就是俗称的概念)，以图的方式（主要是树）展现概念与概念之间的关系,为我们描绘世界认知的静态框架图
oo借鉴这种描述世界的方式，这些描述方式都是有数学基础支撑的，例如类的划标准是集合论里面的等价关系，泛化是一种偏序关系等等等
有人发表一篇论文叫&面向对象方法学理论基础&这本书讲的比我要好多，就不累述
uml与模式应用一书中忽悠我们在提炼类的概念的时候，其中有一种方法是借鉴事实
这也是有道理的
提出类的概念出来后，在构建一个类的体系的时候，有三种策略：自顶向下的演绎法自下向上的归纳法，还有两者兼有之的混合法，实际上如果和机器学习比较一下，你会发现这两者采用的策略竟是如此雷同
我们在用oo析与设计来描述我们的需求时，不过是在大脑中虚拟一种机器从另一个视角来重新认识我们的世界
上面的争论跑远，多接口确实比多继承清楚，LZ自己写个简单的控制台程序就明白至于哪种好，更符合实际-----sjjf兄写的太长，有没有中心句什么的放在段首，我看的头，就看一贴，相当有文采，能忽悠
（其实各人对世界的认知都是不同的，有毛线争的，我自认还没上升到那个理论高度，能很好的实现我就OK，也许再过个5年我能想想这问题）
单继承更容易理解，要不然哪里来这么multiplayer看#codego.net#
C#面向的使用者和应用层次不同无论那一种语言，都必须考虑到使用的环境和语境
额..这个和面象对象编程有关吧
&比如说人。只会有一个父亲一样。&但是他可能会有多个人的行为习惯抽象到程序里来就是单一继承和多接口实现。
单一继承更符合真实的世界。面向对象本身起源于实际生活
如果LS两位只是为这么一句话而争论的话，就显得太过于无聊
到底是多重继承还是单链继承更符合现实世界这本来就是一个没有意义，就像我们不是因为面向对象更符合我们真实的世界才选择面向对象的一样。说面向对象是从现实世界中抽象而成的理论我想在任何一个资深的OO程序员来说都知道这只不过是把OO变得玄之又玄的入门教材而已
OO能够抽象我们的程序，提高代码复用率，降低耦合度，使得程序可伸缩性更佳，这些是我们选择OO的原因，而不是因为我们把我们的家抽象成一个Object然后从日常生活中脑子一拍想出程序
==to&Ivony，我并不认为单一的继承更符合真实的世界，比如现在有的双性生物都是双继承的，甚至是多继承的，例如花授粉
菱形继承在古代甚至现代也是有，例如近亲结婚，当然并不是strict的封闭菱形，但可以找到菱形的
单一的继承也可以，不过并非优雅的设计
就像lambda算子中的多参数总可以curry化成单参数一样，两者是等价的，但是琐碎程度不一样
我在前面也提过，单继承+接口方式对上也能实现多继承函数，但是就像在饥饿的沙漠里面逮住一只蜥蜴一样，虽非美味，为填饱肚子求生存，也只能强咽下去
我用过java，也用过cpp，说实话，比拼coding，我也不一定输给某些人，这点我还是有自信的，比拼design，我也不惧大多数，因为我过，思考过，并找到理论依据
我有两年半的青春是花在java上面的，说实话，尽管java中接口满天飞，我对这种方式没有什么好感，(没用过c#，不知道它和java的方式有什么不一样)缺点我已经说，设计复用性相对较差（当然是拿优良的java设计和优良的cpp设计来说的）代替的缺点也很多，惟一可以带点说服力的是垃圾回收
但是一个良好的设计是可以稍微花费一点开销就能够取得内存自动管理，在开发效率和运行效率之间取得最高的比率
这方面具体的例子可以参考geant4，一个开源的空间物理计算引擎，里面用到很多cpp的oo设计技巧优雅，没事干的可以下来玩玩
so，我说单继承+接口更适合愚蠢的人用，这话并不过份
语言，思想，不过是我们描述世界的一种工具而已，不能简单地对面向对象是否真的合适描述我们的现实世界这样下一个对或者错的结论
刀剑有刀剑的用处，枪炮有枪炮的妙用，但任何工具都有合适使用的范围
这个使用范围就是我们的软件设计里面域
&关于面向对象，本公子今天比较无聊，顺便忽悠一番
在很久以前，有个家伙叫图灵，为证明可计算问题是真的可以的，造出一个叫图灵机的玩意儿（计算模型），同时还催生叫算法的玩意儿，这是计算理论里面的可计算性和计算复杂度的内容
(其实，同时代的还有邱奇的lambda算子，和一个忘名字的人提出的递归函数，)这些内容为表单演算奠定理论基础,使自动计算成为可能
后来，有个叫冯诺依曼的家伙，雇佣300名女工为atomicity弹的扩散影响范围计算几个月后，非常苦恼，偶遇一个军方人士后，在图灵机的模型上加上可存储单元（内存）捣鼓一个可以自动计算的机器。后来的演化成现在计算机
在最初的岁月里面，人们的工作重点是把自然语言里面表达的思想影射到机器可以识别的语言里面，以便可以驱使机器进行自动化的计算。繁琐的机器语言让人头脑胀，于是有人为便于内存使用些助记符号，于是产生一个叫汇编代替品
汇编语言提供的描述点是寄存器，移动址，压栈，入栈，算数运算，位运算，调用等描述点，提供的机制几乎是靠硬件实现的，如保护模式，段页式等
so，适合汇编域是关于机器操纵的
在这种细粒度的语言描述下，要来描述现实中的模型，差距太大，combinationsexplode使其就像用一堆cell来描述一个人体一样恐怖
so，基本上汇编只用来描述最关键性的东西，从现实中提出去需要的计算，转换成机器操作是机器语言程序员工作
在经过大量的使用后，人们发现在描述任务的步骤地时候，出现一些稳定的特征，例如有条件跳转的几种固定模式，循环的几种用法，局部变量，代码块(函数)，这些特征经过适当的封装，形成新的描述点，同时涌现出顺序，支，循环，递归等线程机制，于是便出现过程化语言，它将任务的描述从机器层面解脱出来，扩大到面向过程式任务步骤层面，这时候类似描述一个人体就用躯干四肢和头来表达，描述的粒度开始变大，直接影响可描述任务的复杂度和规模。于是导致c璀璨近40年，并在系统编程领域称霸，描述任务，它再合适不过
从现实模型中提取出需要的任务描述，是过程化语言程序员工作
当问题域涉及描述一个系统的时候，过程式的语言就显得力不从心，就像描述一个公司系统内部的聚餐的时候，用一堆堆躯干四肢和头和嘴如何移动来表现一样，虽然在有限的范围内，它也可能描述的清楚，当容易转移人们的focus，人们更关注的是系统的组，系统的状态，系统的交互行为，系统的协作程度，而不是某一部是如何移动的
这迫使新的语言要提供一个更大的描述点，能够更贴近我们的生活模型，我们的生活抽象出来的模型，是由一些系列的概念，以及概念的交互构成的
因此oo应运而生，虽然很multiplayer理解这个语言中类的概念是数据+函数，但是忽略有机构成几个字，不知道其中某些东西已经发生质的变化，就像木偶也是有四肢+躯干+头构成，但是却无法拥有生命，oo，正是那个像木偶吹口仙气的上帝，以封装，继承，多态等机制赋予类一个活的概念
恩，先到此为止，有事外出，下次再忽悠
专有名词扯再多看不破本质都是纸上谈兵...如果你不能理解儿子是一个属性而父亲教师老公情人等应该是接口我并不...==有点无语，也许你要真正做到设计师才能理解我要表达的意思
至少要真正的用过一次oo思想来析和做后你才能理解
我举的面向对象析与设计一书中的桌子和组成部的关系的例子就是想告诉你问题域的重要性，可惜你没有去翻过
如果你不能对问题域,角色这样的名字敏感，那也说明你还不是设计师，至少，还达不到设计师的层面
算，多说无益，你还以为我在侮辱你的iq
to&Ivony:只是他一个人在为那句话争论而已...现实世界的复杂性不是现有的计算机技术可以描述的...所以我们才尽量的简单化来抽象...to&sjjf:都说不想再讨论...所以只回答你的疑问...优先点：在我域中，所谓的角色依靠职能而存在，一个叫人的对象所拥有的各种职能在我们需要用到这个概念的时候，在他出现的场合就已经拥有这些职能，而不是一会儿加一个职能，转化成某个状态后再动态加一个职能，在软件里难做到这样一点-------------专有名词扯再多看不破本质都是纸上谈兵...如果你不能理解儿子是一个属性而父亲教师老公情人等应该是接口我并不...疑问1：&是我引用错，还是书本错，如果错，错在哪儿？疑问2：&你觉得那些地方那些地方不能相信？为什么？如果采用你的所谓的无书？那如何证明我的决定是对的？疑问3：&"另外书也是人写出来的..."你是想告诉我书不尽正确，还是想告诉我那些书没啥大不的？还是想告诉我其他的别的什么？-------------基本上我不知道你的疑问都是怎么总结出来的...我从头至尾没有说你引用错也没有说书本错更没有说谁的不能相信...只是想告诉你知识不是简单堆积消化理解才是自己的...前人的经验不但是总结更是破除更前人的经验得来的...如果你不能理解尽信书不如无书这句话那更没什么可说的...
另外从OO的角度看...儿子仅仅是男性属性决定的一个属性...与父亲教师老公情人等等有本质的区别...这个例子不怎么恰当一个人&的继承至少两重&基因来自父亲和母亲&当然一定要说是从母亲那里来的单重继承&父亲只是接口&……&nbsp
单一继承更符合真实的世界。面向对象本身起源于实际生活
如果LS两位只是为这么一句话而争论的话，就显得太过于无聊
到底是多重继承还是单链继承更符合现实世界这本来就是一个没有意义，就像我们不是因为面向对象更符合我们真实的世界才选择面向对象的一样。说面向对象是从现实世界中抽象而成的理论我想在任何一个资深的OO程序员来说都知道这只不过是把OO变得玄之又玄的入门教材而已
OO能够抽象我们的程序，提高代码复用率，降低耦合度，使得程序可伸缩性更佳，这些是我们选择OO的原因，而不是因为我们把我们的家抽象成一个Object然后从日常生活中脑子一拍想出程序。
不说谁更接近现实&多重继承无非就是想一个类同时具备多个父类的函数弄成儿子孙子&祖宗十八代也行一次就继承多个父类确实比较方便改多重继承为接口一方面为降低编程难度&有利于垃圾回收
多继承更接近现实世界&单继承容易实现而且不容易出错如果一定要多继承的话&能不能这样虽然不能直接class&A{}class&B{}class&C:A,B但是可以class&A{}class&B:A{}class&C:B{}就是把多重继承弄成多层继承
bs在cpp设计与演化中就谈到smalltalk放弃多重继承就是因为其给垃圾回收带来的复杂程度
二义性根本就不是问题问题在于菱形继承的字段共享，这C++用virtual继承解决，但仍然很难受
还有就是单根继承，C#所有类型都是从object继承而来，这样的单根继承在很多方面有好处，例如垃圾回收……
.你的例子理解错误...11楼是对的...现实世界是单一继承...多继承的特例也有...例如骡狮虎兽...那是人类违背自然规律人为制造的...可以称之为怪物...二义性已经够混乱...但更糟糕的却是菱形继承结构...就是20楼hdt的例子...接口不是唯一方案但到目前为止是解决此问题的最好方案...一个人就是人...除儿子...父亲教师老公情人等等多种角色并不是娘胎里带来的...而是其实现相应的接口...每个男人都是儿子...但不是每个男人都有其他角色...你对OO的理解还不够...世界从来不是单一的继承，如果是这样，那么这世界就不会像现在那么精彩，在自然界如此，在社会上也如此
自然界的例子：你有你父亲和你母亲的某些特征
如果是单根继承，我很难想象你是怎么样从一个母体继承下来，然后再实现谁的接口...物种不是原样拷贝下来之后，再按照某个接口进行transform实现的，而是同时兼有两个父类的特征然后成长的，如果单根继承+接口无法解释，那么就可以认为这个理论模型解释现实是乏力的
你所谓的骡子，狮虎兽的怪物存在，不是人违背自然规律，没有人工的协助下也是可能发生的，你不能保证一头驴不会对马发情，一头狮子不会对母老虎产生性冲动，从而作不该做的事情，然后居然还有结果，金刚都可以为美女在摩天大厦打飞机，还有什么不可能的呢？再uml参考手册是是怎么评价多重继承的吧4.5.3&单类和多重类在最简单的表单中，一个对象仅属于一个类，许多面向对象的语言有这种限制。一个对象仅属于一个类并没有逻辑上的必要性，我们只要从多个角度同时观察一下真实世界的对象就可以发现这一点。在UML更概括的表单中，一个对象可以有一个或多个类。对象看起来就好像它属于一个隐式类，而这个类是每个直接父类的子类&—多重继承可以免去再声明一个新类，这可提高效率
关于一个人多种身份的那个例子
我想，你并没有看过业界那本经典的《面向对象设计与析》，这是里面关于多重继承存在重要性的一个精辟的例子
况且关于------------------------儿子...父亲教师老公情人等等多种角色并不是娘胎里带来的------------------------我不知道你知道"概念"，"抽象概念"，"概念体系"这三个东西不
然后他们怎么样映射到类的设计的
如果不知道，读读我推荐的那本书吧
况且，在我们现实中的概念，在我们不同域中充当的角色有可能是不一样的,里面举桌子以及组成部的关系为例
------------------------另外从OO的角度看...儿子仅仅是男性属性决定的一个属性...与父亲教师老公情人等等有本质的区别...------------------------我不知道儿子和父亲有何本质的区别，告诉我本质性的区别
接口，不过是一个对对象的view而已，在程序析和设计阶段可以允许我们遵照契约来调用,解除上层设计和下层设计的互相依赖的constraints，让两者能够并行开发，是一种更细致的工机制的体现
因而在水岭产生一个叫接口的概念，用以描述与实现无关的动作和行为，这是接口的广义定义，这个概念在很早以前就出现，c头文件里面包含的东西都是接口，后来出现oo，需要描述一些多态这种特征，cpp的接口的概念的支撑才包含抽象类，其他采用单一继承的oo语言，没有办法实现多重继承只好采用接口这个关键字，这可能是属于最初设计的缺陷，不得已引入叫interface这个混淆视听的畸形的东西作为代替方案，而不是最好的，也可能是在开发的复杂度和设计的理性之间的一种折中方案
在商业的鼓吹下居然也红起来
使用的门槛倒是很低的，但是和多重继承是两码事
继承最初的目的是为复用，多重继承也是，可是java的单根+接口方式并没有达到这个效果
转而在单继承+接口的机制下以聚集的方式可以称之为委托的方式来实现复用，采用这样的方式会带来很多的缺点，比如combinationsexplode，比如沟通障碍迫使你会为被委托类类中打开一个回调的窗口，如果不这样将迫使你为协调这两者的沟通问题重新编码，而且菱形问题下放给程序员去手工指定实现，这样会更糟，而且它是对抽象的一种破坏.如果你写过这样的程序就知道累
单根继承+接口的方式下的继承类对上层使用勉强达到复用接口的要但是对下层的实现的糟糕的很，但适用抽象能力很差的人
如果你对此有异议，可以举个例子出来告诉我java或者采用单根继承+接口的语言是怎么实现复用的
如何避免我提到的这些缺点
关于多重继承的二义性，是在编译期就可以检查出来的，也有，不能算是一个缺陷，只不过是复杂一点（主要集中在编译器的实现上，而不是设计和使用上），不过现实就是这么复杂的，他只是忠实的描述现实而已。
人设计的东西并不是全要讲什么道理就象键盘的布局，也是约定俗成的C#语法就是这样规定，编译器也这样识别无论道理讲不讲都得按语法写代码不是？这得问Anders&Hejlsberg，我就不瞎猜
我也赞同一下吧。存在即道理，我们可以清清楚楚的说出什么好处和坏处，但取舍时却会根据不同情况来干。再说接口和类在某种使用上真的是很接近
就像我接触语言时就都说goto是邪恶的。为什么，我不知道，因为我从来没用过。
人设计的东西并不是全要讲什么道理就象键盘的布局，也是约定俗成的C#语法就是这样规定，编译器也这样识别无论道理讲不讲都得按语法写代码不是？这得问Anders&Hejlsberg，我就不瞎猜。
.你的例子理解错误...11楼是对的...现实世界是单一继承...多继承的特例也有...例如骡狮虎兽...那是人类违背自然规律人为制造的...可以称之为怪物...二义性已经够混乱...但更糟糕的却是菱形继承结构...就是20楼hdt的例子...接口不是唯一方案但到目前为止是解决此问题的最好方案...一个人就是人...除儿子...父亲教师老公情人等等多种角色并不是娘胎里带来的...而是其实现相应的接口...每个男人都是儿子...但不是每个男人都有其他角色...你对OO的理解还不够...世界从来不是单一的继承，如果是这样，那么这世界就不会像现在那么精彩，在自然界如此，在社会上也如此
自然界的例子：你有你父亲和你母亲的某些特征
如果是单根继承，我很难想象你是怎么样从一个母体继承下来，然后再实现谁的接口...物种不是原样拷贝下来之后，再按照某个接口进行transform实现的，而是同时兼有两个父类的特征然后成长的，如果单根继承+接口无法解释，那么就可以认为这个理论模型解释现实是乏力的
你所谓的骡子，狮虎兽的怪物存在，不是人违背自然规律，没有人工的协助下也是可能发生的，你不能保证一头驴不会对马发情，一头狮子不会对母老虎产生性冲动，从而作不该做的事情，然后居然还有结果，金刚都可以为美女在摩天大厦打飞机，还有什么不可能的呢？再uml参考手册是是怎么评价多重继承的吧4.5.3&单类和多重类在最简单的表单中，一个对象仅属于一个类，许多面向对象的语言有这种限制。一个对象仅属于一个类并没有逻辑上的必要性，我们只要从多个角度同时观察一下真实世界的对象就可以发现这一点。在UML更概括的表单中，一个对象可以有一个或多个类。对象看起来就好像它属于一个隐式类，而这个类是每个直接父类的子类—多重继承可以免去再声明一个新类，这可提高效率
关于一个人多种身份的那个例子
我想，你并没有看过业界那本经典的《面向对象设计与析》，这是里面关于多重继承存在重要性的一个精辟的例子
况且关于------------------------儿子...父亲教师老公情人等等多种角色并不是娘胎里带来的------------------------我不知道你知道"概念"，"抽象概念"，"概念体系"这三个东西不
然后他们怎么样映射到类的设计的
如果不知道，读读我推荐的那本书吧
况且，在我们现实中的概念，在我们不同域中充当的角色有可能是不一样的,里面举桌子以及组成部的关系为例
------------------------另外从OO的角度看...儿子仅仅是男性属性决定的一个属性...与父亲教师老公情人等等有本质的区别...------------------------我不知道儿子和父亲有何本质的区别，告诉我本质性的区别
接口，不过是一个对对象的view而已，在程序析和设计阶段可以允许我们遵照契约来调用,解除上层设计和下层设计的互相依赖的constraints，让两者能够并行开发，是一种更细致的工机制的体现
因而在水岭产生一个叫接口的概念，用以描述与实现无关的动作和行为，这是接口的广义定义，这个概念在很早以前就出现，c头文件里面包含的东西都是接口，后来出现oo，需要描述一些多态这种特征，cpp的接口的概念的支撑才包含抽象类，其他采用单一继承的oo语言，没有办法实现多重继承只好采用接口这个关键字，这可能是属于最初设计的缺陷，不得已引入叫interface这个混淆视听的畸形的东西作为代替方案，而不是最好的，也可能是在开发的复杂度和设计的理性之间的一种折中方案
在商业的鼓吹下居然也红起来
使用的门槛倒是很低的，但是和多重继承是两码事
继承最初的目的是为复用，多重继承也是，可是java的单根+接口方式并没有达到这个效果
转而在单继承+接口的机制下以聚集的方式可以称之为委托的方式来实现复用，采用这样的方式会带来很多的缺点，比如combinationsexplode，比如沟通障碍迫使你会为被委托类类中打开一个回调的窗口，如果不这样将迫使你为协调这两者的沟通问题重新编码，而且菱形问题下放给程序员去手工指定实现，这样会更糟，而且它是对抽象的一种破坏.如果你写过这样的程序就知道累
单根继承+接口的方式下的继承类对上层使用勉强达到复用接口的要但是对下层的实现的糟糕的很，但适用抽象能力很差的人
如果你对此有异议，可以举个例子出来告诉我java或者采用单根继承+接口的语言是怎么实现复用的
如何避免我提到的这些缺点
关于多重继承的二义性，是在编译期就可以检查出来的，也有，不能算是一个缺陷，只不过是复杂一点（主要集中在编译器的实现上，而不是设计和使用上），不过现实就是这么复杂的，他只是忠实的描述现实而已。
逻辑清晰class&自动class&jeep&nbsp：自动class&夏历&nbsp：自动jeep&是&自动夏历&是&自动三蹦子&不是&自动
另外从OO的角度看...儿子仅仅是男性属性决定的一个属性...与父亲教师老公情人等等有本质的区别...
是为用户考虑的，因为现在编程的门槛太低，愚蠢的人太多，没有办法多继承是最贴近现实的描述的，也是最省力的。比如现实中一个人可能有父亲师，儿子，老公，情人等等多种角色，多继承能够恰如其的描述这样一点采用接口的方式，每一个指定的东西都要不厌其烦得再实现一次，累不累？虽然采用多继承会导致混乱，但是这取决于现实中的模型的复杂程度和模型的建构者的功力你的例子理解错误...11楼是对的...现实世界是单一继承...多继承的特例也有...例如骡狮虎兽...那是人类违背自然规律人为制造的...可以称之为怪物...二义性已经够混乱...但更糟糕的却是菱形继承结构...就是20楼hdt的例子...接口不是唯一方案但到目前为止是解决此问题的最好方案...一个人就是人...除儿子...父亲教师老公情人等等多种角色并不是娘胎里带来的...而是其实现相应的接口...每个男人都是儿子...但不是每个男人都有其他角色...你对OO的理解还不够...
是为用户考虑的，因为现在编程的门槛太低，愚蠢的人太多，没有办法
多继承是最贴近现实的描述的，也是最省力的。比如现实中一个人可能有父亲师，儿子，老公，情人等等多种角色，多继承能够恰如其的描述这样一点
采用接口的方式，每一个指定的东西都要不厌其烦得再实现一次，累不累？虽然采用多继承会导致混乱，但是这取决于现实中的模型的复杂程度和模型的建构者的功力
二义性的责任在程序员而不再语言本身.C#的定位是简单快速开发.所以去除一切不必要的麻烦.当初甚至想把指针都去掉.不过这样又和VB有何区别呢?对,最大的区别就是有.Net&Framework.其实世界上99%的程序员于其说选择语言归根到底其实是选择类库或API库.(有些跑题)
接口就是当初MICROSFOT提出来代替多重继承的主要就是为函数更加明确，接口实现的是一种契约，即要实现哪个函数继承自接口的类必须实现这个函数并且这个二义性会得到解决，它并没有提供实现代码，所以具体实现哪个是无所谓的（个人想法）但是如果想具体到接口就得加上接口名
pubilc&class&a{public&virtual&void&test();}public&class&b:a{public&overrider&void&test(){}}public&class&c:a{public&overrider&void&test(){}}public&class&d:b,c{}a&temp&=&new&c();temp.test()&//??
多继承较之多接口更难合理的应用，这个是为什么除C++和Effel提供这个东西，其他的OOP语言都不提供多继承
个人感觉是简单的多继承很容易控制，不会犯错，但是复杂的情况下面多继承很难控制，容易出错——很多时候都不知道类型怎么设计才合理。相比之下多接口的设计更容易理解。
每个语言都有自己的特点，C++中需要多实现继承的地方，C#中可能通过改变一下设计也可以达到相同的目的。C++中的多继承有好处也有坏处，灵活代码紧凑，但难写也难懂，一个选择。或许是考虑降低C#编程的门槛，许就是当时制定语言规范的那个小组坐在session室里一投票，ok就这么着……
单一继承更符合真实的世界。面向对象本身起源于实际生活。
总结来讲就是更加接近JAVA，当初MS推出C#对手就是JAVA。java和C#都是单继承多接口。多继承容易出错是程序员实践中总结来的
其实接口可以说并不存在的二义性问题
Interface&a{int&test();}Interface&b{int&test();}class&c:a,b{//overrider&test();}c&c1&=...c1.test()因为接口的函数没有函数体，&a.test()&或&b.test()&无所谓
但是类就不一样，因为它可以定义函数体
abstract&class&a{public&abstract&int&test(){consoli.write('a');}}abstract&class&b{public&abstract&int&test(){consoli.write('b');}}class&c:a,b{//overrider&test();}c&c1&=...c1.test()&//&nbsp
其实接口可以说并不存在的二义性问题
Interface&a{int&test();}Interface&b{int&test();}class&c:a,b{//overrider&test();}c&c1&=...c1.test()因为接口的函数没有函数体，&a.test()&或&b.test()&无所谓
但是类就不一样，因为它可以定义函数体
abstract&class&a{public&abstract&int&test(){consoli.write('a');}}abstract&class&b{public&abstract&int&test(){consoli.write('b');}}class&c:a,b{//overrider&test();}c&c1&=...c1.test()&//&nbsp
其实接口可以说并不存在的二义性问题
Interface&a{int&test();}Interface&b{int&test();}class&c:a,b{//overrider&test();}c&c1&=...c1.test()因为接口的函数没有函数体，&a.test()&或&b.test()&无所谓
但是类就不一样，因为它可以定义函数体
abstract&class&a{public&abstract&int&test(){consoli.write('a');}}abstract&class&b{public&abstract&int&test(){consoli.write('b');}}class&c:a,b{//overrider&test();}c&c1&=...c1.test()&//&nbsp
多重继承太混乱，所以要用单继承，这是C#的优点，多接口只是定义一些规范，这个比较深奥，不是一两句能说清楚的，设计模式
就是，像c++这种传统的OO语言，都没能很好控制多继承，所以java，c#都已经舍弃多继承，改用更加窄的接口
二义性exclass&a{public&virtual&int&test();}class&b{public&virtual&int&test();}class&c:a,b{//overrider&test();}c&c1&=...c1.test()&//
本文标题 ：为什么C#舍弃C++中的多继承而支持单一继承与多接口继承呢？
本文地址 ：CodeGo.net/1306304/
Copyright (C) 2017 CodeGo.net