http://bbs.zhenghui.org/tags/inheritance 冒号论坛 » Tag: inheritance - Recent Posts en-US Wed, 08 Feb 2012 23:30:52 +0000 http://bbpress.org/?v=1.0.2 q http://bbs.zhenghui.org/search.php http://bbs.zhenghui.org/topic/%e5%85%b3%e4%ba%8e%e7%bb%a7%e6%89%bf#post-318 Tue, 31 May 2011 19:13:59 +0000 Lumj 318@http://bbs.zhenghui.org/ <p>"如果父类有protected域成员却无相应的规范文档，这种父类不要也罢"<br /> 哈哈<br /> 我觉得其实父类直接向子类暴露数据(protected),和一个类直接向外部暴露它的数据(public),定性地来看,是一样的,只是前者从名义上来说更容易套近乎——"hi,我也是写类供外面使用的"——从而对它的松懈觉得情有可原罢了,而实际上它对父类的颠覆能力一点也不差.. </p> http://bbs.zhenghui.org/topic/%e5%85%b3%e4%ba%8e%e7%bb%a7%e6%89%bf#post-317 Tue, 10 May 2011 18:41:37 +0000 hui 317@http://bbs.zhenghui.org/ <p>现实中子类采用父类protected域成员的情形的确有不少，但这种设计一般是不提倡的。这是因为相比方法成员，域成员的可变性更大，包括名称、用法、访问控制等等，并且也不像前者那样可以被overriden。此外，其用法的粒度也大于前者的粒度。总之，后者的抽象性和规范性均不如前者。这也是为什么接口都以方法成员而非域成员的形式出现的原因。<br /> 话说回来，一旦父类已经采用了protected域成员，也不是绝对不能在子类中引用的。但要注意两点：一、如果不通过域成员也能达到目的的，则尽量不用，除非涉及到严重的性能问题；二、如果不得不用，一定要弄清域成员的详细规范并严格遵循之。（如果父类有protected域成员却无相应的规范文档，这种父类不要也罢） </p> http://bbs.zhenghui.org/topic/%e5%85%b3%e4%ba%8e%e7%bb%a7%e6%89%bf#post-316 Tue, 10 May 2011 18:22:31 +0000 folger 316@http://bbs.zhenghui.org/ <p>有个小问题,请老师指教.</p> <p>在第九章讲继承时,您有这么一个观点,父类应该尽可能禁用protected域成员.我想知道什么情况下可以违背这一原则.因为现实中这种情况似乎非常普遍:父类中含有需要和子类共享而又不便为外界所知的数据,这时候难道不是将其设为protected更为合适吗? </p> http://bbs.zhenghui.org/topic/%e5%ae%9e%e7%8e%b0%e7%bb%a7%e6%89%bf%e9%97%ae%e9%a2%98%e7%9a%84%e7%bb%8f%e5%85%b8%e5%ae%9e%e4%be%8b#post-285 Mon, 10 Jan 2011 23:48:01 +0000 Lumj 285@http://bbs.zhenghui.org/ <p>嗯.. </p> http://bbs.zhenghui.org/topic/%e5%ae%9e%e7%8e%b0%e7%bb%a7%e6%89%bf%e9%97%ae%e9%a2%98%e7%9a%84%e7%bb%8f%e5%85%b8%e5%ae%9e%e4%be%8b#post-283 Mon, 10 Jan 2011 23:26:17 +0000 hui 283@http://bbs.zhenghui.org/ <p>以上提到了实现继承的三种常见pitfall：继承（或实现）一个父类方法时可能会影响另外的超类方法；实现某些接口时可能对非public方法有特殊要求；子类在覆盖父类方法时可能需要调用某些特别的方法（最常见的是父类的被覆盖方法）。此外还有其他可能，比如《冒号课堂》p269提到的某些方法的实现细节不得不出现在规范文档中，容易被人忽略；再比如，有些子类并未实现某接口的全部方法，如有些Java类的方法只是简单地throw UnsupportedOperationException（严格说来这是不满足里氏代换原则的）。 </p> http://bbs.zhenghui.org/topic/%e5%ae%9e%e7%8e%b0%e7%bb%a7%e6%89%bf%e9%97%ae%e9%a2%98%e7%9a%84%e7%bb%8f%e5%85%b8%e5%ae%9e%e4%be%8b#post-281 Mon, 10 Jan 2011 22:58:49 +0000 Lumj 281@http://bbs.zhenghui.org/ <p>最近在使用js独自开发一个HTML UI库的时候,才开始有感于实现继承对于子类提出的潜要求的普遍存在性<br /> 工程规模还不十分大,所见到的最常见的"潜要求"就是,子类实现某方法时必须在开头或结尾调用基类的某方法<br /> 两位提到的情形我能想象,只是没见过,不知在现实中我上面所说的这类潜要求和两位提到的潜要求是否占了这类潜要求的一大块份额? </p> http://bbs.zhenghui.org/topic/%e5%ae%9e%e7%8e%b0%e7%bb%a7%e6%89%bf%e9%97%ae%e9%a2%98%e7%9a%84%e7%bb%8f%e5%85%b8%e5%ae%9e%e4%be%8b#post-275 Mon, 03 Jan 2011 20:02:27 +0000 hui 275@http://bbs.zhenghui.org/ <p>是的。大部分类的接口规范是独立的，但也有一些接口是互相关联的，你提到的equals与hashCode就是一例。此外，有些接口的实现不仅对public方法有要求，还可能对private方法有要求。比如Java中一个类如果是Serializable类型，并且希望定制序列化过程，则需要实现私有的writeObject和readObject方法。 </p> http://bbs.zhenghui.org/topic/%e5%ae%9e%e7%8e%b0%e7%bb%a7%e6%89%bf%e9%97%ae%e9%a2%98%e7%9a%84%e7%bb%8f%e5%85%b8%e5%ae%9e%e4%be%8b#post-274 Mon, 03 Jan 2011 16:46:05 +0000 Todd 274@http://bbs.zhenghui.org/ <p>"You must override hashCode() in every class that overrides equals(). Failure to do so will result in a violation of the general contract for Object.hashCode(), which will prevent your class from functioning properly in conjunction with all hash-based collections, including HashMap, HashSet, and Hashtable."<br /> -- from Effective Java, by Joshua Bloch</p> <p>《冒号课堂》中提到了实现继承的诸多问题，必须引起重视，解决的方法其中之一便是将这类实现相关的“潜规则”明确写入文档。我觉得最经典的实例就是Java中覆盖equals()方法必须同时覆盖hashCode()的问题。 </p> http://bbs.zhenghui.org/topic/subtype%e5%92%8csubclass#post-138 Thu, 24 Jun 2010 11:22:07 +0000 hui 138@http://bbs.zhenghui.org/ <p>是的，CiteSeerx有大量高质量的学术文章。 </p> http://bbs.zhenghui.org/topic/subtype%e5%92%8csubclass#post-137 Thu, 24 Jun 2010 10:51:55 +0000 Todd 137@http://bbs.zhenghui.org/ <p>CiteSeer是个好地方！ </p> http://bbs.zhenghui.org/topic/subtype%e5%92%8csubclass#post-132 Mon, 14 Jun 2010 17:40:53 +0000 Todd 132@http://bbs.zhenghui.org/ <p>是的，和《冒号课堂》的观点基本一致。区分了subtype和subclass就能把继承和多态的关系理清楚了。同时，对于以前不太容易区分的interface与abstract class的选择问题也会更清楚。使用interface是为了subtype，使用abstract class则包含了subtype和subclass。记得书中比喻abstract class是半成品。 </p> http://bbs.zhenghui.org/topic/subtype%e5%92%8csubclass#post-131 Mon, 14 Jun 2010 00:36:52 +0000 hui 131@http://bbs.zhenghui.org/ <p>非常好的文章，多谢分享。其中谈到subclass与subtype的区别时是这样说的：Subclasses allow one to reuse the code inside classes - both instance variable declarations and method definitions. Thus they are useful in supporting code reuse inside a class. Subtyping on the other hand is useful in supporting reuse externally, giving rise to a form of polymorphism。即：子类用于类的内部重用，子类型用于外部重用。这个与《冒号课堂》中提到的观点本质上是一致的：实现继承消费可重用的旧代码，接口继承生产可重用的新代码；接口继承不是为了代码重用，而是为了代码被重用。</p> <p>另：该文章的PDF版可到 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.9.7539&amp;rep=rep1&amp;type=pdf 下载。 </p> http://bbs.zhenghui.org/topic/subtype%e5%92%8csubclass#post-130 Mon, 14 Jun 2010 00:13:36 +0000 Todd 130@http://bbs.zhenghui.org/ <p>虽然subtype和subclass是OOP中最基本的问题之一，但我是在读《冒号课堂》的时候才开始注意到这个问题。我想国内的程序员不能区分subtype和subclass的不在少数。下面这个资料对于subtype和subclass讨论得比较深入，贴上来分享：</p> <p>http://www.cs.princeton.edu/courses/archive/fall98/cs441/mainus/mainus.html </p> http://bbs.zhenghui.org/topic/%e5%8f%a6%e7%b1%bb%e7%bb%a7%e6%89%bf#post-107 Wed, 05 May 2010 10:22:57 +0000 Todd 107@http://bbs.zhenghui.org/ <p>看到一篇相关文章：<br /> http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Non-copyable_Mixin </p> http://bbs.zhenghui.org/topic/%e5%8f%a6%e7%b1%bb%e7%bb%a7%e6%89%bf#post-63 Sun, 21 Feb 2010 23:47:15 +0000 hui 63@http://bbs.zhenghui.org/ <p>&gt;&gt;noncopyable不是接口，但却达到了接口类似的特征表达效果，与C#中可序列化类的标记[Serializable]有异曲同工之妙。</p> <p>是的，书中p307提到的标记接口和属性导向式编程（@OP）正适合那些无法用接口直接表征的类型特性。这在Java和C#中比较常见，而在C++中除noncopyable这种特殊用法外并不多见，一个明显的原因是前二者对metadata有更强大的支持。</p> <p>&gt;&gt;接口是有主客关系的，类的这种行为"特征"不一定需要客户的存在。不知道这种表达“特征”而不涉及客户接口的方式就是mixin或者traits是否有关联？ </p> <p>这话恐怕不太准确。如果没有客户的存在，也就谈不上是否copyable了。而无论是mixin还是trait，都提供了一系列接口集合，它们与通常的抽象类型中interface的一个主要区别是除接口外还提供了实现；与abstract class的一个主要区别是摆脱了class hierarchy的桎梏。 </p> http://bbs.zhenghui.org/topic/%e5%8f%a6%e7%b1%bb%e7%bb%a7%e6%89%bf#post-62 Sun, 21 Feb 2010 23:18:44 +0000 hui 62@http://bbs.zhenghui.org/ <p>&gt;&gt;noncopyable的原理从继承的角度看是通过基类对派生类产生约束而实现不可拷贝的效果的。我把这种方式称为“继承约束”，它与实现继承的“继承功能”和mixin的“混入功能”就显得有些不同。一个注重约束，一个注重功能。 </p> <p>你的这种说法有一定道理，但仅限于noncopyable这类特殊用法，其他的非公开继承（书中p241中提到的protected inheritance与private inheritance）还是注重功能而非约束的。当然，如果把约束看作一种特殊的功能（不妨称之为“负功能”？），它们又可以统一了。</p> <p>此外，书中提到noncopyable类似mixin的地方有一个关键处，即noncopyable类本身具有抽象性（因为一个单纯的noncopyable对象是毫无意义的——无论是语法上还是语义上），故可看作抽象类型（尽管不是严格语法意义上的抽象类型）。 </p> http://bbs.zhenghui.org/topic/%e5%8f%a6%e7%b1%bb%e7%bb%a7%e6%89%bf#post-61 Sun, 21 Feb 2010 21:30:30 +0000 Todd 61@http://bbs.zhenghui.org/ <p>noncopyable例子还有一个有趣的地方。一般来讲，一个类的功能特征是通过接口抽象（还包括数据抽象）来体现，但“不可拷贝”是无法对应到一个接口的！noncopyable不是接口，但却达到了接口类似的特征表达效果，与C#中可序列化类的标记[Serializable]有异曲同工之妙。</p> <p>我思考以后认为：接口是有主客关系的，类的这种行为"特征"不一定需要客户的存在。不知道这种表达“特征”而不涉及客户接口的方式就是mixin或者traits是否有关联？ </p> http://bbs.zhenghui.org/topic/%e5%8f%a6%e7%b1%bb%e7%bb%a7%e6%89%bf#post-60 Sun, 21 Feb 2010 21:06:19 +0000 Todd 60@http://bbs.zhenghui.org/ <p>书中的确讲到了，看的时候这部分没有留下很深的印象。</p> <p>p297讲“本质上看是一种类似mixin功能的抽象类型”。我认为这是一种另类继承的原因在于：noncopyable的原理从继承的角度看是通过基类对派生类产生约束而实现不可拷贝的效果的。我把这种方式称为“继承约束”，它与实现继承的“继承功能”和mixin的“混入功能”就显得有些不同。一个注重约束，一个注重功能。 </p> http://bbs.zhenghui.org/topic/%e5%8f%a6%e7%b1%bb%e7%bb%a7%e6%89%bf#post-53 Sat, 20 Feb 2010 21:59:47 +0000 hui 53@http://bbs.zhenghui.org/ <p>你说的这种继承和boost::nocopyable书中分别在p241和p297中已经介绍过了，它们属于仅继承实现而不继承接口的继承。C++支持这种用法，但Java和C#不支持。 </p> http://bbs.zhenghui.org/topic/%e5%8f%a6%e7%b1%bb%e7%bb%a7%e6%89%bf#post-52 Sat, 20 Feb 2010 21:31:36 +0000 Todd 52@http://bbs.zhenghui.org/ <p>书中继承机制部分介绍了实现继承和接口继承，但感觉还有另一种继承的用法可以说的。比如boost::nocopyable就是利用了C++基类的私有拷贝构造函数防止派生类的拷贝构造。我觉得这类用法既不属于实现继承也不属于接口继承，只是利用了继承配合特定的语言特性达到目的。</p> <p>这也许已经不属于OOP理论范畴，而是与具体语言相关的一些技巧，所以我将这类用法归为实现继承、接口继承之外也另类继承。 </p>