Valid tive c ++ notes (35-40), effective35-40

Valid tive c ++ notes (35-40), effective35-40

// --------------------------- 15/04/24 ----------------------------

// #35 consider other options than virtual functions

{

/*

1: We usually design a virtual function for something that has changed, and then inherit it from the subclass and implement it again,

However, this inertial thinking has become a weakness. Because we have never thought of any other implementation method.

2: Use Non-Virtual Interface instead of virtual function.

1> Design the virtual function as private and call it using other public functions. Here is a key point:

Can the private virtual function realize polymorphism? The answer is yes. Redefine it as you like.

2> you can add some control before and after calling the virtual function, such as locking, recording, and so on.

3> In fact, it is not necessarily private. Let's define it by yourself.

3: Use the Strategy Mode:

1> when you need a virtual function, you can consider storing a function-like object and then calling this in a public function.

Imitation function.

2> the internal operation of this function should not depend on the internal details of the class. Otherwise, it would be better to use the virtual function.

3> at this time, you will find that you can dynamically change the function to be called. For example, a function that calculates the blood volume value can be called at the beginning.

In normal versions, when a role is poisoned, a function is used to calculate the blood volume. Wow! Cool.

*/

}

// #36. Do not redefine the inherited non-virtual function

{

/*

Premise: D public inherits from B

Let's first look at the two principles (the previous terms have already been written ):

1> it applies to everything of object B and also to object D, because every object D is-a B.

2> D will inherit the non-virtual function interfaces and implementations of B.

Therefore, if we redefine a non-virtual function:

1> D inherits B in the public mode. If D has a function that needs to be redefined (immutable over-specificity), this function

It should be virtual rather than non-virtual.

2> if this function does not need to be redefined (the specific overmutability), then D does not need to be redefined for a long time, and it also

You should not try this.

So the conclusion is: Do not redefine the inherited non-virtual function.

 

*/

}

// #37 do not redefine the inherited default parameter value

{

// 1: Check the two functions:

Class Shape

{

Public:

Enum ShapeColor {Red, Green, Blue };

Virtual void draw (ShapeColor color = Red) const = 0;

};

Class Rectangle: public Shape

{

Public:

Virtual void draw (ShapeColor color = Green) const;

};

/*

The result is that when the customer uses the base class pointer and subclass object, the called content is subclass, and the default parameter is indeed the base class.

This is meaningless, so the problem is going in two directions:

1> you want to switch the default parameters.

2> you want to retain the default parameters, but switch the call content. If the subclass also uses the same parameter, if the default parameter is changed

The base class and subclass must be changed, so this is very bad.

It is easy to implement:

1> want to switch parameters? Define a non-virtual function and call it using the virtual function,

It is OK to input different parameters during the call.

2> want to switch the call content? Define a private virtual function and call it with a non-virtual function with default parameters.

 

*/

}

// #38 use composite plastic film to produce has-a or "based on something"

{

/*

There are two scenarios of combination:

1> has-

If you shape something in the world, such as people, things, and cars, then such an object belongs to the application domain,

When the combination occurs in the application domain, it shows the relationship of has-.

2> is-implemented-in-terms-of (based on something)

If you create an object to implement detailed manual work, such as a buffer, mutex lock, and so on, such an object belongs to the implementation domain

Such a combination shows the is-implemented-in-terms-of relationship.

The specific example is that when you want to implement a set, you may need to include a std: list in the class, because you do not want

Write the list by yourself. The relationship is-implemented-in-terms-of. This set is implemented based on the list.

There is no need to inherit from this because: set is not a list, and set is not necessarily usable where list can be used. For example, list can be inserted.

Duplicate values, but not set values.

*/

}

// #39 use private inheritance wisely and cautiously

{

/*

1: private inheritance means is-implemented-in-terms-. That is to say, it is similar to the combination. But which one is better?

1> combination prevents virtual functions from being redefined.

2> composite can decouple two classes to reduce compilation dependencies.

3> private inheritance can implement EBO, that is, making an "empty" base class really out of memory.

4> private can access the content of the base class protected.

2: conclusion:

1> first, consider combination.

2> You Can't implement it in combination, or you really need to pay attention to the 4 byte bytes, so replace it with private.

*/

}

// #40 use multiple inheritance wisely and cautiously

{

/*

1: Multi-inheritance often has many disadvantages:

1> it is more complex than a single inheritance, and may cause ambiguity. That is, if the inherited two base classes have functions with the same name, then simply use

The function name does not know which one to call.

2> the base classes are required to be inherited from virtual, but virtual inheritance is used to increase the volume, slow down the speed, and perform complex initialization.

Cost-effective virtual base classes is the most useful if it does not contain any data.

(Ps: No data is included. Isn't virtual inheritance affected? Even if it is not virtual inheritance, there will be no duplicates,

Is a virtual pointer at most)

2: The legitimate use of multiple inheritance: the adapter mode in the Design Mode

However, this can also be changed to a composite method, so you need to be wise and careful to decide whether to apply Multi-inheritance (ps: not recommended)

*/

}