组成及循环依赖

甲通道包含元素类型的 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

组成及循环依赖

回答

相关问题