Состав против делегации
Есть ли любое различие в терминах внедрения как, как дизайн состава может отличаться от делегации. Например, кодекс ниже, кажется, делает делегацию, так как пользователь не может получить доступ к составленному объекту (т.е.), не используя b. Следовательно, пользователь должен был бы призвать интерфейсы класса b, и затем «класс b» призывает соответствующие интерфейсы «класса» создание его делегация. Это имеет смысл?
Class A {
friend class B;
private:
A(){}; //dont want user to instantiate this class object since it wont sense without any context. Just like a room with no house.
void PrintStructure(){};
};
Class B{
public:
void PrintStructure(){a.PrintStructure();} //delegate
private:
A a; //composition
};
3 ответа
Термин «композиция» обычно используется с точки зрения моделирования объекта как экспрессия отношений «имеет» и является формой ассоциации (другая агрегация). Это обычно противопоставлено «наследством» («IS-A» отношений). Так что:
В чем разница между составом и агрегацией? Композиция подразумевает, что ребенок не может существовать без контекста родителя.
Например, дом имеет один или несколько комнат. Это состав отношения. Удалить дом и номера также перестают существовать. Дом также имеет ряд пассажиров, будучи случаями человека. Это отношения агрегации, потому что эти люди существуют за пределами контекста этого дома.
Делегация - не что иное, как деталь реализации. У класса есть публичный интерфейс, который описывает его состояние и поведение. Как это реализовано неактуально. Это может делегировать другим объектам или нет.
Вы заметите, что оба A и B из вашего примера имеют тот же внешний интерфейс. Более распространено что-то подобное:
// this represents an interface
class A {
public:
virtual void printStructure() = 0;
}
с бетонными классами:
class ConcreteA : A {
public:
virtual void printStructure() { ... }
}
и
class DelegateA : A {
public:
DelegateA(A& a) { this.a = a; }
virtual void printStructure() { a.printStructure(); }
private:
A a;
}
оправдывают мои вероятные синтаксические ошибки C ++. Я немного ржавый.
Существует пара различий, которые я вижу:
- делегация включает в себя реэкспорт методов; В составных отношениях методы внутренних объектов могут быть использованы только в частном порядке и не подвержены воздействию.
- Композиция обычно подразумевает некоторую семантику владения с последствиями для жизненного цикла объекта; Родительский объект «владеет» ребенком, и у ребенка нет веских причин существовать самостоятельно. Делегация не имеет этого значения.
Код, который вы показываете, использует делегирование и ассоциацию; Ассоциация может быть состав, но трудно сказать без более широкого контекста или дополнительной информации о объектах (это может быть довольно тонким и субъективным, когда ассоциация становится составом).
состав соотношения соотношения между объектами.
Делегация о прохождении работы от одного объекта к другому.
Это на самом деле разные (но иногда связанные) проблемы.
То, что у вас есть, это B (B относится к а). B также делегирует свой один метод A.
, но поскольку использование B является частным (полностью инкапсулирован в черный ящик B), я бы не назвал использование B «композиции». Я бы использовал «состав» только в том случае, если у класса A может быть доступен из B. Что важно вот если логическая модель B «имеет - A» A.
в вашем случае, B реализована с точки зрения A. Поскольку это Концерн реализации Его можно рассматривать как не часть логической модели B. То есть вы можете разумно разговаривать о B, не разговаривая и не заботясь о А.
, что все сказано, что этот материал действительно важен только для инструментов моделирования моделирования PHB и UML. Или, возможно, если вы изучаете проектные шаблоны. Я бы не слишком повесил на него.
[PHB => Заостренный волосатый босс]