Polymorphism; How to get the specific class?

[nuzzle]

But if you derive everything from a single class, then there must be some virtual method or property that every object in your design needs to possess. Otherwise, it's fairly pointless. That isn't impossible, but it seems like it would be fairly rare.

You're imposing your lack of imagination on others, even trying to make a "C++ paradigm" out of it.

[Lindley]

Well, I'm not the only one. The "God Object" is called an anti-pattern for a reason.

But if you think it's so great, I'd be curious to see a justifiable example.

[laserlight]

You're imposing your lack of imagination on others, even trying to make a "C++ paradigm" out of it.

I think that it is indeed a paradigm, and is implied by the core language and standard library, and even stated somewhat explicitly by Stroustrup. In Gotcha #97, Stephen Dewhurst claimed that:

More than a decade ago, the C++ community decided that the use of "cosmic" hierarchies (architectures in which every object type is derived from a root class, usually called Object) was not an effective design approach in C++.

[nuzzle]

Well, I'm not the only one. The "God Object" is called an anti-pattern for a reason.

The "god class" anti-pattern warns you not to build a design around one big all-knowing class. In such a design one class controls everything and uses other classes as mere records to shuffle data in and out from. I don't think it's even possible to misuse a common top class according to this antipattern but if you manage to find a way you definately shouldn't do it.

So a common top class will sit at the top of all inheritance hierarchies, and if you want to call it a "god class" because of that you may do so. This however won't make it bad in the "god class" anti-pattern sense.

But if you think it's so great, I'd be curious to see a justifiable example.

In C++ there's no language-wide top class so here you would introduce one to give all application classes a common functionality. Still Java and C# are good examples of what kind of functionality that could be. The only requirement really is that it should be of clear application-wide interest.

Here are a few specific examples.

Say for example you would like to enumerate all objects. This would make every application object identifiable. Then you would like to introduce a counter in all objects to hold a unique number.

Or maybe you would want to standardise on an application wide memory management scheme. Say you want to use a reference counting smart pointer. If you want to make it intrusive you would like all objects to hold a reference counter.

[nuzzle]

I think that it is indeed a paradigm,

I think it's great that C++ doesn't enforce a common top class. This is only to be expected from a language which supports multiple programming paradigms. But just because C++ doesn't force it on you doesn't mean it's wrong to introduce a top class in your own applications.

The Stephen Dewhurst reference you posted agrees with my view. It states that a "cosmic" top class in C++ would be bad. I don't think any C++ programmer wants a "cosmic" top class, I certainly don't. But again, this doesn't mean it's wrong to use a common top class of your own design to good effect in your own application, and it certainly isn't anti-C++ in any way.

In short, the fact that the C++ language doesn't enforce a "cosmic" top class on you doesn't make it a paradigm that you shouldn't introduce an application-wide one yourself.

[laserlight]

But again, this doesn't mean it's wrong to use a common top class of your own design to good effect in your own application, and it certainly isn't anti-C++ in any way.

I think that you are just unnecessarily harping on semantics. Let us review the context:

I have an (abstract) class named BaseObject, whose purpose is just to be extended upon.

The notion of a BaseObject which *everything* inherits from doesn't fit the C++ paradigm very well. It's really more of a Java concept. You should consider whether or not it's really necessary here. What does having that BaseObject get for you?

A class "whose purpose is just to be extended upon" certainly does not sound like the use of "a common top class of your own design to good effect in your own application", and "a BaseObject which *everything* inherits from" really means a "cosmic" base class that is so general that it is blindly all inclusive. This differs from an application wide base class that provides just the right amount of generalisation for an application specific problem.

This, I think, is the lesson to learn: you should avoid generalising classes beyond what is appropriate.