9fe4d26c59
git-svn-id: https://yap.svn.sf.net/svnroot/yap/trunk@1539 b08c6af1-5177-4d33-ba66-4b1c6b8b522a
61 lines
3.3 KiB
Plaintext
61 lines
3.3 KiB
Plaintext
=================================================================
|
|
Logtalk - Object oriented extension to Prolog
|
|
Release 2.27.0
|
|
|
|
Copyright (c) 1998-2006 Paulo Moura. All Rights Reserved.
|
|
=================================================================
|
|
|
|
|
|
To load this example and for sample queries, please see the SCRIPT file.
|
|
|
|
You can find the original description of this example (and a solution using
|
|
SICStus Objects) at the URL:
|
|
|
|
http://www.sics.se/ps/sicstus/sicstus_32.html#SEC254
|
|
|
|
Suppose you wish to represent points in a two-dimensional space. The
|
|
protocol you will have to define consists on the operation move/2, which
|
|
allows you to move one point to a new position, and on the operation
|
|
print/0, which prints the point position. From the base class point,
|
|
which contains the indicated operations, we wish to build three
|
|
variants. One class bounded_point in which one point can only move in a
|
|
restricted area in space. One class history_point, characterized from
|
|
the particularity that each point recalls its previous positions.
|
|
Finally, a class bounded_history_point combining the functionality of
|
|
classes bounded_point and history_point.
|
|
|
|
At first sight, this looks like the kind of ideal problem to illustrate
|
|
the advantages of the multiple inheritance mechanisms. However, this type
|
|
of solution holds several problems. If the methods move/2 and
|
|
print/0 are inherited by bounded_history_point of classes
|
|
history_point and bounded_point simultaneously, then one point will be
|
|
moved and shown twice. If the inheritance is carried out, for each
|
|
method, only from one of the superclasses (assuming that it is possible
|
|
to do so, only by breaking the apparent problem symmetry), then the
|
|
interfaces of classes history_point and bounded_point will have to
|
|
contain separately the necessary operations to verify the limits (in the
|
|
case of bounded_point), or to recall the previous positions (in the
|
|
case of history_point). This way, the class bounded_history_point could
|
|
build its own versions of methods move/2 and print/0, adding to the
|
|
inherited definitions of one of the superclasses the calling of the
|
|
operation missing in the other superclass. This is the solution adopted
|
|
in the SICStus Objects. However, this solution also implies a few
|
|
problems. Let's suppose that method move/2 is inherited from class
|
|
history_point. Then, any changing operated in the definition of the same
|
|
method in class bounded_point is ignored by bounded_history_point. The
|
|
problem can be unnoticed, once the symmetry suggested by the use of
|
|
multiple inheritance does not reflect on the present implementation.
|
|
|
|
The solution just suggested is, in short, a generalization of the
|
|
problem previously described. Instead of using multiple inheritance,
|
|
let's use composition mechanisms. In order to do so, let's separate the
|
|
operations on one point, while an object state, of the classes
|
|
representing each one of the point types. This can be achieved through
|
|
the definition of two new categories, bounded_coordinate and
|
|
point_history, that will define the operations associated both to the
|
|
memorization of previous values, and to the verification of feasible
|
|
limits for a coordinate value. Each one of the point, bounded_point,
|
|
history_point and bounded_history_point classes will import this
|
|
category, using his operations so as to define the methods affecting the
|
|
solutions that use multiple inheritance.
|