Object Relationship analysis (non-inheritance relationship)

There are various object relationships in the real environment, and special relationship type descriptors can be used to describe these relationships.

For example:

1. The square is a form of shape, you can use "is-a" to describe the relationship between the square and the shape.

2. The car has a steering wheel and can use "has-a" to describe the relationship between the car and the steering wheel.

3. Programmers use the keyboard to edit code, you can use "uses-a" to describe the relationship between the programmer and the keyboard.

4. Flowers rely on bees to spread pollen, and "depends-on" can be used to describe the relationship between flowers and bees.

5. The student is a member of a class and can use "member-of" to describe the relationship between the student and the class.

6. Limbs are part of the body and can use "part-of" to describe the relationship between the body and the body.

Using C + + for object-oriented programming is a great help in writing high-quality code if you can understand the relationship between objects accurately.

Several typical object relationships (non-inheritance) are listed below:

I. Object composition Relationship

Object composition is easy to understand, such as a car is made up of wheels, frames, engines and other equipment, the computer is the display, chassis, CPU, etc.

Equipment. These relationships are called combinatorial relationships (composition), and in this case the vehicle-to-wheel relationship is inclusive ("Has-a").

In C + +, object composition simplifies the operation of complex classes by transforming complex classes into a combination of multiple simple classes.

Object combinations also contain two forms: one is a combination and the other is an aggregation.

1. Composition Relationship:

There are several prerequisites for satisfying a composition relationship:

A. Members must be part of a class;

B. Members can only belong to one class at a time;

C. A member must exist in a class;

D. Members do not have to know that they are contained within a class.

The relationship of a combination is like the relationship between the human body and the heart, part must be contained in the whole, the whole must consist of parts, a moment the heart

Must belong to some human body, and not belong to other human body. The composition relationship emphasizes that the integrity of the object must be guaranteed by the member and that the member is one-way

Guaranteed that the object must contain members, and that the member does not necessarily exist on this object.

Class POINT2D

{

Private

int m_x;

int m_y;

...

Public

...

}

The relationship between m_x, M_y and Class point2d is composed.

2. Aggregation relationship

Meeting the aggregation relationship consists of the following elements:

A. Members must be part of a class;

B. Members may belong to more than one class at a time;

C. The membership does not necessarily exist in the class;

D. Members do not have to know that they are contained within a class.

As with combinatorial relationships, the aggregation relationship is part of the overall relationship, but unlike the combined relationship, members can belong to multiple objects at the same time.

When an aggregation relationship object is created or destroyed, the aggregation member is not responsible for creating the part of the object, nor for eliminating the part of the object. It's like a man and a home address.

Relationship, everyone has an address, but this address can belong to multiple people (parents and brothers). The person does not manage the address, in fact, before the people live there,

It may already exist. In addition, people usually know the name of their address, but the address does not know who lives there. The relationship between people and addresses is the aggregation relationship.

When modeling an aggregation relationship, the overall object is not responsible for destroying the aggregated members when the object is being refactored.

Class implementations that contain aggregation relationships are basically the same as the composite relationships, because they are all part of the relationship.

In a composite relationship, a member variable is usually a normal variable, and if it is a pointer, the combined class must be responsible for allocating and releasing the space that the pointer points to.

In an aggregation relationship, a member variable is usually a reference or a pointer, and the member variable refers to an object that is outside the scope of the class. Therefore, when an object is

When destroyed, the aggregate relationship member variable reference or pointer is destroyed, but the referenced or pointed object still exists.

The following example, teacher and teacher name is a combination of the relationship, the teacher must have a name, teacher and name coexist, teacher class objects destroyed, teacher name also destroyed.

The relationship between teachers and departments is the aggregation of the relationship, the department can have many other teachers, teachers can also belong to other departments, the department destroyed, the teachers still exist.

#include <string>classteacher{Private: std::stringM_name; Public: Teacher (std::stringname): M_name (name) {} std::stringGetName () {returnm_name;}}; classdepartment{Private: Teacher*m_teacher;//This dept holds only one teacher for simplicity, but it could hold many teachers  Public: Department (Teacher*teacher=NULL): M_teacher (Teacher) {}}; intMain () {//Create A teacher outside the scope of the DepartmentTeacher *teacher =NewTeacher ("Bob");//Create a teacher    {        //Create A department and use the constructor parameter to pass//The teacher to it.Department Dept (teacher); } //Dept goes out of the scope here and is destroyed//Teacher still exists here because dept do not delete M_teacherStd::cout<< Teacher->getname () <<"still exists!"; Deleteteacher; return 0;}

Object Relationship analysis (non-inheritance relationship)