Blogs

This Blog

News

Favorite Posts

Archives

ctodx

Discussions, news and rants from the CTO of DevExpress, Julian M Bucknall

Talking about inheritance

I was having an IM chat with an old friend yesterday afternoon (let's call him A). He's starting to pull his hair out (he has more than me, so I'm not worried yet) with regard to the obtuseness of his fellow developers. They're somewhat prone, shall we say, to producing unwieldy class models that can't easily be extended or maintained.

We chatted a bit about implementation inheritance versus interface inheritance using composition. Implementation inheritance is what programmers normally think about when they hear "inheritance". They think of a class hierarchy, they consider which methods to make virtual (or, if you're using Java, which methods if any to make final), they worry about private versus protected. Interface inheritance is when you write a cless that implements one or more interfaces, usually through some kind of composition technique.

J: The big problem with implementation inheritance is that you are tightly coupling the descendant to the ancestor. The ancestor is not this black box, it's much more transparent than that.

A: Right, exactly.

J: As soon as you have a virtual method you impose this awful problem on the writer of the override. Do I call the ancestor's method? If so, when can I call it? At the beginning of my overridden method? At the end? Anywhere I like? Can I set up some data, call some other ancestor methods first? Or is there some calling dependency I don't understand here? The writer of the descendant is forced to read and understand the code for the ancestor.

A. And it's not just the virtual methods, it's the ancestor's local data. Should the ancestor make this data available directly as a protected field? If so what are the ramifications of this?

J. Indeed.

A. So I'm thinking about it, and I'm mostly coming up with the conclusion that some form of composition results in more flexbility and eaiser to understand code when compared with traditional implementation inheritence. I'm thinking that maybe I should talk about this to the developers at one of the design meetings.

J: The problem is, will they understand?

A: The problem is, the ones who need to understand never come to the meetings :(

J: Aye, true.
J: You really need a good refactoring tool though.
J: It's not impossible without, just more difficult and a bit tedious.

A: Do you have any articles you recommend on composition over inheritance?

J: Let me check some out. The Design Patterns book by the GOF is a paean to composition over inheritance.
J: The first thing to drill into their heads is Single Responsibility Principle (SRP), but some really don't get even that.

A: Good point, maybe I should be focusing on the principles and see what I get from that...

J: SRP is the biggest because it's the hardest to get across.

A: I think the problem stems from how programming is taught.

J: Yep. Or, people come to OOP through procedural (say to C# from VB6) and program in the same way they always did.

A: It's taught backwards -- you're told to think of the data, so all your classes become nothing more than structs, and then you think of what you do to that data, and you never quite get to how the system interacts, and it's those relationships that make the code work or not.
A: We should start with discussing interactions and relationships of classes, not data packaging

J: Yep. Teach behavior, not data. The bible of that is "Object Thinking" by David West. I worry it's above most people's heads.

A: It will remain there until they are paired with people who can teach it, or find a job where it doesn't really matter :(

J: I'd say, start with SRP. Take some class and show how it has more than two responsibilities and break it apart. Say, any class in [A's company's main application]. LOL

A: "now see this class has 36 responsibilities, so we type "del class.cs" and start over"

J: LOL
J: Trouble is, SRP requires thinking about design and understanding choices and knowing why A is better than B.

A: Judgement... hard to teach.

Published May 18 2006, 04:03 PM by
Bookmark and Share

Comments

Alex Hoffman

Julian Bucknall (DevExpress) has written a great post on interface versus implementation inheritance,...
May 29, 2006 12:07 AM

dotnetkicks.com

Trackback from dotnetkicks.com
May 29, 2006 4:07 AM

JayFlowers > Judgement… hard to teach

May 29, 2006 6:12 PM

keith ray

With people who don't "get it", focusing on code-smells may be better than trying to teach design principles... because code-smells are concrete violations of design principles.

Trying printing out this article and going over it with your team.

http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=75

Please let us know how that works out.
May 30, 2006 12:34 PM

Alex Hoffman

Developers, Inheritance and Skills

January 29, 2008 8:22 PM

About Julian Bucknall (DevExpress)

Julian is the Chief Technology Officer at Developer Express. You can reach him directly at julianb@devexpress.com. You can also follow him on Twitter with the ID JMBucknall.
LIVE CHAT

Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383

FOLLOW US

DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. Whether using WPF, Silverlight, ASP.NET, WinForms, HTML5 or Windows 8, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2014 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners