条款31:将文件间的编译依赖关系降至最低

前端之家收集整理的这篇文章主要介绍了条款31:将文件间的编译依赖关系降至最低前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

假设修改calss的实现文件,不是修改class接口,只是实现中的private成分。然后你会发现全部编译和重新连接了。这些问题是因为C++没有“将接口从实现中分离”做得足够好。class的定义不只是描述了class接口,还包括实现细节。如下代码

class Person
{
         public:
                   Person(conststring& name,const Date& birth,const Addr& addr);
                   std::stringname() const;
                   std::stringbirth() const;
                   std::stringaddr() const;
         ...
                   private:
                   std::string theName;  //实现细目
                   Date theBirth;       //实现细目
                   Addr theAddr;        //实现细目
};


以上代码无法编译如果没有取得class string,Date,Addr的定义式。这样的定义式通常由#include提供,所以Person类的定义上面很可能有这些东西:
#include <string>
#include ”Date.h”
#include ”Addr.h”

 不幸的是这样使Person定义文件和其含入文件间形成了编译依存关系。如果这些头文件有改变,则含有Person类的文件都必须重新编译,连串编译依存关系会对很多项目造成灾难。
为什么C++坚持将class的实现细则定义于class定义式中?为何不将实现细目分开,如下代码
namespace std  {  class  string;}   //前置声明,但不正确 下述
class  Date;
class  Addr;
class Person
{
         public:
                   Person(conststring& name,const Addr& addr);
                   std::stringname() const;
                   std::stringbirth() const;
                   std::stringaddr() const;
         ...
};


这么做,Person只在修改接口时才重新编译,但存在两个问题、
1、string不是class,只是typedef,定义为basic_string<char>)。所以上面针对string的前置声明并不正确。正确的声明比较 复杂并涉及额外的templates。不应该手工声明标准程序库,应仅仅使用适当的#include完成目的。
2、“前置声明”比较重要也比较困难 是,必须在编译期间知道对象大小。如下:
int main()
{
int x;   //定义一个int
Person p(params);  //定义一个Person
…
}


编译看到int时能知道分配空间的大小,但Person对象有多大?获得大小的唯一办法是询问Class的定义,如果定义式不合法的列出实现细目则编译器不知道分配空间大小。
此问题在java等语言上并不存在。因为定义对象时,编译器只分配一个足够空间的指针,如下:
int main()
{
int x;
Person* p;  //指向Person对象的指针
…
}


这也是合法的C++代码,针对Person我们也可以这么做,将其分为两个类,一个提供接口,另一个负责实现该接口。取名为PersonImpl。即implementation class,定义如下:
#include<string> //标准程序库文件不该被前置声明
#include <memory>  //为引用tr1::shared_ptr
class PersonImpl;
class Date; //Person实现类的前置声明
class Addr;   //…Person接口用到类的前置声明
class Person
{
         public:
                   Person(const string& name,constAddr& addr);
                   std::stringname() const;
                   std::stringbirth() const;
                   std::stringaddr() const;
         ...
private:
std::tr1::shared_ptr<PersonImpl> pImpl;  //指向实现物
};


这样,main class(person)只含一个指针成员指向实现类,这种设计一般被称为pimpl idom,(pointer toimplementation缩写)。这种class类的指针名往往就是pImpl.
这样Person就完全与Date…等实现细目完全分离了,那些类的修改person都不需要重新编译。这些关键在于“声明的依存性”代替“定义的依存性”,这是编译依存最小化的本质。现实中让头文件尽可能自我满足,否则让它与其他文件内的声明式(而非定义式)相依。简单的设计策略:
1、如果用对象引用或指针能够完成任务,就尽量不用对象。可以只用类型声明式就能定义指针或引用,但如果定义对象就需用到该类的定义式。
2、尽量以class声明式替换class定义式。注意,如果声明某个函数用到class时,并不需要该类的定义式,即使是传值方式传递该类型凑数,如下:
class Date;   //类声明式
Date today();  //ok  尽管用不到
void clearAppontment(Date d); //Date定义式


虽然声明时不需用到Date定义,但调用时一定得提前曝光。虽然声明的是用不到的函数,但我们不能保证以后不会使用。如果将“cladd定义式”(通过#include完成)从“函数声明”头文件转移到“含函数调用”的客户文件,便可将“非真正的类型定义”和客户端间编依存性去掉。
3、为声明和定义提供不同的头文件。为了严守上述准则。客户应总是#include一个声明文件(而不是前置声明若干函数),程序库作者也应该提供这两个函数。如上,Date客户如果希望声明today和clearApp..,不应该手工前置声明,而应该#include适当的,内含声明式的头文件,如下:

#include “datefwd.h”//这个头文件声明但未定义Date
Date today(); 
void clearAppontment(Date d); 

 datefwd.h命名方式取自C+标准程序库文件iosfwd,内含iostream各声明式其对应定义分布在若干不同头文件内。包括<sstream>,<streambuf>,<fstream>,<iostream>
 同样,虽然template定义通常位于头文件,但也有内置环境允许定义在非头文件中,这样可以把只含“声明式”的头文件提供给template.<iosfwd>就是这样的文件

 虽然C+也提供关键字export允许template声明和定义位于不同文件,但支持这样的编译器很少

 这Person这样使用pimpl idom的class,往往称为handle class,将所有的函数交给相应实现类并由后者完成相应工作。下面是Person两个成员函数的实现:
#include “Person.h” //正在实现,必须#include其定义式
#include “PersonImpl.h” //同理,否则无法调用其成员函数。两者接口相同
Person::Person(const string& name,const Date&birth,const Addr& addr):
pImpl(new PersonImpl(name,birth,addr));
std::string Person::name() const
{
return pImpl->name();
}


Person以new调用(TK16)调用PersonImpl构造函数,name函数同理。Person变成一个handle class并不会改变它做的,只是改变做事方法
另一个制作handle class办法是令Person变成一个Abstract clas(抽象基类),即Interface class.这种类的目的是详述类的接口、通常只有一个虚析构和一组纯虚函数
一个针对Person而写的接口类应该像是这样的:
class Person
{
public:
virtual ~Person();
virtual std:;string name() const=0;
virtual std::string birthdate() const=0;
….
};


该类应以指针或引用来写程序,因为不可能针对内含纯虚函数的类具现实体。(当然派生类能具现出实体),这样除非接口改变,否则其他客户不需要重新编译。
interface class客户有办法为这种类创建新对象,调用一类特殊函数,和真正具体实例化的派生类构造函数角色一致。这样的函数通常为factory(工厂)函数或虚构造。他们返回指针(更为可取的是智能指针)指向动态分配对象。这样的函数在接口类中被声明为static:
class Person
{
…..
static std::tr1::shared_ptr<Person>  //返回智能指针指向新对象并用指定参数初始化
create(const std::string& name,const Date&birthday,const Addr& addr);
…..
}


客户这样使用:
std::string name;
Date dat;
Addr addr;
std::tr1::shared_ptr<Person>  pp(Person::create(name,dat,addr));
…
pp->name();pp->addr();  //通过Person接口使用对象 pp离开作用域自动删除Tk13


当然抽象类的实现都在虚构造实现文件类完成。假设虚基类有个派生类通过继承而来的虚函数实现:
class realPerson:public Person
{
public:
realPerson(const std::string&name,const Date& birthday,const Addr& addr):theName(name),theBirth(birthday),theAddr(addr);
virtual ~ realPerson() {};
std::string name() const;
std::string birthday() const;
std::string address() const;
private:
std::string theName;
Date theBirth;
Addr theAddr;
}


有了realPerson之后,写出Person::create()就一点不奇怪了
std::tr1::shared_ptr<Person> Person::create(conststd::string& name,const Addr& addr)
{
return 
std::tr1::shared_ptr<Person>(new realPerson(name,birthday,addr));
}


上述示范是接口类的两个最常见机制之一,从接口类继承接口风格并实现接口覆盖的函数。接口类的第二个实现方法是多继承。
比较两者不同:
1、Handle class成员通过实现指针取得对象数据,增加间接性。每个对象内存消耗增加实现指针大小,另外有动态内存额外开销。
2、对于接口类,显然虚函数增多会增加函数表的大小。vptr(virtual tabal pointer)
但是二者脱离inline都 无法作为,TK30解释函数本体为了被inline必须(典型)

需要记住的:
 1、“编译依存最小化”的一般构想是:相依于声明式而不是定义式,基于此的两个手段是handle class和Interface class.
2、程序库头文件应该以“完全且仅有声明式”的形式存在,此做法不论是否涉及template都适用。
原文链接:https://www.f2er.com/javaschema/284932.html

猜你在找的设计模式相关文章