?

Log in

No account? Create an account

Inheritance (the OOP kind)

« previous entry | next entry »
Sep. 11th, 2007 | 08:31 pm
mood: geekygeeky

I've recently noticed that deciding class inheritance requires looking at the behaviour you want from your classes a lot more than I'd previously realised[1]. Looking at what they represent isn't enough. Looking at the classic Rectangle and Square example in OOP..

If we are interested in creating a couple of read-only and immutable classes (Get methods only), then everything we can ask of a Rectangle we can also ask of a Square (GetWidth() and GetHeight()). So leading from this we'd be inclined to make Square inherit from Rectangle.

Alternatively.. If we are interesting in write-only classes and we focus only on the Set methods then we come to the opposite conclusion. Having Rectangle as base would imply that Square would need to implement SetWidth() and SetHeight(), not very clever. Only SetSize() makes sense for both shapes, and so we conclude that Square should be the base, with Rectangle derived (presumably SetSize() on a rectangle would set both the width and height in one go).

Can this sort of issue (where looking at different behaviour requirements for the same set of objects could lead to different decisions about inheritance) crop up with real classes? Or is this an artifact of the slightly dodgy example[2]? I'm inclined to think it is a real problem, but I can't think of an instance in which this has bitten me for real.

Is there a name for this kind of analysis? Can any of the more experienced programmers out there suggest a good book?

Also.. What happens if you have an existing class hierarchy and are interested in adding a new feature, only to discover that the new feature would require a different inheritance layout? (Maybe we have read-only shape classes, and want to extend them to be mutable).

[1] Hmm, books always say that classes should focus on behaviour more than anything else.
[2] We probably shouldn't have a Square class, or at least it should be unrelated to Rectangle.

Link | Leave a comment | Share

Comments {2}

Use interfaces instead of inheritance

from: anonymous
date: Sep. 11th, 2007 09:31 pm (UTC)
Link

It is worth noting that most of the problems go away if you stop using inheritance. Define 3 interfaces (one for GetWidth/GetHeight, one for SetWidth/SetHeight, one for SetSize), and two independent Square and Rectangle classes which each implement the appropriate interfaces.

Using inheritance messes up the representations as well: you either get a Square class which has independent width and height members inherited from its Rectangle parent, or a Rectangle class which has a size member inherited from its Square parent, and then has to introduce its own with and height members.

DaveT

Reply | Thread

zombywuf

Re: Use interfaces instead of inheritance

from: zombywuf
date: Sep. 13th, 2007 05:07 pm (UTC)
Link

Well, using interfaces in this case really is inheritance. The issue is possibly better resolved really by referring to the context. You may not want the classes to be related to each other at all. You might want them both to inherit from Shape, possibly via FourSidedShape with a mixin of RegularShape for the Square. Or may be go Shape -> RegularShape -> mixin 4 sided -> Square.

It all depends on what you want to do with the classes, and what you may want to do with them later (while simultaneously avoiding the second system effect :-). There's a reason computer architecture is called an old man's game. You've got to get it wrong many many times before you can get the 4SidedObject into the Square hole.

Reply | Parent | Thread