No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Abstract class
From: Stefan Sobernig <stefan.sobernig_at_wu-wien.ac.at>
Date: Sun, 06 Apr 2008 14:18:05 +0200
Victor,
Kristoffer already provided you with a primer ...
> I've been looking everywhere and can't find the info.
I am wondering why you are looking for that concept in the XOTcl-verse?
Out of curiosity? Or, because you assemble your arsenal against your
Java, C#, C++ background?
There is a prior thread on this issue which provides a pretty precise
picture on that matter:
http://alice.wu-wien.ac.at/pipermail/xotcl/2000-December/004148.html
To sum it up, you won't find a direct equivalent of "abstract class" as
you might know it from languages cited above. But the key message of the
thread by Uwe Zdun is that you can approximate and, finally, build it on
your own ...
Abstract class can take the following semantics which are not mutually
inclusive (!):
~ A class object that, at least partially, consists of /abstract
methods/. Abstract methods do not provide an implementation (method body).
~ A class object that is constraint to participate only in
superclass-subclass relationships, i.e. participate only as
superclass/subclass in an object system. In other words, a class that
can not be instantiated.
~ A class object that requires its subclasses to provide
implementations (method bodies) for the set of its abstract methods.
Any of the three aspects may be approximated in XOTcl (as shown in the
thread), but still, the concept will differ. Many issues blur the
picture, for instance, time of enforcement of the abstract class
constraints (there is no compile time in XOTcl!).
The notion of "abstract class" comes with many connotations, but its
purpose has been prominently linked to their use in terms of OO
frameworks as promoted by Ralph Johnson & Co. This is inherently linked
to the need of /integrating/ a framework into a final application with
integration meaning completion. Completion, in turn, realises as
refining "abstract classes" into concrete subclasses provided by the
framework.
Another perspective is considering the need for a /type hierarchy/, on
the one, and an /implementation hierarchy/, on the other hand. Note,
that type here not necessarily means "behavioural type" in the Liskov
sense of the term. Type hierarchies are commonly realised by the
well-known "interface" constructs in languages such as Java and C#, and
the importance of interface-oriented programming gained some momentum in
recent years (while it was the default in years of CLU and Emerald, but
anyway). Implementation hierarchies, on the contrary, are commonly
realised by class-based inheritance hierarchies. The trade-offs of using
inheritance for realising both type and implementation hierarchies is
widely discussed in literature. Abstract classes somehow settle in the
middle. With abstract classes meaning collections of abstract methods,
methods that comes without a method body (=implementation), you can
approximate the idea of interfaces (as member of a type hierarchy).
Finally, at a higher level, abstract classes may help realise valuable
forms of OO design, the most prominent example being the GoF TEMPLATE
METHOD pattern.
Hope it helps to clarify the picture a bit ...
//stefan
Date: Sun, 06 Apr 2008 14:18:05 +0200
Victor,
Kristoffer already provided you with a primer ...
> I've been looking everywhere and can't find the info.
I am wondering why you are looking for that concept in the XOTcl-verse?
Out of curiosity? Or, because you assemble your arsenal against your
Java, C#, C++ background?
There is a prior thread on this issue which provides a pretty precise
picture on that matter:
http://alice.wu-wien.ac.at/pipermail/xotcl/2000-December/004148.html
To sum it up, you won't find a direct equivalent of "abstract class" as
you might know it from languages cited above. But the key message of the
thread by Uwe Zdun is that you can approximate and, finally, build it on
your own ...
Abstract class can take the following semantics which are not mutually
inclusive (!):
~ A class object that, at least partially, consists of /abstract
methods/. Abstract methods do not provide an implementation (method body).
~ A class object that is constraint to participate only in
superclass-subclass relationships, i.e. participate only as
superclass/subclass in an object system. In other words, a class that
can not be instantiated.
~ A class object that requires its subclasses to provide
implementations (method bodies) for the set of its abstract methods.
Any of the three aspects may be approximated in XOTcl (as shown in the
thread), but still, the concept will differ. Many issues blur the
picture, for instance, time of enforcement of the abstract class
constraints (there is no compile time in XOTcl!).
The notion of "abstract class" comes with many connotations, but its
purpose has been prominently linked to their use in terms of OO
frameworks as promoted by Ralph Johnson & Co. This is inherently linked
to the need of /integrating/ a framework into a final application with
integration meaning completion. Completion, in turn, realises as
refining "abstract classes" into concrete subclasses provided by the
framework.
Another perspective is considering the need for a /type hierarchy/, on
the one, and an /implementation hierarchy/, on the other hand. Note,
that type here not necessarily means "behavioural type" in the Liskov
sense of the term. Type hierarchies are commonly realised by the
well-known "interface" constructs in languages such as Java and C#, and
the importance of interface-oriented programming gained some momentum in
recent years (while it was the default in years of CLU and Emerald, but
anyway). Implementation hierarchies, on the contrary, are commonly
realised by class-based inheritance hierarchies. The trade-offs of using
inheritance for realising both type and implementation hierarchies is
widely discussed in literature. Abstract classes somehow settle in the
middle. With abstract classes meaning collections of abstract methods,
methods that comes without a method body (=implementation), you can
approximate the idea of interfaces (as member of a type hierarchy).
Finally, at a higher level, abstract classes may help realise valuable
forms of OO design, the most prominent example being the GoF TEMPLATE
METHOD pattern.
Hope it helps to clarify the picture a bit ...
//stefan
-- Stefan Sobernig Institute for Information Systems and New Media Vienna University of Economics Augasse 2-6 A - 1090 Vienna `- +43 - 1 - 31336 - 4878 [phone] `- +43 - 1 - 31336 - 746 [fax] `- stefan.sobernig_at_wu-wien.ac.at <mailto:stefan.sobernig_at_wu-wien.ac.at> `- ss_at_thinkersfoot.net <mailto:ss_at_thinkersfoot.net>