组成和循环依赖

Question

• 通道包含类型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”的可用性的优势是什么？

我的想法是，唯一的解决方案是在同一个类中实现组合器和（私有地）所有组件接口（以解决组件间的通信问题）。 也许可以提供该唯一同一类的特定视图，以使它们在“具有”关系中看起来像“是”关系……但是在这种情况下，所有组合优势都丧失了！

Answer 1

这个问题太抽象了，与应用程序分开了。 当您的频道中的内容发生变化（谁负责通过端口传播）时，会发生什么？ 通过流协议而不是面向对象的API是否可以更好地为应用程序提供服务？ 将有多少个通道与将有多少个端口侦听器？