Author Topic: Abstract child of an instantiable class  (Read 1043 times)

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Abstract child of an instantiable class
« on: August 10, 2006, 10:39:30 pm »
Is it conceptually "fit and proper" to have a specialised class marked as abstract when its parent(s) are instantiable?

I got asked this today and cant find an answer.

Further, is it allowable (or more correctly, how can one model) a class that is abstract in certain (general) circumstances, but instantiable in other (priviledged) circumstances?

bruce

« Last Edit: August 10, 2006, 10:42:01 pm by sargasso »
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

«Midnight»

  • EA Guru
  • *****
  • Posts: 5651
  • Karma: +0/-0
  • That nice Mister Grey
    • View Profile
Re: Abstract child of an instantiable class
« Reply #1 on: August 11, 2006, 04:44:30 am »
IMHO - and I admit I need to work through this a bit - the answer to your first query seems to be "yes." The situation would be obscure, but I don't see it breaking any rules. Basically, the child class of a concrete parent class could define new methods beyond what the parent provides. Some of these new methods could be virtual. We could get into quite a discussion about shadowed (.Net speak, so others should translate to their local argot) methods and such, but I see the cows returning already...

As to the second query, I suspect you might have a trick question here. When you model it out I think you will (perhaps should, or even must) come up with some form of black box with a hierarchy of classes. These would include both the 'true' virtual class and the concrete child class with appropriate guards. You might also have the validation logic in a manager (or whatever) class, or even as part of a factory. These latter approaches might be better for putposes of using well-known patterns.

An alternate scenario for the second query is to have conditional logic in the constructor (or whatever) to determine whether instantiation is allowed, and to benignly return nothing (or an appropriate error, depending on your framework) otherwise. This is much along the lines of defining a singleton class on your own in paradigms that do not support this at the language level (.Net for an example). In these cases the overall structure is just another class definition, with conditions etc.

David
No, you can't have it!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 6148
  • Karma: +83/-85
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Abstract child of an instantiable class
« Reply #2 on: August 11, 2006, 06:19:37 am »
Quote
Is it conceptually "fit and proper" to have a specialised class marked as abstract when its parent(s) are instantiable?
I got asked this today and cant find an answer.
Further, is it allowable (or more correctly, how can one model) a class that is abstract in certain (general) circumstances, but instantiable in other (privileged) circumstances?
bruce
bruce,

Some languages, notably Eiffel (and, I think, C++), allow this.  In Eiffel terms you are creating a Deferred descendant from an Effective ancestor.  This process is called Undefinition.
(See 14.5 Deferred Features and Classes in Object Oriented Software Construction II)

As to your second question, I suspect that the same class can't be, since whether a Class is Effective or Deferred is a design time decision.  However, I stand to be corrected on that.

HTH,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!