Organizing classes with UML diagrams

So far, our object-oriented solution includes nine classes with their fields and methods. However, if we take another look at these nine classes, we will notice that all of them have the same two methods: calculateArea and calculatePerimeter. The code for the methods in each class is different because each shape uses a special formula to calculate either the area or perimeter. However, the declarations, contracts, interfaces, or protocols for the methods are the same. Both methods have the same name, are always parameterless, and return a floating point value. Thus, all of them return the same type.

When we talked about the nine classes, we said we were talking about nine different geometrical 2D shapes or simply shapes. Thus, we can generalize the required behavior, protocol, or interface for these nine shapes. The nine shapes must define the calculateArea and calculatePerimeter methods with the previously explained declarations. We can create an interface to make sure that the nine classes provide the required behavior.

The interface is a special class named Shape, and it generalizes the requirements for the geometrical 2D shapes in our application. In this case, we will work with a special class that we won't use to create instances, but in the future, we will use interfaces for the same goal. The Shape class declares two parameterless methods that return a floating point value: calculateArea and calculatePerimeter. Then, we will declare the nine classes as subclasses of the Shape class, which will inherit these definitions, and provide the specific code for each of these methods.

Tip

The subclasses of Shape (Circle, Ellipse, EquilateralTriangle, Square, Rectangle, RegularPentagon, RegularHexagon, RegularOctagon, and RegularDecagon) implement the methods because they provide code while maintaining the same method declarations specified in the Shape superclass. Abstraction and hierarchy are two major pillars of object-oriented programming. We are just making our first steps in this topic.

Object-oriented programming allows us to discover whether an object is an instance of a specific superclass. After we change the organization of the nine classes and they become subclasses of Shape, any instance of Circle, Ellipse, EquilateralTriangle, Square, Rectangle, RegularPentagon, RegularHexagon, RegularOctagon, or RegularDecagon is also an instance of the Shape class.

In fact, it isn't difficult to explain the abstraction because we speak the truth about the object-oriented model when we say that it represents the real world.

It makes sense to say that a regular decagon is indeed a shape, and therefore, an instance of RegularDecagon is also an instance of the Shape class. An instance of RegularDecagon is both a Shape (the superclass of RegularDecagon) and a RegularDecagon (the class that we used to create the object).

The following figure shows an updated version of the UML diagram with the superclass or base class (Shape), its nine subclasses, and their attributes and methods. Note that the diagram uses a line that ends in an arrow that connects each subclass to its superclass. You can read the line that ends in an arrow as the following: the class where the line begins is a subclass of the class that has the line ending with an arrow. For example, Circle is a subclass of Shape, and Rectangle is a subclass of Shape. The diagram shows the results of the third round.

Note

A single class can be the superclass of many subclasses.