C++,python,热爱算法和机器学习
全部博文(1214)
分类: C/C++
2014-08-18 20:07:22
最近在恶补设计模式的知识,GoF的23种设计模式都囫囵吞枣的看了一遍,貌似每一种模式都看懂了。然而到底有没有掌握各种模式呢,遇到实际问题时能否正确处理,还是需要打一个大大的问号。这里就遇到一个实际问题需要用模式来解决,然而我拿到这个问题的时候第一时间想到的却不是用模式,走了不少弯路。
问题如下:拿到了如下接口和库文件。需求是,不想把这个原始的接口暴露给用户,希望将真实的接口做一个简单的隐藏,对这套接口进行一个封装,在客户调用doSmth之前,还能做一些别的事情,诸如做一些额外的初始化。也就是对一个动态库文件和接口进行二次封装。
[root@Shentar /myprogs/cpp/proxy]# cat sysbase.h #ifndef _SYS_BASE_H_ #define _SYS_BASE_H_ class SysBase { public: SysBase(){} ~SysBase(){} virtual void doSmth() = 0; }; #endif [root@Shentar /myprogs/cpp/proxy]# cat interface.h #ifndef _INTER_FACE_H__ #define _INTER_FACE_H__ #include "sysbase.h" class InterFace : public SysBase { public: InterFace(); ~InterFace(); virtual void doSmth(); }; #endif
[root@Shentar /myprogs/cpp/proxy]# l libinterface.so -rwxrwxr-x 1 root root 9563 2013-11-16 13:30 libinterface.so
拿到这个问题,我首先想到的是集成InterFace类,生成一个NewInterFace类,在子类中调用父类的方法,并且在该调用之前实现额外的初始化。于是有了如下代码:
[root@Shentar /myprogs/cpp/proxy]# cat newinterface.h #ifndef _NEW_INTERFACE_H_ #define _NEW_INTERFACE_H_ class InterFace; class NewInterFace : public InterFace { public: NewInterFace() : InterFace(){} ~NewInterFace(){} public: virtual void doSmth(); }; #endif [root@Shentar /myprogs/cpp/proxy]# cat newinterface.cpp #include#include #include "interface.h" #include "newinterface.h" void NewInterFace::doSmth() { printf("do some extra initianize()!\n"); InterFace::doSmth(); }
[root@Shentar /myprogs/cpp/proxy]# cat Makefile all:libinterface libnewinterface libinterface: g++ -fPIC -g -shared -o libinterface.so interface.cpp libnewinterface: g++ -fPIC -g -shared -L./ -linterface -o libnewinterface.so newinterface.cpp
这样成功生成了一个新的头文件和库文件:libnewinterface.h 和libnewinterface.so
预期客户只需要使用我提供的新的头文件和库文件就可以达到调用原来老的doSmth接口呢,同时还增加了额外的初始化,而用户对不能再调用老的接口了。然而事实上,客户在使用的时候还是需要知道interface.h这个接口,因为新的头文件中用到了InterFace类,尽管没有直接包含该头文件。因此,客户仍然可以直接使用interface.h中定义的接口。
显然这样的方式不对。于是只能另找别的方法,想到了在新的库文件中用一个全局指针,提供两个C风格的接口来创建和销毁该对象,再封装一个C风格的doSmth方法,在该方法中调用全局指针的doSmth方法。这样可以比较容易的解决该问题。但是由原来的一个接口变成了3个接口,如果客户只能接受一个接口呢?好好的C++类接口变成了C接口。在要求严格的场景下仍然解决不了问题。
回头一想,总觉的这个问题似曾相识,感觉正是模式能够解决的问题。想起了Adapter模式,但是Adapter强调的是接口转换,上面用的不正是Adapter模式吗,解决的不是特别优雅。再看Proxy模式,代理,这里正好是一个透传的需求啊,也即是保护代理,正是代理模式的应用场景。只需要在新的类中集成一个指向老接口对象的指针,在新的类的构造函数中构造该对象,析构时销毁该对象,这样可以达到目的。并且接口也具有一致性。
最后新的代码如下:
[root@Shentar /myprogs/cpp/proxy]# cat proxyinterface.h #ifndef _PROXY_INTERFACE_H_ #define _PROXY_INTERFACE_H_ #include "sysbase.h" class ProxyInterFace : public SysBase { public: ProxyInterFace(); ~ProxyInterFace(); public: virtual void doSmth(); private: SysBase* pimpl; }; #endif [root@Shentar /myprogs/cpp/proxy]# cat proxyinterface.cpp #include#include #include "interface.h" #include "proxyinterface.h" ProxyInterFace::ProxyInterFace() : SysBase() { pimpl = new InterFace; } ProxyInterFace::~ProxyInterFace() { delete pimpl; pimpl = NULL; } void ProxyInterFace::doSmth() { printf("do some extra initianize()!\n"); pimpl->doSmth(); }
客户端程序:
[root@Shentar /myprogs/cpp/proxy]# cat test.cpp #include "sysbase.h" #include "proxyinterface.h" int main(int argc, char** argv) { SysBase* p = new ProxyInterFace; p->doSmth(); delete p; return 0; } [root@Shentar /myprogs/cpp/proxy]# cat Makefile all:libinterface libnewinterface proxyinterface test libinterface: g++ -fPIC -g -shared -o libinterface.so interface.cpp libnewinterface: g++ -fPIC -g -shared -L./ -linterface -o libnewinterface.so newinterface.cpp proxyinterface: g++ -fPIC -g -shared -L./ -linterface -o libproxyinterface.so proxyinterface.cpp test: g++ -fPIC -g -L./ -linterface -lproxyinterface -o testproc test.cpp [root@Shentar /myprogs/cpp/proxy]# make all g++ -fPIC -g -shared -o libinterface.so interface.cpp g++ -fPIC -g -shared -L./ -linterface -o libnewinterface.so newinterface.cpp g++ -fPIC -g -shared -L./ -linterface -o libproxyinterface.so proxyinterface.cpp g++ -fPIC -g -L./ -linterface -lproxyinterface -o testproc test.cpp [root@Shentar /myprogs/cpp/proxy]# ./testproc do some extra initianize()! InterFace's doSmth is called!