One interesting question: If objects are in an array rather than being
individually allocated (and handled through references/pointers), can it
still be called object-oriented? (I'm not talking about an array of
references to objects, but an array of actual objects.)

  For example a heap (ie. what is used eg. in heap sorting) is an extremely
ingenuous form of binary tree in that all the elements in a heap can be
stored in an array and they require no ancillary data whatsoever (ie.
left/right/parent pointers or anything). Elements can be added and removed
from the heap in O(log n) regardless of this. (About the only thing that
is guaranteed about the distribution of the elements in the heap is,
however, that the largest element will always be at the root. However,
even this guarantee is quite useful in many tasks, such as maintaining
a fast priority queue or heap sorting.)

  The advantage of a heap is, of course, that it consumes the least amount
of memory because all the objects are in a contiguous array, rather than
being allocated individually and handled through references/pointers.

  However, can this be called object-oriented? Having objects in an array
excludes the possibility of using objects of a derived type (unless an
object of the derived type has the exact same size as the base type object;
even then it requires some low-levelish trickery to get it working, at
least in C++, and probably other languages where objects can be handled
by value and put into arrays). However, one of the basic ideas of OOP is
that whenever an object of type A is expected, an object of type B can be
given to it instead, if B has been derived from A (or from any of its
subclasses). An array of objects wouldn't support this.

-- 
                                                          - Warp

Post a reply to this message