Comments on: Implementation Exposure Through Inheritance http://enfranchisedmind.com/blog/posts/implementation-exposure-through-inheritance/ programming, politics, & other religious issues Sat, 13 Mar 2010 19:36:10 +0000 hourly 1 By: Enfranchised Mind http://enfranchisedmind.com/blog/posts/implementation-exposure-through-inheritance/#comment-31654 Enfranchised Mind Mon, 10 Sep 2007 00:25:58 +0000 http://enfranchisedmind.com/blog/archive/2007/02/17/193#comment-31654 <strong>Use vr.s Reuse, or The Second Derivitive of Programming...</strong> I think I’ve come to the conclusion that anything Raganwald writes is required reading. Even when I don’t agree with what he’s writing. As it is with this post on abstraction vr.s abbreviation in programming. Well, disagree with is... Use vr.s Reuse, or The Second Derivitive of Programming…

I think I’ve come to the conclusion that anything Raganwald writes is required reading. Even when I don’t agree with what he’s writing. As it is with this post on abstraction vr.s abbreviation in programming. Well, disagree with is…

]]> By: Enfranchised Mind http://enfranchisedmind.com/blog/posts/implementation-exposure-through-inheritance/#comment-31567 Enfranchised Mind Mon, 13 Aug 2007 18:10:27 +0000 http://enfranchisedmind.com/blog/archive/2007/02/17/193#comment-31567 <strong>Another Person Bit by Java Exposing the Implementation through Inheritance...</strong> Brian Pontarelli encounters the same ugliness in the Java API that I talked about back in Implementation Exposure Through Inheritance. It’s a good read, and goes into more detail than I did about the most glaring and chafing example: Java’s... Another Person Bit by Java Exposing the Implementation through Inheritance…

Brian Pontarelli encounters the same ugliness in the Java API that I talked about back in Implementation Exposure Through Inheritance.
It’s a good read, and goes into more detail than I did about the most glaring and chafing example: Java’s…

]]> By: Sandro Magi http://enfranchisedmind.com/blog/posts/implementation-exposure-through-inheritance/#comment-31117 Sandro Magi Thu, 21 Jun 2007 00:56:46 +0000 http://enfranchisedmind.com/blog/archive/2007/02/17/193#comment-31117 This happens simply because these OO languages do not sufficiently distinguish interface from implementation. You may wish to implement the Hashtable interface, but that you inherit the implementation of Hashtable (ie. reuse it) is an implementation detail of Properties, and should not be exposed to client code. Unfortunately, it is since the subtyping relationship of Properties is clearly visible. For this reason, and others, I strongly object to Java/C#-style inheritance on general principle, and believe future languages should enforce interfaces only; code reuse should occur via alternate mechanisms which are not exposed to clients, such as traits in Scala, or forwarding as in systems with first-class messages. This happens simply because these OO languages do not sufficiently distinguish interface from implementation. You may wish to implement the Hashtable interface, but that you inherit the implementation of Hashtable (ie. reuse it) is an implementation detail of Properties, and should not be exposed to client code. Unfortunately, it is since the subtyping relationship of Properties is clearly visible.

For this reason, and others, I strongly object to Java/C#-style inheritance on general principle, and believe future languages should enforce interfaces only; code reuse should occur via alternate mechanisms which are not exposed to clients, such as traits in Scala, or forwarding as in systems with first-class messages.

]]> By: Andre Pang http://enfranchisedmind.com/blog/posts/implementation-exposure-through-inheritance/#comment-3094 Andre Pang Mon, 19 Feb 2007 13:05:54 +0000 http://enfranchisedmind.com/blog/archive/2007/02/17/193#comment-3094 There's <code>private</code> inheritance in C++, but I suspect you know that already :-). Outside of that, sorry. Maaaaybe you can hack up something involving Java's class loaders (and whatever the equivalent in C# is), but I suspect that using an interface and factory is probably a ton easier than that kind of craziness! There’s private inheritance in C++, but I suspect you know that already :-). Outside of that, sorry. Maaaaybe you can hack up something involving Java’s class loaders (and whatever the equivalent in C# is), but I suspect that using an interface and factory is probably a ton easier than that kind of craziness!

]]> By: Candide http://enfranchisedmind.com/blog/posts/implementation-exposure-through-inheritance/#comment-3061 Candide Sun, 18 Feb 2007 16:29:36 +0000 http://enfranchisedmind.com/blog/archive/2007/02/17/193#comment-3061 Jules: Well, if I use Ruby, the advantages I am looking for (e.g. compile-time checks on method signatures) all go away. So, yes, I do not have the problems, but I also do not have any of the advantages. PLUS I lose typo checking on my method calls (<code>list.frist</code> is a popular one for me). BHurt: I know. I was facing this problem and going wishing for type inference the whole time. And there are those out there who are categorically opposed to inheritance because of these issues -- if you want the same method signature, use interfaces. I think this is a bit too far: the Number example is a good one, because you can override one method and get the rest for free. Jules:

Well, if I use Ruby, the advantages I am looking for (e.g. compile-time checks on method signatures) all go away. So, yes, I do not have the problems, but I also do not have any of the advantages. PLUS I lose typo checking on my method calls (list.frist is a popular one for me).

BHurt:

I know. I was facing this problem and going wishing for type inference the whole time. And there are those out there who are categorically opposed to inheritance because of these issues — if you want the same method signature, use interfaces. I think this is a bit too far: the Number example is a good one, because you can override one method and get the rest for free.

]]>