從RPC開始（二）、序列化_ZenDei技術網路在線

在C++的世界里構建一個序列化框架；並非一件困難的事情，但也並非簡單。因此，需要分成兩部分來完成這項任務： 1、序列化容器。 2、序列化方式。前者，很容易理解；但也決定著我們將要存儲數據的方式：二進位抑或其他。二進位方式，很容易想到和使用的方式；但也最容易以極不安全的方式去使用；因為，為了各種原因 ...

在C++的世界里構建一個序列化框架；並非一件困難的事情，但也並非簡單。因此，需要分成兩部分來完成這項任務：

1、序列化容器。

2、序列化方式。

　　前者，很容易理解；但也決定著我們將要存儲數據的方式：二進位抑或其他。二進位方式，很容易想到和使用的方式；但也最容易以極不安全的方式去使用；因為，為了各種原因，在存儲時我們極易丟掉原本的類型信息，使得一切都靠“人工約定”這種很不靠譜的方式。而其他方式，如文本，我們則可以相對地在其中保留很多信息；即使最後的成品並非是讓人類來閱讀的，但構建過程中，為了各種目的（如調試），總會加入各種信息的。

　　後者，則決定了該框架的可用性以及健壯性；在此有兩種方式可選擇：介面和全局重載函數。第一個，是完全面向對象的方式，也是以侵入式地決定了一個類型是否可以被序列化；看似完美，但對於已完善的不可更改的類型，是有著致命性的不足：無法被我們的框架所包容（例如基本類型）！第二個，使用類似“operator<<”的cout方案；可以擴展式地支持所有類型，但，是的有“但是”，其在一定程度上破壞了“封裝”，C++友元函數便是這一爭論的中心。當然，這無關緊要。

一、容器

　　第一步，自然我們需要選擇是使用固定的一個完善的類來完成這項工作；還是，使用相對可擴展的介面定義。前者，在我們的RPC中是很理想的方式：我們只需要二進位。而後者，則關係到整個序列化框架本身的可復用性——如果，我們想要支撐永久化對象（即：保存到文件和從文件恢復）呢？

　　所以，對此，只能使用介面：

class IBuffer{//沒有寫所必要的virtual ~IBufer(){}
public:
    virtual void write(const byte* buffer, size_type length) = 0;
    virtual bool read(byte* buffer, size_type length) = 0;
public:
    virtual size_type length()const = 0;
    virtual const byte* data()const{ return nullptr;}
};

　　以上便是我們所需要的最基本的介面了。基本上和一個文件所提供的功能一致；需要說明的是“data()”函數，其既不是純虛的，其也有一個不怎麼安全的預設返回值：nullptr。很簡單：其是為了相容MemoryBuffer和FileBuffer而設定的！在MemoryBuffer的實現中我們需要重寫該函數以傳遞二進位序列化後的結果；而FileBuffer則無視這一介面。而且，預設返回一個"nulllptr"也只有一個作用：該函數會返回【空指針】，請註意！

　　當然，這並非盡頭；在使用該介面時，我們將會十分的難受！因為，沒有可設置的偏移量介面；是的，我們需要偏移量，當需要完成更複雜的操作時。比如，我們拋個異常：

    ....
    buffer->read(...);
    throw XXX;

　　作為一個健壯的系統，我們需要支持一定程度的【異常安全】：在異常拋出後，我們捕獲它，並重置偏移量，然後繼續拋出。最經典的場景是：在反序列化的某處，檢測到類型不匹配或緩衝區不足，我們需要拋出異常，而非錯誤地繼續走下去。這是第二部分“序列化方式”的關鍵之一。

　　因此，我們需要如下新的介面：

class IBuffer{//依然沒有必要的virtual ~IBuffer(){}
public:
    virtual void write(const byte* buffer, size_type length) = 0;
    virtual bool read(byte* buffer, size_type length) = 0;
    virtual void clear() = 0;//刺眼8
    virtual void reset() = 0;//刺眼9
public:
    virtual size_type length()const = 0;
    virtual size_type bufferSize()const = 0;//刺眼1
    virtual const byte* data()const{ return nullptr;}
    virtual const byte* buffer()const{ return nullptr;}//刺眼2
public:
    virtual size_type tellRead()const = 0;
    virtual size_type tellWrite()const = 0;
    virtual size_type seekRead(size_type offset) = 0;
    virtual size_type seekWrite(size_type offset) = 0;
    virtual size_type setLength(size_type length) = 0;//刺眼3
public:
    virtual bool addBuffer(IBuffer* buffer, size_type offset) = 0;//刺眼4
    virtual void reserve(size_type length) = 0;//刺眼5
public:
    virtual void serialize(IBuffer* buffer)const = 0;//刺眼6
    virtual bool deserialize(IBuffer* buffer) = 0;//刺眼7
};

　　上面突然間有了很多刺眼的新介面；因為，我不想浪費篇幅，打算一次性講完。上面的“tell/seek”系列4個介面，便是新增的偏移量支持，自然不需多說。

　　那些“刺眼”系列介面，一定程度上是其作為容器的證明；clear()用來重置整個容器，包括刪除所有使用到的記憶體或硬碟資源；reset()只是簡單地重置讀寫偏移量以復用容器；setLength()/reserve則對應了STL中的resize和reserve；addBuffer()是為了支持直接地從不同的Buffer中寫入內容（如MemoryBuffer與FileBuffer的互操作，以不借用第三方資源的方式）。

　　bufferSize()與buffer()，需要特殊解釋一下；在TCP發送時，我們需要一個頭來存放整個消息的大小，否則我們需要發送2次(第一次為消息大小，第二次為消息本身)。所以，為了支持能夠獲得一個自身帶有大小的緩衝區，我們需要這樣的介面支持：buffer()返回包含內容大小為頭的緩衝區；bufferSize()獲得含頭的緩衝區大小。

　　在以上介面的支持下，我們便能夠完成所需要的所有事情了；當然，你需要實現它們。

二、方式

　　面向對象語言(編譯型)，都有一個問題：值類型和引用類型的隔閡。同樣在C++中也有類似的問題：基本類型和自定義類。前者，我們無法做任何的改變；但他們和後者有著巨大的距離：沒有成員函數。意味著，我們只能夠以函數重載的方式去相容二者：

void Serialize(IBuffer* buffer, int);//基本類型1

void Serialize(IBuffer* buffer, double);//基本類型2

void Serialize(IBuffer* buffer, const Something&);//自定義類型1

　　作為一個現代的C++人士，我們不能夠容忍這樣的“無聊”；因為我們可以進行類型萃取：

　　1、如果為基本類型，我們直接保存其二進位值；

　　2、如果其為自定義類，且有成員函數“serialize/deserialize”，我們通過調用該配套函數進行序列化和反序列化；

　　3、如果其為自定義類，且是POD，同樣直接保存其二進位值；

　　4、以上的其他情況，編譯器會直接報錯。

　　以上方案，可以通過C++11完成。至於方式，其涉及模板元編程；我並不詳細描述，大致通過以下方式完成：

　　1、使用TypeList定義基本類型的類型列表（當然可以逐個特化，但這樣失去了味道），以判斷是否為基本類型；

　　2、使用C++11的decltype判斷是否有“serialize/deserialize”成員函數；

　　3、在類型信息中查找該類型是否為POD且不為指針。

　　然後，使用元編程將以上3個信息融合得到最佳的選擇。詳細的，可以參考未來的某天，我將要講的《基於C++11的類型系統》。或者，可以依次搜索：泛型編程與設計模式之應用(TypeList)、C++SFINAE(關鍵技術decltype)、STL的type_traits。

　　有一個關鍵的地方不得不提：不為指針。是的，我沒有支持指針的序列化；因為，我們並不能夠知道一個指針是一個元素還是一個數組。當然，我們可以支持shared_ptr和vector，以更健壯的方式。

　　總結一下，在你學完所有以上提到的及術後，我們便能夠創建出以下序列化方式：

　　1、基本類型和自定義POD調用以下方式：

template<typename T>
void _Serialize(IBuffer* buffer, const T& val)
{
    buffer->write((const byte*)&val, sizeof(T));
}

template<typename T>
bool _Deserialize(IBuffer* buffer, T& val)
{
    return buffer->read((byte*)&val, sizeof(T));
}

　　2、自定義類型且有配套函數：

template<typename T>
void _Serialize(IBuffer* buffer, const T& val)
{
    val.serialize(buffer);
}

template<typename T>
bool _Deserialize(IBuffer* buffer, T& val)
{
    return val.deserialize(buffer);
}

　　還有一個問題就是，對於已完善的不可更改類的處理：很簡單和自然，重載以上_Serialize/_Deserialize函數；比如STL中的std::string就需要如此處理。

　　還有一個不可忽視的問題：健壯性！也就是，我們需要感知類型，我們需要類型信息。很自然的方式，我們在序列化時寫入類型信息；在反序列化首先獲取該信息，並判斷是否類型匹配。

　　可用的方式是：寫入類型ID；通常來說是一個字元串。但，問題的關鍵是誰來生成並提供這個字元串？

　　自然，依然使用C++的方式：模板特化

template<>
struct TypeInfo<Something>{
    static std::string Name(){ return "Something";}
};

　　這種方式，很繁瑣，意味著：對於每一個需要序列化的類型，我們都需要特化一個模板！但，這是必不可少的，因為我們沒有完整的運行時類型系統，我們可以操作類型的唯一機會，只在編譯期。不要抱怨，每個類，也只需要一次而已，代價並不高。

　　完了。？沒有，這個“判斷過程”由誰來做？絕不是手動進行。到這裡，我們需要引入一個“代理”：Any，可變類型。也就是，其可以包裝所有類型；然後通過模板函數來獲取值：

template<typename T>
void Any::from(const T& val);

template<typename T>
T& Any::to();

template<typename T>
const T& Any::to()const;

　　在序列化時，我們需要首先將類型包裝到Any中，然後通過Any執行序列化；在另一端，我們將Buffer交給Any然後再調用to<T>()時反序列化；這時，我們就有一個中間層幫我們完成類型信息的寫入和匹配：

void _AnyData::serialize(IBuffer* buffer)
{
    Serialize(buffer, TypeInfo<T>::Name());
    Serialize(buffer, mData);
}

bool _AnyData::deserialize(IBuffer* buffer)
{
    std::string name;
    if(!Deserialize(buffer, name)){
        return false;
    }
 　 if(name != TypeInfo<T>::Name()){
　　　　return false;
　　}
   Deserialize(buffer, mData);
　　return true;
}

　　當然，以上僅僅是示例並非可用的代碼；但，也差不多了。這樣，我們便能夠完成序列化和反序列化的完整操作，並且在安全的環境下。當然需要說明一下所謂的安全：是指我們能夠感知錯誤的反序列化，並有機會進行相應的處理。Deserialize返回布爾值，便是作為一個通知（我並沒有選擇拋出異常）。

　　以上，便是序列化框架的所有了；當然，並沒有列出所有的內容；但也，足夠說明，C++能夠以我的方式構造出一個相對安全且可用的序列化。

　　PS：很多東西，我並沒有展開；有機會的話，可以等開源我的代碼；但很渺茫。