General Relationship-excerpt

CEN Advanced Technology Training Center (www.itisedu.com)

Generalization is a classification relationship between a general element and a specific element. The specific element is exactly the same as the general element, but it contains some additional information. An instance of a specific element can be used when general elements are allowed.

In real life, many things share common characteristics. For example, both dogs and cats are animals. Objects can also have common features. You can use the generalized relationships between classes to clarify these common features. By extracting common features into the classes they belong to, you can easily change and maintain the system in the future.

Generalized relationships indicate the inheritance of one class to another class. The inherited class is called a descendant. The inherited class is called the ancestor. Inheritance means that the definition of the ancestor (including any features, such as attributes, links, or operations performed on its objects) is also valid for the objects of future generations. The general relationship is the relationship from the descendant class to its ancestor class.

Generalized relationships can take place in several stages, which allows you to model complex, multilevel inherited hierarchies. Generally, features are in the upper part of the hierarchy, while special features are in the lower part. That is to say, you can use generalized relationships to create special models for general concepts.

Example

In the recycler system, all classes (CAN, bottle, and crate) describe different types of storage items. Except for the same type, they share two common features: height and weight. You can model these features using attributes and operations in a separate deposit Item class. Can, bottle, and crate will inherit such features.

Classes can, bottle, and crate share the same features: height and weight. They are the specialization of the general concept of "Storage items.

I. Multiple inheritance

Although a class generally only inherits from one class, it can also inherit from several other classes multiple times.

When using multiple inheritance, you must pay attention to the following two potential problems:

If a class inherits from several classes, you must check the naming methods of the relationships, operations, and attributes in the ancestor. If the same name appears in several ancestors, it must indicate what this means for a specific inherited class. For example, the declared source is indicated by a qualified name.
If repeated inheritance is used, the same ancestor will be inherited multiple times by one descendant. In this case, the inheritance hierarchy is represented as a "diamond", as shown below.

Repeated inheritance. The scrolling window with dialog box class is inherited multiple times from the window class.

In this environment, a problem may occur. How many copies of the window attribute are contained in the scrolling window with dialog box instance? Therefore, to use repeated inheritance, you must define the meaning of the inheritance. In most cases, it supports multiple inheritanceProgramming Language.

Generally, the inherited programming language rules are complex and often difficult to use correctly. Therefore, it is best to use multiple inheritance as needed, so be careful when using it.

Ii. abstract classes and specific classes

If a class is not instantiated and only exists for other classes to inherit it, it is an abstract class. The actually instantiated class is a specific class. Note that abstract classes must have at least one descendant to become useful classes.

Example

The pallet place in the warehouse management system is an abstract entity class that represents the Features shared by different types of pallets. This class is inherited by specific classes station, transporter, and storage unit. All these classes can be used as pallets in the warehouse. All these objects share one feature: they can accommodate one or more pallets ).

The inherited class (pallet place here) is abstract and does not instantiate itself.

Iii. Use

Because each class constructor has different purposes, it makes no sense to inherit from one class constructor to another class constructor. For example, if the boundary class inherits the object class, the boundary class will become a mixture of things. Therefore, generalized relationships should only be used between classes with the same constructor type.

You can use generalized relationships to express the two relationships between classes:

Create a child type to specify that the descendant is the child type of the ancestor. Creating a child type means that the descendant inherits the structure and behavior of the ancestor, and the descendant is a type of the ancestor (that is, the descendant is a child type that can replace all its ancestors under any circumstances ).
Create a subclass to specify that the descendant is a subclass of the ancestor rather than a child type ). Creating a subclass means that the descendant inherits the structure and behavior of the ancestor, and the descendant is not a type of the ancestor.
To create the preceding two relationships, you can extract the Features shared by several classes and put them into a separate class for other classes to inherit. Alternatively, you can create a new class that makes the general class special, and let them inherit from these general classes.

If the two variables are exactly the same, you can establish a correct inheritance relationship between the class and the class without any difficulty. However, in some cases, they are inconsistent. In this case, inheritance must have an understandable purpose. At least, you should know the purpose of each inheritance relationship in the model.

Iv. Used to support inheritance of Polymorphism

Creating a child type means that a descendant is a child type that can replace all its ancestors under any circumstances. Creating child types is a special and important feature of polymorphism because it allows you to design all customers (using ancestor objects) without considering potential offspring of the ancestor. This makes the customer object more general and can be reused. When a customer uses an actual object, it will work in a specific way and will always find that the object is executing its task. Creating a child type ensures that the system allows changes to the child type set.

Example

In the Warehouse Management System, the Transporter interface class defines basic transportation functions using all types of transport equipment (such as cranes and trucks. This class also defines the executetransport operation.

Both the truck Interface Class and the crane interface class inherit from the Transporter interface. Therefore, the objects of these two classes will respond to the Message executetransport. These objects can replace the Transporter interface at any time and provide all its actions. Therefore, other objects (customer objects) can send messages to the Transporter interface object without knowing whether the truck interface or crane interface object will respond to the message.

The Transporter interface class can even be abstract. It will never be instantiated. In this case, the Transporter interface can only define the signature of the executetransport operation and implement it by the descendant class.

Some object-oriented languages (such as C ++) use class hierarchies as type hierarchies so that designers must use inheritance to create subtypes in the design model. Other languages such as Smalltalk-80 do not perform type checks during compilation. If the object cannot respond to received messages, they will generate an error message.

In languages that do not perform type checks, it is best to use generalized relationships to indicate child-type relationships. In some cases, you should use the generalized relationship to make the object model andSource codeIt is easier to understand and maintain, regardless of whether the programming language permits this. Whether the inherited usage method is valid depends on the conventions of the programming language.

V. Inheritance used to support implementation Reuse

By creating sub-classes, generalized relationships can be reused. When creating a subclass, consider which parts of the implementation can be reused by inheriting the features defined by other classes. When a specific class is implemented, you can create a subclass to reuse it.CodeTo reduce the workload.

Example

In the Smalltalk-80 class library, class dictionary inherits the characteristics of set.

The reason for this generalized relationship is that dictionary can reuse some general methods and storage policies in the implementation of set. Even if you can treat a dictionary as a set (including a key-Value Pair), it is not a child type of the set, because you cannot add any types of objects to the dictionary (only key-value pairs can be added ). The dictionary object does not realize that it is actually set.

Creating a subclass usually leads to an illogical hierarchy, which is hard to understand and maintain. Therefore, it is best not to use inheritance only for reuse, unless it is recommended for programming language use. Such reuse is usually difficult to maintain. Any change to the class set may mean that all classes of the inherited class set will be greatly changed. Remember this and only inherit from stable classes. Inheritance will actually freeze the implementation of the class set because its changes are too expensive.

Vi. Inheritance in programming languages

How to use generalized relationships in design depends mainly on the semantics and recommended usage of inheritance in programming languages. Object-oriented languages Support inheritance between classes, but not object-oriented languages. You should process language features in the design model. If you are using a language that does not support inheritance or that does not support multiple inheritance, you must simulate inheritance in the implementation. In this case, it is best to model the simulation in the design model, instead of using the generalized relationship to describe the inheritance structure. If we use generalized relationships to create a model of the inheritance structure and simulate inheritance during implementation, the design will be abandoned.

If you are using a language that does not support inheritance or that does not support multiple inheritance, you must simulate inheritance in the implementation. In this case, it is best to model the simulation in the design model, instead of using the generalized relationship to describe the inheritance structure. If the generalized relationship is used to establish the model of the inheritance structure and simulate the inheritance in the implementation, the design will be abandoned.

You may need to change the features of interfaces and other objects during simulation. We recommend that you use one of the following methods to simulate inheritance:

Let future generations forward messages to their ancestors.
Copy the code of the ancestor in each descendant. In this case, no ancestor classes will be created.

Example

In this example, the descendant forwards messages to the ancestor by serving as a link to the associated instance.

Assign the behaviors of CAN, bottle, and crate objects to a special class. An object that has this behavior together sends a message to a stored item object so that this behavior can be executed if necessary.
1987-2001 Rational Software Corporation. Copyright.