In general, there are two kinds of relationship between classes in object-oriented languages that allow one class to access features of another one:
- inheritance, and
- client-supplier relationship.
In the first case, the class inherits all features of the parent and may call them as its own:
class APPLICATION
inherit
BLUE
rename
-- Class `APPLICATION' has `make' as well,
-- so the inherited one has to be renamed to avoid a clash.
make as make_blue
end
create
make
feature {NONE} -- Initialization
make
-- Run application.
do
-- This prints "test".
print ("test")
-- Call the inherited feature `{BLUE}.test'
-- renamed above into `make_blue'
-- that prints "writetest".
make_blue
end
end
In the case of inheritance, the call is performed on the same object.
In the client-supplier relationship, the call is performed on a different object. In your example the feature to be called coincides with a creation procedure, so the call becomes a part of a creation instruction of that object being created:
class APPLICATION
create
make
feature {NONE} -- Initialization
make
-- Run application.
local
other: BLUE
do
-- This prints "test".
print ("test")
-- Create an object of type `BLUE'
-- calling its creation procedure `make'
-- that prints "writetest".
create other.make
end
end
A rough approximation regarding when to use one method over the other is the following. We can see inheritance as "is-a" and client-supplier as "has" relationship. For example, an apple has a color, but it is not a color, so client-supplier relationship fits better. On the other hand, it is a fruit, so inheritance relationship fits better. In the latter case, an apple class refines a fruit class by specifying some other properties like shape and seed location. But it cannot refine a color class. The same with your example: it does not look like APPLICATION
is an example of BLUE
, so the client-supplier relationship seems to fit better.