12.8 Support for Object-Oriented Programming in C#

public override void Draw() { ... }

...

}

C# includes abstract methods similar to those of C++, except that they are specified with different syntax. For example, the following is a C# abstract method:

abstract public void Draw();

A class that includes at least one abstract method is an abstract class, and every abstract class must be marked abstract. Abstract classes cannot be instantiated. It follows that any subclass of an abstract class that will be instantiated must implement all abstract methods that it inherits.

As with Java, all C# classes are ultimately derived from a single root class, Object. The Object class defines a collection of methods, including ToString, Finalize, and Equals, which are inherited by all C# types.

12.8.4Nested Classes

A C# class that is directly nested in a class behaves like a Java static nested class (which is like a nested class in C++). Like C++, C# does not support nested classes that behave like the nonstatic nested classes of Java.

12.8.5Evaluation

Because C# is the most recently designed C-based object-oriented language, one should expect that its designers learned from their predecessors and duplicated the successes of the past and remedied some of the problems. One result of this, coupled with the few problems with Java, is that the differences between C#’s support for object-oriented programming and that of Java are relatively minor. The availability of structs in C#, which Java does not have, can be considered an improvement. Like that of Java, C#’s support for objectoriented programming is simpler than that of C++, which many consider an improvement.

12.9 Support for Object-Oriented Programming in Ada 95

Ada 95 was derived from Ada 83, with some significant extensions. This section presents a brief look at the extensions that were designed to support objectoriented programming. Because Ada 83 already included constructs for building abstract data types, the necessary additional features for Ada 95 were those for supporting inheritance and dynamic binding. The design objectives of Ada 95 were to include minimal changes to the type and package structures of Ada 83 and retain as much static type checking as possible. Note that object-oriented

programming in Ada 95 is complicated and that this section includes only a brief and incomplete description of it.

12.9.1General Characteristics

Ada 95 classes are a new category of types called tagged types, which can be either records or private types. They are defined in packages, which allows them to be separately compiled. Tagged types are so named because each object of a tagged type implicitly includes a system-maintained tag that indicates its type. The subprograms that define the operations on a tagged type appear in the same declaration list as the type declaration. Consider the following example:

with Ada.Strings.Unbounded; use Ada.Strings.Unbounded; package Person_Pkg is

type Person is tagged private; procedure Display(P : in Person);

private

type Person is tagged

record

Name : Unbounded_String;

Address : Unbounded_String;

Age : Integer;

end record;

end Person_Pkg;

This package defines the type Person, which is useful by itself and can also serve as the parent class of derived classes.

Unlike C++, there is no implicit calling of constructor or destructor subprograms in Ada 95. These subprograms can be written, but they must be explicitly called by the programmer.

12.9.2Inheritance

Ada 83 supports only a narrow form of inheritance with its derived types and subtypes. In both of these, a new type can be defined on the basis of an existing type. The only modification allowed is to restrict the range of values of the new type. This is not the kind of full inheritance required for object-oriented programming, which is supported by Ada 95.

Derived types in Ada 95 are based on tagged types. New entities are added to the inherited entities by placing them in a record definition. Consider the following example:

with Person_Pkg; use Person_Pkg;

package Student_Pkg is

type Student is new Person with

record

Grade_Point_Average : Float;

Grade_Level : Integer;

end record;

procedure Display(St : in Student);

end Student_Pkg;

In this example, the derived type Student is defined to have the entities of its parent class, Person, along with the new entities Grade_Point_Average and Grade_Level. It also redefines the procedure Display. This new class is defined in a separate package to allow it to be changed without requiring recompilation of the package containing the definition of the parent type.

This inheritance mechanism does not allow one to prevent entities of the parent class from being included in the derived class. Consequently, derived classes can only extend parent classes and are therefore subtypes. However, child library packages, which are discussed briefly below, can be used to define subclasses that are not subtypes.

Suppose we have the following definitions:

P1 : Person;

S1 : Student;

Fred : Person := (To_Unbounded_String("Fred"),

To_Unbounded_String("321 Mulberry

Lane"), 35);

Freddie : Student :=

(To_Unbounded_String("Freddie"),

To_Unbounded_String("725 Main St."), 20, 3.25, 3);

Because Student is a subtype of Person, the assignment

P1 := Freddie;

should be legal, and it is. The Grade_Point_Average and Grade_Level entities of Freddie are simply ignored in the required coercion. This is another example of object slicing.

The obvious question now is whether an assignment in the opposite direction is legal; that is, can we assign a Person to a Student? In Ada 95, this action is legal in a form that includes the entities in the subclass. In our example, the following is legal:

S1 := (Fred, 3.05, 2);

Ada 95 does not provide multiple inheritance. Although generic classes and multiple inheritance are only distantly related concepts, there is a way to achieve an effect similar to multiple inheritance using generics. However, it is not as elegant as the C++ approach, and it is not discussed here.

12.9.3Dynamic Binding

Ada 95 provides both static binding and dynamic binding of procedure calls to procedure definitions in tagged types. Dynamic binding is forced by using a classwide type, which represents all of the types in a class hierarchy rooted at a particular type. Every tagged type implicitly has a classwide type. For a tagged type T, the classwide type is specified with T'class. If T is a tagged type, a variable of type T'class can store an object of type T or any type derived from T.

Consider again the Person and Student classes defined in Section 12.9.2. Suppose we have a variable of type Person'class, Pcw, which sometimes references a Person object and sometimes references a Student object. Furthermore, suppose we want to display the object referenced by Pcw, regardless of whether it is referencing a Person object or a Student object. This result requires the call to Display to be dynamically bound to the correct version of Display. We could use a new procedure that takes the Person type parameter and sends it to Display. Following is such a procedure:

procedure Display_Any_Person(P: in Person) is

begin

Display(P);

end Display_Any_Person;

This procedure can be called with both of the following calls:

with Person_Pkg; use Person_Pkg; with Student_Pkg; use Student_Pkg; P : Person;

S : Student;

Pcw : Person'class;

...

Pcw := P;

Display_Any_Person(Pcw); -- call the Display in Person Pcw := S;

Display_Any_Person(Pcw); -- call the Display in Student

Ada 95+ also supports polymorphic pointers. They are defined to have the classwide type, as in

type Any_Person_Ptr is access Person'class;

Purely abstract base types can be defined in Ada 95+ by including the reserved word abstract in the type definitions and the subprogram definitions. Furthermore, the subprogram definitions cannot have bodies. Consider this example:

package Base_Pkg is

type T is abstract tagged null record;

procedure Do_It (A : T) is abstract;

end Base_Pkg;

12.9.4Child Packages

Packages can be nested directly in other packages, in which case they are called child packages. One potential problem with this design is that if a package has a significant number of child packages and they are large, the nesting package becomes too large to be an effective compilation unit. The solution is relatively simple: Child packages are allowed to be physically separate units (files) that are separately compilable, in which case they are called child library packages.

A child package is declared to be private by preceding the reserved word package with the reserved word private. The logical position of a private child package is at the beginning of the declarations in the specification package of the nesting package. The declarations of the private child package are not visible to the nesting package body, unless the nesting package includes a with clause with the child’s name.

One important characteristic of a child package is that even the private parts of its parent are visible to it. Child packages provide an alternative to class derivation, because of this visibility of the parent entities. So, the private parts of the parent package are like protected members in a parent class where a child package is used to extend a class.

Child library packages can be added at any time to a program. They do not require recompilation of the parent package or clients of the parent package.

Child library packages can be used in place of the friend definitions in C++. For example, if a subprogram must be written that can access the members of two different classes, the parent package can define one of the classes and the child package can define the other. Then, a subprogram in the child package can access the members of both. Furthermore, in C++ if the need for a friend is not known when a class is defined, it will need to be changed and recompiled when such a need is discovered. In Ada 95+, new classes in new child packages can be defined without disturbing the parent package, because every name defined in the parent package is visible in the child package.

12.9.5Evaluation

Ada offers complete support for object-oriented programming, although users of other object-oriented languages may find that support to be both weak and somewhat complex. Although packages can be used to build abstract data types, they are actually more generalized encapsulation constructs. Unless child library packages are used, there is no way to restrict inheritance, in which case all subclasses are subtypes. This form of access restriction is limited in comparison to that offered by C++, Java, and C#.

C++ clearly offers a better form of multiple inheritance than Ada 95. However, the use of child library units to control access to the entities of