pablo
Не согласен. Точнее не согласен с критерием разделения. С указателем в объявлении класса может быть и композиция, и агрегация. Да ещё и ассоциация

К примеру,

Код

class Container {   private:    Item* temp;   public:     virtual ~Container() {delete temp;} };

Указатель есть, но это будет композиция, так как от времени жизни "целого" зависит время жизни "частного". Если бы не было зависимости "времени жизни", а лишь отношение "целое-частное" - это агрегация. А будь так, как ты сказал, простой указатель в объявлении и никакой зависимости, кроме того, что один знает о состоянии другого - это ассоциация.

а вот что такое агрегация: http://cplus.about.com/od/beginnerctutorial/l/aa091502a.htm
Добавлено @ 15:06
да, не то немного. но вот здесь всё нормально рассказано что к чему

Цитата(np9mi7 @ 11.1.2006, 09:42)

Цитата Причина в том, что композиция представляет более слабую зависимость, чем наследование.

что значит "более слабую зависимость"? если можно, в килограммах, пожалуйста.
Добавлено @ 19:27

Цитата(pablo @ 11.1.2006, 14:50)

Если объект создаётся в обявлении класса, то это называется композицией. Если же в объявлении находятся только указатели на него, то это называется агрегацией.

круто! где ты взял такие определения? ссылку, плиз, в студию!
Добавлено @ 19:34

Цитата(pablo @ 11.1.2006, 15:02)

а вот что такое агрегация: http://cplus.about.com/od/beginnerctutorial/l/aa091502a.htm

из этой ссылки я понял лишь следующее:

генерализация (Generalization) - это отношение между классами "b есть a". к примеру, "яблоко есть фрукт". данное отношение реализуется в с++ через наследование.

Код

class Fruit { }; class Apple : public Fruit { };

агрегация (Aggregation) - отношение "b есть часть a". к примеру, "яблоко есть часть яблони". данное отношение в с++ реализуется через члены класса. к примеру, класс "яблоня" может иметь членом коллекцию классов "яблоко".

Код

class Apple { }; class AppleTree {    vector<Apple> apples; };

ассоциация (Association) - довольно расплывчатое отношение. два класса мы можем назвать находящимися в отношении ассоциации, если один из них - Man, допустим, имеет методы, параметрами которого являются переменные типа Apple. т.е.

Код

class Apple { }; class Man {   void Eat(const Apple &apple); };

в данном случае классы Man и Apple находятся в отношении ассоциации.

поправляйте меня.

Это сообщение отредактировал(а) blackofe - 11.1.2006, 19:41

так как насчет композиции-то?

Summary

Avoid inheritance taxes: Inheritance is the second-tightest coupling relationship in C++, second only to friendship. Tight coupling is undesirable and should be avoided where possible. Therefore, prefer composition to inheritance unless you know that the latter truly benefits your design.

Discussion

Inheritance is often overused, even by experienced developers. A sound rule of software engineering is to minimize coupling: If a relationship can be expressed in more than one way, use the weakest relationship that's practical.

Given that inheritance is nearly the strongest relationship we can express in C++, second only to friendship, it's only really appropriate when there is no equivalent weaker alternative. If you can express a class relationship using composition alone, you should prefer that.

In this context, "composition" means simply embedding a member variable of a type within another type. This way, you can hold and use the object in ways that allow you control over the strength of the coupling.

Composition has important advantages over inheritance:

Greater flexibility without affecting calling code: A private data member is under your control. You can switch from holding it by value to holding by (smart) pointer or Pimpl (see Item 43) without breaking client code; you would only need to change the implementations of the class's own member functions that use it. If you decide you need different functionality, you can easily change the type of the member or the manner of holding it while keeping the class's public interface consistent. In contrast, if you begin with a public inheritance relationship, it is likely that clients have already come to depend on the inheritance; you have therefore committed your class to it and cannot easily change your base class decision later on. (See Item 37.)

Greater compile-time insulation, shorter compile times: Holding an object by pointer (preferably a smart pointer), rather than as a direct member or base class, can also allow you to reduce header dependencies because declaring a pointer to an object doesn't require that object's full class definition. By contrast, inheritance always requires the full definition of the base class to be visible. A common technique is to aggregate all private members behind a single opaque pointer, called a Pimpl (see Item 43).

Less weirdness: Inheriting from a type can cause name lookup to pull in functions and function templates defined in the same namespace as that type. This is very subtle and hard to debug. (See also Item 58)

Wider applicability: Some classes were not designed to be bases in the first place (and see Item 35). Most classes, however, can fulfill the role of a member.

Great robustness and safety: The tighter coupling of inheritance makes it more difficult to write error-safe code. (See [Sutter02] §23.)

Less complexity and fragility: Inheritance exposes you to additional complications, such as name hiding and other complications that can arise in the presence of later changes to the base class.

Of course, these are not arguments against inheritance per se. Inheritance affords a great deal of power, including substitutability and/or the ability to override virtual functions (see Items 36 through 39, and Exceptions below). But don't pay for what you don't need; unless you need inheritance's power, don't endure its drawbacks.

Exceptions

Do use public inheritance to model substitutability. (See Item 37.)

Even if you don't need to provide a substitutability relationship to all callers, you do need nonpublic inheritance if you need any of the following, in rough order from most common (the first two points) to exceedingly rare (the rest):

If you need to override a virtual function.

If you need access to a protected member.

If you need to construct the used object before, or destroy it after, a base class.

If you need to worry about virtual base classes.

If you know you benefit from the empty base class optimization, including that it matters in this case and that your target compiler(s) actually perform it in this case. (See Item 8)

If you need controlled polymorphism. That is, if you need a substitutability relationship, but that relationship should be visible only to selected code (via friendship).

References

34. Prefer composition to inheritance, C++ Coding Standards: 101 Rules, Guidelines, and Best Practices By Herb Sutter, Andrei Alexandrescu

Это сообщение отредактировал(а) np9mi7 - 11.1.2006, 19:57

np9mi7, спасибо за инфу.

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

а потому мне и непонятны эти "сильные связи", "слабые связи". если один класс должен быть наследован от другого, то он должен быть от него наследован. если один класс является членом другого, то он должен быть его членом. я как-то никогда не взвешивал силу связи между классами.

и кстати, я в очередной раз убедился, что композиция и агрегация - суть синонимы.

Это сообщение отредактировал(а) blackofe - 11.1.2006, 20:19

Цитата(blackofe @ 11.1.2006, 20:17)

и кстати, я в очередной раз убедился, что композиция и агрегация - суть синонимы.

Нет, хотя понятия очень близкие. При отношениях типа "агрегация" "целое" не отвечает за время жизни "частного". При отношениях типа "композиция", такая заисимость (явная или косвенная) существует. Это и есть их главное, да и пожалуй единственное, отличие друг от друга.

Это сообщение отредактировал(а) dronzo - 11.1.2006, 21:25

Цитата

если один класс должен быть наследован от другого, то он должен быть от него наследован

, да? Никогда не думал, что итераторы в STL можно было через наследование реализовать? Не думал почему они так не раализованы?

Цитата

это как читать буча - мужик пишет само собой разумеющиеся вещи!

, само сабой разумеющиеся вещи? - Тогда ты гений! Всем остальным нужны годы для того чтобы считать идеи Гради Буча очевидными вещами.

Так что значит это твое - класс должен быть наследован от другого?

Цитата

мне и непонятны эти "сильные связи", "слабые связи"

, с этого и начни. Попробуй почитать литературу, посмотреть и почитать форумы не нужно говорить, мне это не понятно и я этим горжусь, это очевидно - всё это от того, что заморачиваться не хочеться - всё равно на форуме всё разжуют. Да?

Цитата(dronzo @ 11.1.2006, 20:24)

Нет, хотя понятия очень близкие. При отношениях типа "агрегация" "целое" не отвечает за время жизни "частного". При отношениях типа "композиция", такая заисимость (явная или косвенная) существует. Это и есть их главное, да и пожалуй единственное, отличие друг от друга.

где такое написано? кто вводил такие понятия? где об этом можно почитать?
Добавлено @ 21:52
np9mi7, папрашу без ярлыков!

если я вижу, что создаваемый мною класс должен быть наследован от другого, то я его наследую. я не знаю, из чего я при этом исхожу. это как писать стихи. почему они пишутся именно так?

и причем тут итераторы? если при создании итераторов нельзя использовать наследование, или ненужно, или сложно, или по любым другим причинам, то какого я буду его использовать?

про буча - серьезно. читать его скучно. он разжевывает очевидные вещи, прописные истины. это как читать библию. не убий, не укради - ну, дык, это ж и дураку ясно!

и я нигде не писал, что горжусь тем, что мне это непонятно. так что давайте без передергиваний и без снобизма. плииз.

Это сообщение отредактировал(а) blackofe - 11.1.2006, 21:44

Цитата(blackofe @ 11.1.2006, 21:44)

где такое написано? кто вводил такие понятия? где об этом можно почитать?

Везде, где мне встречалось отличие комопзиции от агрегации (google : composition + aggregation + lifetime). Не знаю.
По любой из ссылок, которую можно получить на вышеописанный запрос, да и по ссылке на статью с codeproject.com, которую pablo уже привёл в теме, тоже самое написано.

Цитата(dronzo @ 11.1.2006, 22:40)

Везде, где мне встречалось отличие комопзиции от агрегации (google : composition + aggregation + lifetime). Не знаю. По любой из ссылок, которую можно получить на вышеописанный запрос, да и по ссылке на  статью с codeproject.com, которую  pablo уже привёл в теме, тоже самое написано.

спасибо, дочитал. как-то в первый раз не бросилось в глаза.

Цитата(blackofe @ 11.1.2006, 21:44 )

про буча - серьезно. читать его скучно. он разжевывает очевидные вещи, прописные истины. это как читать библию. не убий, не укради - ну, дык, это ж и дураку ясно! и я нигде не писал, что горжусь тем, что мне это непонятно. так что давайте без передергиваний и без снобизма. плииз.

Вообще со снобизма начали Вы.
А раз Вам не понятно, каким образом наследование может заменять композицию и обратно, придется привести пример из классиков, которых Вам читать скучно. Никогда не задавались вопросом, а нафига в с++ предусмотрено private наследование.
А теперь пример, когда наследование и композиция - эти

Цитата(blackofe)

разные вещи, для разных целей. их сравнивать, все-равно что сравнивать мотоцикл с автомобилем.

выполняют одну и туже функцию

Композиция

Код

class List { public:      List();   ...           void addToFront(int);      bool  includes(int);    ....     };   class Set { public:    Set(): theData() {}    void  add(int value)     {       if ( !theData.includes(value) ) {              theData.addToFront( value );       }    }   //... private:      List  theData; };

Наследование

Код

class Set : private List { public:    Set():List(){}    void  add(int value)     {       if ( !theData.includes(value) ) {              List::addToFront( value );       }    } ... };

Кстати и Ваши "мотоцикл с автомобилем" по сути своей предназанчены для одного и того же: доставить Вас из точки A в точку B

Vyacheslav
если я назвал книгу буча очевидной, то почему меня сразу надо обвинять в снобизме? откройте математику за первый класс. она не покажется вам очевидной и самособойразумеющейся? и не надо говорить, что я считаю себя умнее буча. я не умней его, я просто с ним согласен. и практически всегда следую его советам и следовал еще до того, как его прочитал. поэтому он и очевиден для меня. что здесь плохого? я ж не говорю, что в нашей маскве дома выше, чем в вашем урюпинске. я говорю, что наши дома так же хороши, как ваши. откуда здесь снобизм?

далее. то, что можно стоять на перепутье и решать, что лучше - композиция или наследование, я тоже знаю. просто у меня никогда таких перепутий не было. для меня практически всегда ясно, какую из этих двух парадигм использовать. что, опять же, в этом плохого?

и к слову о примере: я бы использовал наследование. потому как "набор" таки суть логически есть "список", но с определенными свойствами.

Цитата(blackofe @ 12.1.2006, 21:49 )

и к слову о примере: я бы использовал наследование. потому как "набор" таки суть логически есть "список", но с определенными свойствами.

Ты не прав, набор не "есть список", а "может быть реализован посредством списка". Кардинальное отличие: список - это последовательность, а набор - нет. Ну и т.д.
Каждый раз, когда нужно "сужать" интерфейс базового класса, это говорит о том, что открытое наследование - не то что доктор прописал.
То что для тебя таких "перепутьев не было" говорит только о недостаточном опыте и о недостаточном осознании проблем ООП - это просто болезнь роста, и то что рекомендации Буча тебе кажутся очевидными - тоже отсюда растет.
Приведу такую аналогию:
В автомабильных авариях есть такая статистика: один из пиков ДТП приходится на водителей со стажем 2-3 года. Сначала новички, осознавая свою ламерность, ездят медленно и осторожно, но через 2-3 года преисполняются такой уверенности в себе, что им кажется, что они уже прошли огонь и воду.

Ты уж пожалуйста не обижайся, со стороны это хорошо заметно.

Цитата(blackofe @ 13.1.2006, 01:49 )

я бы использовал наследование. потому как "набор" таки суть логически есть "список", но с определенными свойствами.

Посмотрите как реализован std::stack в реальной жизни. Подумайте о возможных проблемах, если бы вместо агрегации, использовалось protected наследование.