An introduction to Object-oriented language (III.)

One of the main characteristics of the traditional object-oriented language based on class is the inseparable connection between inheritance, subclassing and subtyping. Many of the object-oriented language syntax, concepts, from these three. For example, by subclassing, you can inherit some of the methods of the parent class, while at the same time you can rewrite the parent class's method in the subclass. This rewritten method, through subtyping, subsumption, can be invoked from an object of a type that is a parent class.

However, inheritance, subclassing, subtyping these three are not always in harmony. In some cases, the tangle between the three will hinder code reuse through inheritance or generics. As a result, people began to notice the possibility of separating the three. It is common to distinguish between subclassing and subtyping. Other methods are at the stage of research. In this chapter we will introduce some of these methods.

One, Object type

In the early object-oriented language (such as Simula), the definition of a type is mixed with the implementation of the method. This is a violation of the principle of separating implementation from norms (specification) that we have been widely aware of today. This principle of separation is especially important when development is a team.

In more recent languages, implementations and specifications are differentiated by introducing object types that are not dependent on implementation. Modula-3 and other support classes and interface languages, such as Java, are used in this technique.

In this book, when we begin to introduce instancetypeof (cell), it represents a fairly limited concept. It appears that it only represents the type of object generated with the new cell, so we cannot use it to represent objects that are new from other classes. But later, when we introduced subclassing, method overriding, subsumption and dynamic dispatch, things became less simple. Our instancetypeof (cell) can already be used to represent objects that are new from the cell's subclass, which can include properties and methods that are not defined by the cell class.

So it seems unreasonable to make instancetypeof (cell) dependent on a specific class. In fact, a instancetypeof (cell) Type of object does not necessarily have any relation to the class cell.

The only thing in common with the cell class is that it has the signature (signature) of all the methods defined by the cell class.

Based on this consideration, we can introduce the syntax of the object type:

For the cell class and the ReCell class definition:

class cell is

var contents: Integer :=0;

method get(): Integer is

return self.contents;

end;

method set(n:Integer) is

self.contents := n;

end;

end;

subclass reCell of cell is

var backup: Integer := 0;

override set(n: Integer) is

self.backup := self.contents;

super.set(n);

end;

method restore() is

self.contents := self.backup;

end;

end;