C++超详细讲解隐藏私有属性和方法的两种实现方式

在我们编写程序的时候，会将程序模块化，常见的就是用动态链接库的方式，然后导出函数接口或者类。而对于导出类的方式，作为模块的实现者，不论是给第三方使用或者自己的项目使用，应该都不太愿意暴露自己的私有属性和方法，个人碰到的主要有以下两个常见原因：

• 通过隐藏私有属性和方法，让被调用者猜不到其实现方式
• 私有方法中或者属性中，可能会存在一些第三方的头文件或者库的依赖，而对于被调用方来说不应该直接依赖

本文将介绍两种方式来满足以上的需求，一种是抽象类，另一种是pimpl风格. 在找到解决方法的时候，你会发现这样的方式不仅仅满足了原先的需求，还买一赠一地带来了其他的优点。

例子

假设我们有一个DataAcquirer封装为一个动态链接库，用来获取数据的：那么以下代码有几个问题:

• 其只需要暴露GetData这个方法给调用方，但是文件中还包含了头文件HttpClient.h 这个是调用方其实并不需要关心的，这就导致调用方还需要配置头文件的目录，有时候甚至还要配置这个间接依赖的库。那么就给调用方带来了不必要的依赖。
• 有时候想要隐藏类的内部实现细节，但这里通过HttpClient m_pHttpClient私有属性和HttpResponseCode HttpDataGet()私有方法，那么调用方就可能猜到这个数据其实是通过http协议来获取的。

#include <string>
#include "HttpClient.h"
#ifdef DATA_ACQUIRER_DLL_EXPORT
#define DATA_ACQUIRER_DECL __declspec(dllexport)
#else
#define DATA_ACQUIRER_DECL __declspec(dllimport)
#endif
class DATA_ACQUIRER_DECL DataAcquirer
{
public:
	DataAcquirer();
	~DataAcquirer();
public:
	const std::string GetData();
private:
	HttpResponseCode HttpDataGet();
	HttpClient m_pHttpClient;
};

用抽象类解决问题

如果你知道依赖倒置原则(Dependence Inversion Principle, DIP), 那应该知道，提供给调用方的时候高层模块依赖其抽象。 在软件编写的时候，抽象是必不可少的，他可以降低我们依赖，也能够让我们更加清晰的定义更友好的接口。这个样例中，我们只需要提供GetData的方法/接口，那我们面向接口的设计如下面类图所示:

解释下上述的类图：

• 调用者client操作的是DataAcquirerAbstract作为抽象类，利用多态实际的对象指向的是DataAcquirer
• DataAcquirer通过工厂方法DataAcquirerFactory进行生产

DataAcquirerAbstract.h的内容如下, 声明抽象类:

#pragma once
#include <string>
class DataAcquirerAbstract
{
public:
	virtual const std::string GetData() = 0;
};

DataAcquirer.h的内容如下, 声明DataAcquirer :

#pragma once
#include <string>
#include "HttpClient.h"
#include "DataAcquirerAbstract.h"
class DataAcquirer : public DataAcquirerAbstract
{
public:
	DataAcquirer();
	~DataAcquirer();
public:
	virtual const std::string GetData();
private:
	HttpResponseCode HttpDataGet();
	HttpClient m_pHttpClient;
};

工厂方法部分用于生产DataAcquirer，下面是DataAcquirerFactory .h文件:

#pragma once
#include <memory>
#include "Factory.h"
#include "DataAcquirerAbstract.h"
#ifdef DATA_ACQUIRER_DLL_EXPORT
#define DATA_ACQUIRER_DECL __declspec(dllexport)
#else
#define DATA_ACQUIRER_DECL __declspec(dllimport)
#endif
class DATA_ACQUIRER_DECL DataAcquirerFactory : public Factory
{
public:
	virtual std::unique_ptr<DataAcquirerAbstract> CreateDataAcquirer();
};

最后调用者只需要引用DataAcquirerAbstract和DataAcquirerFactory ，如下所示， DataAcquirer对于调用者来说是不可见的。

#include <string>
#include <memory>
#include "DataAcquirerAbstract.h"
#include "DataAcquirerFactory.h"
int main()
{
	std::unique_ptr<Factory> factory = std::make_unique<DataAcquirerFactory>();
	std::unique_ptr<DataAcquirerAbstract> pObj = factory->CreateDataAcquirer();
	std::string strData = pObj->GetData();
	//...	Do something else
	return 0;
}

用Pimpl风格解决问题

Pimpl实际的解决方法也比较简单，将Private/Protected属性和方法放到另一个类中，这个类只需要进行声明，然后通过成员指针的方式，进行属性或者方法的访问。用pimpl改造后的类图如下:

DataAcquirer只给调用者暴露了GetData()方法和m_pImpl未知细节的指针，而这个未知细节的指针，在cpp文件中将含有一些私有的方法和属性，也提供一个相应的GetData()的public方法。

DataAcquirer.h文件实现如下:

#pragma once
#include <string>
#include "HttpClient.h"
#ifdef DATA_ACQUIRER_DLL_EXPORT
#define DATA_ACQUIRER_DECL __declspec(dllexport)
#else
#define DATA_ACQUIRER_DECL __declspec(dllimport)
#endif
class DATA_ACQUIRER_DECL DataAcquirer
{
public:
	DataAcquirer();
	~DataAcquirer();
public:
	const std::string GetData();
private:
	class DataAcquirerImpl;
	std::unique_ptr<DataAcquirerImpl> m_pImpl;
};

DataAcquirerImpl的具体实现放在DataAcquirer.cpp中:

#include "DataAcquirer.h"
class DataAcquirer::DataAcquirerImpl
{
public:
	DataAcquirerImpl() {};
	const std::string GetData() { return ""; };
private:
	HttpResponseCode HttpDataGet() { return m_pHttpClient.Get(); };
	HttpClient m_pHttpClient;
};
DataAcquirer::DataAcquirer() : m_pImpl(new DataAcquirerImpl())
{
}
DataAcquirer::~DataAcquirer()
{
}
const std::string DataAcquirer::GetData()
{
	return m_pImpl->GetData();
}

总结

无论是抽象类的方式还是Pimpl风格都达成了接口与实现的分离，并且降低了编译时候的依赖。

以上所说的两种方式，在从无到有编写代码的时候，可以完整的使用这个模式，可是有时候，你需要去维护已有的代码，在原先的导出类中进行一些修改，想要去降低这些依赖，个人认为用Pimpl此时就更适合去做这种扩展修改了。

参考

抽象类方法和Pimpl均在<<Effective C++>> 条款31中提到，只是本人的实现方式会有小小的区别。

另外参考了微软文档<<Pimpl For Compile-Time Encapsulation (Modern C++)>>

到此这篇关于C++超详细讲解隐藏私有属性和方法的两种实现方式的文章就介绍到这了,更多相关C++隐藏私有属性内容请搜索猪先飞以前的文章或继续浏览下面的相关文章希望大家以后多多支持猪先飞！