Композиция и круговая зависимость - PullRequest
1 голос
/ 08 декабря 2011
  • A Канал содержит элементов типа 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 не может предоставить себя shared_ptr для порта ImpL во время построения (потому что он еще не завершен)
  • Если оба используют сильные ссылки, они никогда не будут освобождены
  • Некоторый пользовательский код может захотеть сохранить указатель порта для последующего использования ... Так что в это время канал еще должен существовать!

Разрыв круга с помощью weak_ptr может привести к преждевременному разрушению канала!

Какой шаблон лучше всего использовать, не объединяя два интерфейса ??

EDIT: @ Эдвин Да, я уже проверил существующие обсуждения ... Ответ, который я ищу, более этичный, чем технический ...

В сущности, каковы преимущества композиции в таком языке, как C ++, в котором отсутствует управление памятью и удобство использования «this» во время создания, когда скомпонованному объекту требуется доступ к компоновщику?

Я нахожусь в идее, что уникальное решение состоит в том, чтобы реализовать композитор и (в частном порядке) все интерфейсы компонентов в одном классе (чтобы решить проблему связи компонента с композитором). И, может быть, предоставим конкретные представления об этом уникальном классе, чтобы выглядело как отношение «есть» в отношении «есть»: Но при таком сценарии все достоинства композиции теряются!

1 Ответ

1 голос
/ 08 декабря 2011

Вопрос слишком абстрактный и отделен от приложения. Что произойдет, когда ваш материал в канале изменится, кто отвечает за распространение через порт? Будет ли приложение лучше обслуживаться потоковым протоколом, а не объектно-ориентированным API? Сколько каналов и сколько будет прослушивателей портов?

...