How to avoid the expansion of classes

The expansion of a class (bloating) refers to the presence of too many members in a class, or even an increase in disorder. Too large a class, will make the complexity of the rapid increase, maintenance will become more difficult. So we need to control the growth of the class. This article summarizes, briefly introduces four kinds of solutions, I deliberately use four, mainly in order to introduce the last way.
(The following will need to avoid the expansion class called the Target class, which is the car class in the class diagram.) )

Friend class

This is the most primitive way of thinking. Member variables are still incremented, and some methods are reduced by the ability of the friend class to access the private members of the class.
The disadvantage of this approach is that it is not realistic to add all callers to the friend class. It's a similar scenario:

Class Car {
......
Friend class Driver;
Friend class Sales;
Friend class passenger;
......
}

Helper Class

If you put the newly added member in a helper class, the target class provides a new method for external use, and the helper implementation is invoked internally. In this way the method still needs to be increased.

And the other method, is also more commonly used. Provide a function in the target class to open the helper class, which can be used directly by the class that needs to use it.

"This helper class can also be a friend of the target class." 】

Visitor mode

Sometimes we just have to use a class of existing methods to implement different algorithms. It can be implemented using the Observer pattern.
The new algorithm needs to be put into vistor instead of the target class. You can also set the visitor as the friend class for the target if necessary.

The biggest difference between this scenario and the helper class is that the client may need different versions of the algorithm implementation and is specified by the client.

Helper Class in bind form

Whether it's a simple helper class or a visitor model, helper and visitor lifecycle management needs to be managed by the target class and the customer class. In addition, helper class cannot differentiate between different classes of methods and member variables (different categories represent different responsibilities, we do not have God Class), and visitor does not apply to the need to increase member variables.
A mechanism similar to binding is provided in chromium. The principle is to encapsulate the data and methods I want to add to a class in different categories, and then bind to the target class as a key with the content that I specify. To use a static method, the previous specified key can be taken to the corresponding class and then manipulated.

This is essentially a helper class implementation, except that the helper completes the access to the relevant data object.
The structure is as follows:

(see Base::supportsuserdata in the Chromium code.) )

The target class can increase the data and methods it holds without altering one line of code.

Reprint Please specify source: Http://blog.csdn.net/horkychen

How to avoid the expansion of classes