mirror of
https://gitlab.com/fbb-git/cppannotations
synced 2024-11-16 07:48:44 +01:00
777b182edd
This allowed me to standardize the sourcetar and sf/* scripts: the base
directory (containing ./git) is now empty, except for maintenance scripts,
while the source files and build scripts of the annotations are stored in
a subdirectory of their own.
57 lines
3.1 KiB
Text
57 lines
3.1 KiB
Text
When programming in bf(C), programming problems are commonly approached using
|
|
a top-down structured approach: functions and actions of the program are
|
|
defined in terms of sub-functions, which again are defined in
|
|
sub-sub-functions, etc.. This yields a i(hierarchy of code): tt(main) at
|
|
the top, followed by a level of functions which are called from tt(main),
|
|
etc..
|
|
|
|
In bf(C++) the i(relationship between code and data) is also frequently
|
|
defined in terms of dependencies among em(classes). This looks like
|
|
emi(composition) (see section ref(Composition)), where objects of a class
|
|
contain objects of another class as their data. But the relation described
|
|
here is of a different kind: a class can be em(defined) in terms of an older,
|
|
pre-existing, class. This produces a new class having all the functionality of
|
|
the older class, and additionally defining its own specific functionality.
|
|
Instead of composition, where a given class em(contains) another class, we
|
|
here refer to emi(derivation), where a given class em(is) or
|
|
em(is-implemented-in-terms-of) another class.
|
|
|
|
Another term for derivation is emi(inheritance): the new class inherits the
|
|
functionality of an existing class, while the existing class does not appear
|
|
as a data member in the interface of the new class. When discussing
|
|
inheritance the existing class is called the emi(base class), while the new
|
|
class is called the emi(derived class).
|
|
|
|
Derivation of classes is often used when the methodology of bf(C++) program
|
|
development is fully exploited. In this chapter we first address the
|
|
syntactic possibilities offered by bf(C++) for deriving classes. Following
|
|
this we address some of the specific possibilities offered by
|
|
class derivation (inheritance).
|
|
|
|
As we have seen in the introductory chapter (see section ref(OOP)), in the
|
|
object-oriented approach to problem solving classes are identified during the
|
|
i(problem analysis). Under this approach objects of the defined classes
|
|
represent entities that can be observed in the problem at hand. The classes
|
|
are placed in a hierarchy, with the top-level class containing limited
|
|
functionality. Each new derivation (and hence descent in the
|
|
i(class hierarchy)) adds new functionality compared to yet existing classes.
|
|
|
|
In this chapter we shall use a simple vehicle classification system to build a
|
|
hierarchy of classes. The first class is tt(Vehicle), which implements as its
|
|
functionality the possibility to set or retrieve the mass of a vehicle. The
|
|
next level in the object hierarchy are land-, water- and air vehicles.
|
|
|
|
The initial i(object hierarchy) is illustrated in fig(hierarchy).
|
|
figure(inheritance/hierarchy)
|
|
(Initial object hierarchy of vehicles.)
|
|
(hierarchy)
|
|
|
|
This chapter mainly focuses on the technicalities of class derivation. The
|
|
distinction between inheritance used to create derived classes whose objects
|
|
should be considered objects of the base class and inheritance used to
|
|
implement derived classes em(in-terms-of) their base classes is postponed
|
|
until the next chapter (ref(POLYMORPHISM)).
|
|
|
|
Inheritance (and polymorphism, cf. chapter ref(POLYMORPHISM)) can be used with
|
|
classes and structs. It is not defined for unions.
|
|
|