Why not SubClass instead of making an object Switchable

Why not SubClass instead of making an object Switchable

Old forum URL: forums.lhotka.net/forums/t/203.aspx


Jav posted on Thursday, May 25, 2006

For objects that have a lot of inherent complexity - the very kind that cry out for switchable functionality, does it not make more sense to simply subclass and add the "Root" functionality to the sublass.  It should provide a neater set of objects.

How does this sound?

Jav

DansDreams replied on Friday, May 26, 2006

It seems to fit the "single purpose" requirement better, eh?

The constructor doesn't need to be protected though, does it? Since the inherited class IS also the base class, it should be able to call the private constructor.

DansDreams replied on Friday, May 26, 2006

Actually, constructors aren't inherited in the normal sense anyway, so I really think you'd want to stay with the private one to make sure that's what's called when you instantiate via the private one in the inherited class.  Yes, no, maybe so?

Jav replied on Friday, May 26, 2006

Yes, y'all have reached the right conclusion.  For a class to be inheritable, it has to have at least a Protected access Constructor.  Since writing my original post, I have gone ahead and implemented the scheme in an object that was becoming unmanageable as a switchable.  Everything has worked just fine.  In fact in all my UI custom controls, where the previously switchable control is being used in data binding, I have had to make not a whit of change.  I simply pass the new root control to the same controls.

Jav

LayeredDev replied on Friday, May 26, 2006

I thought that inherited classes cannot call private members of the base class. The member has to be declared protected so that it can be called from an inherited class.

ajj3085 replied on Friday, May 26, 2006

LayerDev,

You are right; sub classes cannot call private members.

This also applies to constructors; you'll get a compiler error if you try to subclass from a class which only has a private constructor.

Andy

Copyright (c) Marimer LLC