組成及循環依賴

甲通道包含元素類型的 E.
通道還具有一個端口，讓進入元件在溝道

template< 
    typename E> 
class IOutPort{ 
public: 

    ... 

    /** 
    * Takes an element (chosen by the implementation) that is in channel 
    * 
    * @return 
    *  The element 
    */ 
    virtual E take() = 0; 
}; 

template< 
    typename E> 
class IChannel { 
public: 

    ... 

    /** 
    * Gives access to the out port of this channel 
    * 
    * @return 
    *  A smart pointer to the channel's port 
    */ 
    virtual std::shared_ptr<IOutPort<E>> getOutPort() = 0; 
};

他們都需要引用自己..
另外：

通道IMPL不能在施工時間端口IMPL提供自身的shared_ptr的（因爲它尚未完成）
如果兩者都使用強引用，它們將永遠不會被釋放
某些用戶代碼可能希望存儲端口的指針供以後使用......所以當時該通道必須仍然存在！

用weak_ptr打破圓圈可能會導致頻道的過早破壞！

哪個是最好的模式，沒有合併兩個接口？

編輯： @Edwin是的，我已經檢查現有的討論... 我要找的答案是比技術更合乎道德的...

實質上，它們是組成優勢在像C++這樣的語言中，當構造對象需要訪問作曲者時，缺乏內存管理和'this'的可用性？

我認爲獨特的解決方案是在同一個類中實現作曲者和（私下）所有組件接口（以解決組件到作曲者通信問題）。也許提供這個獨特的同一類的具體意見，使看起來'是一個'關係在'有'的關係... 但在這種情況下，所有的組成優勢都失去了！

來源

2011-12-07 MrAduer

我不知道你是否注意到了，但是右邊的邊欄中提到的很多話題聽起來與你所問的非常相似。在發佈問題之前，您是否先檢查出它們？ – Edwin

該問題太抽象，與應用程序分離。當頻道中的內容發生變化時，會發生什麼情況？誰負責通過端口傳播？通過流協議而不是面向對象的API可以更好地服務應用程序嗎？多少個頻道與多少個端口聽衆會有多少？

來源

2011-12-07 23:56:01

它在併發環境中運行。當代理準備好處理一個元素時，它會從端口調用'take'。其他人可能會做同樣的事情......但是一次只能從端口中取出一個元素，因此實現和調度程序策略有助於某種形式的序列化。 '渠道'抽象服務器隱藏元素插入語義的目的：它可能是一個約束大小的隊列，一個優先級隊列（每個插入必須攜帶有關優先級的信息......），插入器和等待接受者之間的randezvou等等。 – MrAduer

組成及循環依賴

回答

相關問題