Experience the technology of separating interfaces from implementations in C ++

When using C ++ to write a library for the class to be exported, we often only want to expose the interface and hide the implementation details of the class. That is to say, the header file we provide only the declaration of the Public member function to be exposed, and all other information of the class will not be displayed in this header file. In this case, the technology of separating interfaces from implementations is required.

The following is a simple example.

Class ClxExp is the class to be exported. One private member variable is the object of the ClxTest class. The content of each file is as follows:

LxTest. h file content:

Class ClxTest { Public: ClxTest (); Virtual ~ ClxTest (); Void DoSomething (); };

LxTest. cpp file content:

# Include "lxTest. h" # Include <iostream> Using namespace std; ClxTest: ClxTest () {} ClxTest ::~ ClxTest () {} Void ClxTest: DoSomething () { Cout <"Do something in class ClxTest! "<Endl; } //////////////////////////////////////// ////////////////////////////////////

LxExp. h file content:

# Include "lxTest. h" Class ClxExp { Public: ClxExp (); Virtual ~ ClxExp (); Void DoSomething (); Private: ClxTest m_lxTest; Void lxTest (); };

LxExp. cpp file content:

# Include "lxExp. h" ClxExp: ClxExp () {} ClxExp ::~ ClxExp () {} // In fact, this method is not necessary here. I just want to explain the call relationship. Void ClxExp: lxTest () { M_lxTest.DoSomething (); } Void ClxExp: DoSomething ()

To enable users to use our class ClxExp, we must provide lxExp. h file, so that private members of the class ClxExp are also exposed to users. In addition, it is not enough to provide lxExp. H files, because lxExp. H files include lxTest. H files. In this case, we also provide lxTest. H files. In this way, the Implementation Details of the ClxExp class will be fully exposed to users. In addition, when we modify the ClxTest class (such as adding or deleting some member variables or methods), we also need to update lxTest for users. h file, which is irrelevant to the interface. If the ClxExp class contains many objects like m_lxTest, we will provide you with N objects like lxTest. h. If any class has been changed, we must update the header file for the user. Another point is that the user must re-compile in this case!

The above is a very small example. The time for re-compilation is negligible. However, if the ClxExp class is widely used by users, we will have time to have a cup of coffee or something during recompilation in a large project. Of course, the above situations are not what we want to see! You can also imagine what they will scold when users constantly update header files and compile their programs without changing them. In fact, for users, they only care about the DoSomething () method of the ClxExp-class interface. So how can we expose only the ClxExp-like DoSomething () method without the problems mentioned above? The answer is the separation of interfaces and implementations. I can let the class ClxExp define the interface and put the implementation in another class. The specific method is as follows:

First, add an implementation class ClxImplement to implement all ClxExp functions. Note: The class ClxImplement has the same public member functions as the class ClxExp, because their interfaces must be completely consistent.

LxImplement. h file content:

# Include "lxTest. h" Class ClxImplement { Public: ClxImplement (); Virtual ~ ClxImplement (); Void DoSomething (); 　 Private: ClxTest m_lxTest; Void lxTest (); };

LxImplement. cpp file content:

# Include "lxImplement. h" ClxImplement: ClxImplement () {} ClxImplement ::~ ClxImplement () {} Void ClxImplement: lxTest () Void ClxImplement: DoSomething ()

Then, modify the ClxExp class.

The modified lxExp. h file content:

// Pre-declaration Class ClxImplement; Class ClxExp { Public: ClxExp (); Virtual ~ ClxExp (); Void DoSomething (); Private: // Declare the ClxImplement pointer of a class and do not need to know the definition of the class ClxImplement ClxImplement * m_pImpl; };

The content of the modified lxExp. cpp file:

// Contains the definition header file of the ClxImplement class. # Include "lxImplement. h" ClxExp: ClxExp () { M_pImpl = new ClxImplement; } ClxExp ::~ ClxExp () { Delete m_pImpl; } Void ClxExp: DoSomething ()

Through the above method, the ClxExp-like interface and implementation are separated. Note the annotations in the two files. The ClxExp class declares only interfaces, and the real implementation details are hidden in the ClxImplement class. In order to use the class ClxImplement in the class ClxExp without including the header file lxImplement. h, the class ClxImplement must be predeclared, and only the pointer pointing to the class ClxImplement object can be used; otherwise, the compilation fails.

When releasing a library file, we only need to provide the user with a header file lxExp. h, without exposing any implementation details of the class ClxExp. In addition, we do not need to update the header file for any changes to the ClxTest class (of course, the library file is to be updated, but in this case, the user does not need to re-compile it !). Another advantage is that the system analyst or Senior Programmer can define the class interface first in the analysis phase, or even write the interface code (for example, lxExp after the above modification. h file and lxExp. (cpp file), and the specific implementation of the class is handed over to other programmers for development.

From

Http://www.builder.com.cn/2007/1027/584831.shtml