選擇corect導出基於ID值基於類

我在C++類名爲InformationElement它定義瞭如下的信息單元的幀結構：選擇corect導出基於ID值基於類

< - 元素ID-> < - 元素長度 - > < -Variable淨荷 - >

元素ID是1字節。
元素長度是1個字節長。它定義了有效載荷部分的長度。
該類包含用於對內容進行序列化和反序列化的虛擬函數+定義ElementID的類型。

從這類不同派生類繼承例如：

類能力
類操作。
class TimingParameters。

每個派生類都有唯一的元素ID和不同的有效負載。

不同的信息元素（IEs）將被封裝在一個更大的框架中。這個更大的框架包含了封裝在其中的信息元素的數量。

< IEs-的-Number> < --IE 1 - > < - IE 2 - > < - IE 3 - > ......

從發射機點查看序列化這些信息沒有問題。然而，在接收端，接收端必須提取Element ID，並根據該值，接收端選擇正確的派生類來處理淨荷部分，即處理反序列化操作。在接收端這樣的傳統方法是建立一個大的開關情況如下：

InformationElement *element; 
switch (elementID) 
{ 
    case 1: 
    element = new Capabilties; 
    case 2: 
    element = new Operation; 
    case 3: 
    element = new TimingParameters; 
}

但是，如果我有100個元素，這將是太多與比較，也不會擴大該許多。

所以我的問題是有沒有什麼聰明的方式來做到這一點在c + +比爲每個獨立的元素ID插入一個獨特的情況？

來源

2015-08-14 IoT

有什麼不對switch語句？我更喜歡我認爲的任何其他解決方案。 – Barry

您需要表達每個標識符與相應類型*之間的關聯*。每種類型的解決方案是否需要一些關聯以適合您的賬單？ – Quentin

@Quentin，你有什麼建議？ – IoT

我建議使用一個工廠。請參閱Boost.Functional/Factory以獲得合理的實施。

如果你不想使用升壓，Factory，從維基教科書，顯示了一個簡化的C++實現，可以幫助你開始。

從維基討論的一個大的遺漏是缺乏半自動註冊，這是在這個博客帖子Factory Design Pattern in C++和CodeProject上A C++ Object Factory和Factory Pattern in C++兩篇文章中討論的。

當然，還有一個SO回答這個太： Is there a way to instantiate objects from a string holding their class name?

來源

2015-08-14 14:42:37 Phil

我不想使用任何外部庫。有沒有可能做到這一點，而不使用Boost？ – IoT

這是一個無法回答的問題。您需要首先確定類型以獲取工廠對象。我的代碼片段中的lambda表達式實現了工廠模式，但它們不會讓它看起來像一個大問題。鏈接的問答通過將交換機放在課堂中來解決問題。 – Potatoswatter

取switch - case並用相同的東西代替它。例如，

typedef InformationElement * (*ElementCreatorFunction)(); 
std::map< ElementEnum, ElementCreatorFunction > ElementCreatorMap { 
    { 1, []() -> InformationElement * { return new Capabilities; } }, 
    { 2, []() -> InformationElement * { return new Operation; } }, 
    { 3, []() -> InformationElement * { return new TimingParameters; } } 
}; 

InformationElement * element = ElementCreatorMap[ elementID ]();

這允許運行時自定義和模塊化。「案例」的主體可以在不同的源文件或動態加載的模塊中。

一個較小的變化是用類似但更安全的替代容易出錯的語句switch-case。我的safe_switch library提供了CASE而不需要break;，這在您的示例中已被遺忘。

順便說一句，它看起來像std::unique_ptr<InformationElement>可能比InformationElement *更合適。

來源

2015-08-14 14:32:24 Potatoswatter

在我的解決方案中，我再次回到相同的問題，不得不添加每個新的信息元素。那麼爲什麼你提出這個解決方案呢？在比較速度和選擇正確派生類別方面是否有任何不同 – IoT

這看起來像是一個非常非常奇特的「開關」給我。 – Quentin

@IoT你提到了可伸縮性。此解決方案更容易擴展 - 請參閱編輯。至於性能方面，'switch'聲明可能是無與倫比的，但你沒有提到問題中的性能。 – Potatoswatter

選擇corect導出基於ID值基於類

回答

相關問題