Extension of classes is a more pragmatic concept than specialization of classes. Specialization of classes is directly based on - and inspired from - specialization of concepts, as discussed in Section 3.4. Extension of classes is a much more practical idea.

In the previous chapter (Chapter 25) we discussed specialization of classes. In this section we discuss class extension. In C# both class specialization and class extension will be dealt with by class inheritance, see Chapter 27.

26.1 Extension of Classes 26.3 The intension of class extensions 26.2 An example of simple extension

 

26.1.  Extension of Classes
Contents   Up Previous Next   Slide Annotated slide Aggregated slides    Subject index Program index Exercise index 

As the name suggests, class extension is concerned with adding something to a class. We can add both variables and operations.

We are not constrained in any way (by ideals of specialization or substitution) so we can in principle add whatever we want. However, we still want to have coherent and cohesive classes. We want classes focused on a single idea, where all data and operations are related to this idea. Our classes should be used as types for declaration of variables, and it should make sense to make instances of the classes. Thus, we do not want to treat classes are general purposes modules (in the sense of boxing modularity, see Section 2.3).

These considerations lead us to the following definition of class extension.

26.2.  An example of simple extension
Contents   Up Previous Next   Slide Annotated slide Aggregated slides    Subject index Program index Exercise index 

In this section we will look at a typical example of class extension, which distinguishes itself from specialization as seen in Chapter 25.

Below, in Program 26.1 we show the class Point2D. It is a variant of one the Point types we have studied in Section 11.6, Section 14.3, and Section 18.2. The variant programmed below implements mutable points. This is seen in line 19, which assigns to the state of a Point object.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

using System;

public class Point2D {
  private double x, y;

  public Point2D(double x, double y){
   this.x = x; this.y = y;
  }

  public double X{
    get {return x;}
  }

  public double Y{
    get {return y;}
  }

  public void Move(double dx, double dy){
    x += dx; y += dy;
  }

  public override string ToString(){
    return "Point2D: " + "(" + x + ", " + y + ")" + ".";
  }
}

In Program 26.2 we extend the class Point2D with an extra coordinate, z, and hereby we get the class Point3D.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

using System;

public class Point3D: Point2D {

  private double z;

  public Point3D(double x, double y, double z):
         base(x,y){
   this.z = z;
  }

  public double Z{
    get {return z;}
  }

  public void Move(double dx, double dy, double dz){
    base.Move(dx, dy);
    z += dz;
  }

  public override string ToString(){
    return "Point3D: " + "(" + X + ", " + Y + ", " + Z + ")" + ".";
  }
}

Notice that Move in Point3D does not conflict with Move in Point2D. The reason is that the two methods are separated by the types of their formal parameters. The two Move operations in Point3D and Point2D are (statically) overloaded. Thus relative to the discussion in Section 28.9 it is not necessary to supply a new modifier of Move in Point3D.

We also show how to use Point2D and Point3D in a client class, see Program 26.3. The output of the client program is shown in Listing 26.4.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

using System;

public class Application{

  public static void Main(){
    Point2D p1 = new Point2D(1.1, 2.2),
            p2 = new Point2D(3.3, 4.4);

    Point3D q1 = new Point3D(1.1, 2.2, 3.3),
            q2 = new Point3D(4.4, 5.5, 6.6);

    p2.Move(1.0, 2.0);
    q2.Move(1.0, 2.0, 3.0);
    Console.WriteLine("{0} {1}", p1, p2);
    Console.WriteLine("{0} {1}", q1, q2);
  }

}

1
2

Point2D: (1,1, 2,2). Point2D: (4,3, 6,4).
Point3D: (1,1, 2,2, 3,3). Point3D: (5,4, 7,5, 9,6).

The important observations about the extension Point3D of Point2D can be stated as follows:

A 3D point is not a 2D point Thus, Point3D is not a specialization of Point2D The set of 2D point objects is disjoint from the set of 3D points

The is-a test (see Section 25.2) fails on the class Point3D in relation to class Point2D. The "has-a test" also fails. It is not true that a 3 dimensional point has a 2 dimensional point as one its parts. Just look at the class Point3D! But - in reality - the "has-a test" is closer to success than the "is-a test". Exercise 7.1 researches an implementation of class Point3D in terms of a Point2dD part.

It is interesting to wonder if the principle of substitution applies, see Section 25.7. Can we substitute instances of Point3D in place of instances of Point2D without observable effects? Due to the independence and orthogonality of the three dimensions the principle of substitution is almost applicable. But the Move operation, as redefined in class Point3D, causes problems. The Move operation in class Point2D does an incomplete move when applied on a 3D point. And as noticed, Move in class Point3D is not a redefinition of Move from class Point2D. There are two different Move operations available on an instance of class Point3D. This is a mess!

In the last item it is stated that extensions (see Section 3.1) of class Point2D and class Point3D are disjoint (non-overlapping). Conceptually, there is no overlap between the set of two-dimensional points and the set of three-dimensional points! This is probably - in a nutshell - the best in indication of the difference between the Point2D/Point3D example and - say - the BankAccount examples from Section 25.3 .

26.3.  The intension of class extensions
Contents   Up Previous Next   Slide Annotated slide Aggregated slides    Subject index Program index Exercise index 

In Section 25.2 we realized that the essential characteristics of specialization is the narrowing of the class extension, see Figure 25.2. Above, in Section 26.2, we realized the the class extension of an extended class (such as Point3D) typically is disjoint from the class extension of the parent class (such as Point2D).

In this section we emphasize the similar, clear-cut characteristics of class extension, namely the enlargement of the class intension. This is illustrated in Figure 26.1.

Please be aware of possible confusion related to our terminology. We discuss class "extension" in this section, and we refer to the "intension" and "extension" (related to concepts, as discussed in Section 3.1). The two meanings of "extension" should be kept apart. They are used with entirely different meanings.

Figure 26.1    The intension of a class A is blown up when the class is extended to B