Здравствуйте!
Подскажите, пожалуйста, чем отличается композиция от наследования.Наследование-это понятно что такое. А композиция?
(маленький, на композицию....)
Заранее благодарю

усть два класса

Код

class Foo{   public:     int Get(){} }; class Bar{    Foo f; //композиция    public:       int Get(){return f.Get()} };

т.е. мы не используем наследование а создаем объект в самом классе

Спасибо

у буча это, кажется, называется агрегацией?

Цитата

у буча это, кажется, называется агрегацией?

, да это у всех называется агрегацией. Вообще предпочитай композицию наследованию;

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

Это сообщение отредактировал(а) blackofe - 10.1.2006, 01:17

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

Цитата

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

Айайай, чему вы учите! Композиция и наследование используются для решения совершенно разных задач ! Ну-ка, продемонстрируй полиморфизм на базе композиции. Еще бы сравнили операторы if и while.

threef
Думаю, если слово "наследование" заменить на "наследование реализации" вопрос несколько прояснится.

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

Цитата(threef @ 10.1.2006, 12:44)

Айайай, чему вы учите! Композиция и наследование используются для решения совершенно разных задач ! Ну-ка, продемонстрируй полиморфизм на базе композиции. Еще бы сравнили операторы if и while.

Айайай. Как Вы задачи наследования ограничиваете.
Вы никогда о множественном наследовании не слышали?
Так вот задача:

Код

class A {  public:     func_a() ; };  class B {  public:     func_b() ; };

Нужен класс С, имеющий func_a() и func_b() ;
То есть требуется реализовать повторное использование кода без copy-past
Как будем решать задачу с учетом того, что возможны три решения?

Виноват, четыре решения

А что бы Вы не думали, что только меня мучают сомнения, что в конкретном случае применить, я дам пару цитат по данной проблеме

http://uic.rsu.ru/doc/programming/c++/TIC2...html#Heading428

Цитата

В мире ООП часто приходится слышать высказывания типа «композиция предпочтитель-нее наследования» (то есть лучше использовать интерфейсы, а не наследование). Благодаря средствам контроля версии в .NET выбор между наследованием и композицией уже не играет столь принципиальной роли. Используйте наследование всюду, где это уместно, — там, где существует ярко выраженная связь типа «является частным случаем».

Цитата

Действительно, в C++ скрытое (защищенное или закрытое) наследование почти всегда можно заменить скрытой агрегацией экземпляра суперкласса. Решая, с чем вы имеете дело - с наследованием или агрегацией - будьте осторожны. Если вы не уверены, что налицо отношение общего и частного (is а), вместо наследования лучше применить агрегацию или что-нибудь еще

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

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

Цитата

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

Цитата

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

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

Если объект создаётся в обявлении класса, то это называется композицией.
Если же в объявлении находятся только указатели на него, то это называется агрегацией.
Добавлено @ 14:59
Inheritance and Composition
Inheritance is the feature of classes that allows one class to be derived from another. The class that you derive a new class from is called the base class, and the new class is called the derived class. Classes create a hierarchy, which is usually shown as a tree, where base classes are higher in the tree. Each derived class inherits all of the public members of the base class, and all of the private members of the base class remain private. The third member access specifier, protected, allows instances of a derived class to have access to that member. Further, you can redefine functions in base classes, providing unique functionality in the derived class. The derived class may explicitly call the function from the base class using the namespace modifier (:. Thus, if a base class defined the member print() and a derived class defined the same function, the derived class could call the base class’ print function with the notation, baseClass::print(). The constructor of the base class automatically executes when the derived class’ constructor is called; you therefore do not need to explicitly call this member function. A good example of simple inheritance is the stream family of classes, which you use for interacting with input and output devices. The class tree starts with ios that houses basic operations and flags, and builds with each new class providing more functionality and more specific features, such as ifstream which specializes in reading from input files.

Composition is simply defining a class as a member of another class, and all normal scope rules apply. A class that is a member of another class does not enjoy the same benefits as a derived class, and only has access to public members of the containing class.

Object-oriented design principles are encapsulation, inheritance, and polymorphism. All of these design principles are possible in C++ with classes, and programming with OOD principles is called object-oriented programming.

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 наследование.

Earnest, извини, страшно не люблю, когда на личности переходят.

в чем будем опыт измерять? в годах, говоришь? да, когда я первую строчку main() набрал в turbo c 1.0, тебя еще на свете не было. и за спиной у меня десятки работающих поныне приложений. работающих годами без переделок. и не игрушек типа крестики-нолики, а системных сервисов и объектов, на которых держатся коммерческие вебсайты и b2b-приложения.

соглашусь, что знаний мне не хватает. но покажи, у кого их достаточно.

честно, я был о тебе лучшего мнения.

с set и list я, быть может, поторопился. хотя в моем понимании что-то родственное в них есть. а если в stl они реализованы не через наследование, то уж и не через агрегацию. поэтому вопрос на знание stl был некорректный. и не вижу особых проблем, если бы я реализовал set через наследование.
Добавлено @ 19:31

Цитата(Mayk @ 13.1.2006, 11:27)

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

что ж вы мне все эту stl суете! да это ж вообще не объектно-ориентированная библиотека! как же можно ее в пример приводить?

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

А теперь по существу - насчет STL, агрегаций и прочего. STL - конечно, очень даже объектно-ориентированная библиотека. Кроме всего прочего. А что, ты считаешь, что ООП - это бешенные иерархии классов + все методы живут внутри них?
И агрегация, как бы ее не называли, лучшее проектное решение чем наследование. И наследование нужно использовать только тогда когда без него нельзя обойтись...

Методология программирования пришла к этому уже несколько лет как... Чего уж тут спорить.


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

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

Цитата(Earnest @ 13.1.2006, 21:44)

STL - конечно, очень даже объектно-ориентированная библиотека.

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

http://gethelp.devx.com/techtips/cpp_pro/10min/10min0900.asp

и еще я так понял, что пользуясь объектно-ориентированностью stl, вы частенько делаете такие вещи, как

class MySuperString : public std::string {
};

вот еще:

Encapsulation of data and functionality in objects is a hallmark of object-oriented programming. In the Standard C++ Library, however, the data structures are separate from the algorithms you use to manipulate them.

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

blackofe, тема уже себя исчерпала.

Это сообщение отредактировал(а) np9mi7 - 14.1.2006, 02:17