- 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» во время создания, когда скомпонованному объекту требуется доступ к компоновщику?
Я нахожусь в идее, что уникальное решение состоит в том, чтобы реализовать композитор и (в частном порядке) все интерфейсы компонентов в одном классе (чтобы решить проблему связи компонента с композитором).
И, может быть, предоставим конкретные представления об этом уникальном классе, чтобы выглядело как отношение «есть» в отношении «есть»:
Но при таком сценарии все достоинства композиции теряются!