1. public наследование реализует модель "is-a"
2. private наследование реализует модель "has-a"
А что/зачем нужен сабж?

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>1. public наследование реализует модель "is-a"
ДН>2. private наследование реализует модель "has-a"

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

ДН>А что/зачем нужен сабж?

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

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>1. public наследование реализует модель "is-a"
ДН>2. private наследование реализует модель "has-a"
ДН>А что/зачем нужен сабж?

Они все — "is a", только public — это во всеуслышание, private — сам с собой, а protected — по секрету :)

You will always get what you always got
  If you always do  what you always did

Здравствуйте, dkon, Вы писали:

D>приватное наследование выражает "реализован-посредством", а не "включает-в-себя".

Это одно и тоже. Рассмотрим пример:

class Engine
{
public:
  void RevsUp();
  void RevsDown();
};

Возьмем два случая:
1. Закрытое наследование

class Car : private Engine
{
};

2. Aggregation (не помню как правильно по русски пишется — одна "г" или две... )

class Car
{
private:
  Engine _engine;
public:
  void RevsUp() { _engine.RevsUp(); }
  void RevsDown() { _engine.RevsDown(); }
};

В обоих случаях, с точки зрения пользователя класса Car, оба случая можно выразить словами "Car has an Engine".

Здравствуйте, jazzer, Вы писали:

J>Они все — "is a", только public — это во всеуслышание, private — сам с собой, а protected — по секрету

А вы шутник однако... Но насчет все они "is a" это неправда.

Здравствуйте, Дмитрий Наумов, Вы писали:

D>приватное наследование выражает "реализован-посредством", а не "включает-в-себя".

ДН>Это одно и тоже. Рассмотрим пример:

ДН>

ДН>class Car : private Engine
ДН>

ДН>

ДН>class Car {
ДН>private:
ДН>  Engine _engine;
ДН>

ДН>В обоих случаях, с точки зрения пользователя класса Car, оба случая можно выразить словами "Car has an Engine".

Хе :)
А если это не движок, а четыре колеса плюс пятое запасное? :)

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>Здравствуйте, jazzer, Вы писали:

J>Они все — "is a", только public — это во всеуслышание, private — сам с собой, а protected — по секрету :)

ДН>А вы шутник однако... :) Но насчет все они "is a" это неправда.

Проиллюстрирую свою мысль:

class VasyaPupkin
  : public Human,
    private SexualManiac,
    protected AIDS_Infected
{
...
};

Вместо маньяка можно подставить марсианина, например, хотя это уже будет ближе к наследственному признаку protected :)

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

ДН>>В обоих случаях, с точки зрения пользователя класса Car, оба случая можно выразить словами "Car has an Engine".

J>
J>Хе
J>А если это не движок, а четыре колеса плюс пятое запасное?

А в чем проблема? Либо агрегируем, либо приватно наследуемся от всего что нужно. Все равно "has-a" остается.

Здравствуйте, Дмитрий Наумов, Вы писали:

J>> А если это не движок, а четыре колеса плюс пятое запасное?

ДН> А в чем проблема? Либо агрегируем, либо приватно наследуемся от
ДН> всего что нужно. Все равно "has-a" остается.

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Здравствуйте, Дмитрий Наумов, Вы писали:

J>>> А если это не движок, а четыре колеса плюс пятое запасное?

ДН>> А в чем проблема? Либо агрегируем, либо приватно наследуемся от
ДН>> всего что нужно. Все равно "has-a" остается.

ПК>А как ты унаследуешь свой класс от пяти колес? Хитрые упражнения, которые придется
ПК>для этого проделать, должны навести на мысль, что проблема все-таки имеется

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Здравствуйте, Дмитрий Наумов, Вы писали:

J>>> А если это не движок, а четыре колеса плюс пятое запасное?

ДН>> А в чем проблема? Либо агрегируем, либо приватно наследуемся от
ДН>> всего что нужно. Все равно "has-a" остается.

ПК>А как ты унаследуешь свой класс от пяти колес? Хитрые упражнения, которые придется
ПК>для этого проделать, должны навести на мысль, что проблема все-таки имеется

class Engine {};
class Wheel {};
class LFWheel : public Wheel {}; // left front
class RFWheel : public Wheel {}; // right front
class LRWheel : public Wheel {}; // left rear
class RRWheel : public Wheel {}; // rigth rear

class Car : private Engine, private LFWheel, private RFWheel ... {};

И не говорите мне что это выглядит убого — я тоже так считаю, но, опять же, имхо, это проблемы инструмента, а с концептуальной точки зрение, я, все еще , считаю что закрытое наследование, это одна из возможностей данного инструментария для выражения модели "has-a"

Здравствуйте, Дмитрий Наумов, Вы писали:

ПК>> А как ты унаследуешь свой класс от пяти колес? Хитрые упражнения,
ПК>> которые придется для этого проделать, должны навести на мысль, что
ПК>> проблема все-таки имеется

ДН>

ДН> class Car : private Engine, private LFWheel, private RFWheel ... {};
ДН>

ДН> И не говорите мне что это выглядит убого — я тоже так считаю, но,
ДН> опять же, имхо, это проблемы инструмента,

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Ага... А теперь, пожалуйста то же самое для переменного количества
ПК>агрегируемых объектов.

Павел, я не вижу конструктива в ваших словах!
Давайте вернемся к нашей печке:

class Car : private Engine
{
};

class Car
{
private:
  Engine _engine;
public:
  void RevsUp() { _engine.RevsUp(); }
  void RevsDown() { _engine.RevsDown(); }
};

Являются ли ЭТИ два примера отображением концепции "has-a"? Если нет, то что тогда?

Насчет переменного количества агрегируемых объектов — я ввел разговор к тому (точнее меня то вообще интересовало protected наследование), что закрытое наследование и агрегация — одно и тоже в плане концепции. Если я могу, то можно делать и агрегацией и наследованием. ЕСЛИ — ключевое слово. В случае с переменным числом агрегируемых объектов я использовать наследование не могу, но теряет ли оно от этого смысл "has-a"? ИМХО, нет, просто в данном конкретном случае оно не применимо, но в тех случаях, в которых может быть применено, оно выполняет свои функции. Разве не так? Correct me, if I'm wrong.

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>

ДН>class Engine {};
ДН>class Wheel {};
ДН>class LFWheel : public Wheel {}; // left front
ДН>class RFWheel : public Wheel {}; // right front
ДН>class LRWheel : public Wheel {}; // left rear
ДН>class RRWheel : public Wheel {}; // rigth rear

ДН>class Car : private Engine, private LFWheel, private RFWheel ... {};
ДН>

ДН>И не говорите мне что это выглядит убого — я тоже так считаю, но, опять же, имхо, это проблемы инструмента, а с концептуальной точки зрение, я, все еще , считаю что закрытое наследование, это одна из возможностей данного инструментария для выражения модели "has-a"

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

В данном примере, на мой взгляд, наследование совершенно бессмыслено и делает дизайн хрупким/ломким (brittle, как обычно пишут).

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>Здравствуйте, Павел Кузнецов, Вы писали:

ПК>>Ага... А теперь, пожалуйста то же самое для переменного количества
ПК>>агрегируемых объектов.

ДН>Павел, я не вижу конструктива в ваших словах!
ДН>Давайте вернемся к нашей печке:

ДН>

ДН>class Car : private Engine
ДН>{
ДН>};

ДН>class Car
ДН>{
ДН>private:
ДН>  Engine _engine;
ДН>public:
ДН>  void RevsUp() { _engine.RevsUp(); }
ДН>  void RevsDown() { _engine.RevsDown(); }
ДН>};
ДН>

ДН>Являются ли ЭТИ два примера отображением концепции "has-a"? Если нет, то что тогда?

Нет.

Композиция ("has-a") и непубличное наследование ("implemented in terms of") — совсем разные вещи.

Здравствуйте, MaximE, Вы писали:

ME>Вообще, в любой книжке по дизайну на с++ сказано, что наследование — самая сильная, зафиксированная на этапе компиляции связь и пользовать ее следует очень обдумано. Обычно, композиция (агрегация) предоставлет больше гибкости и возможностей в плане примения паттернов проектирования.

Это я знаю. Не стоит рассматривать данный пример, как момент выбора "что использовать — наследование или агрегацию?" — это просто пример.

ME>В данном примере, на мой взгляд, наследование совершенно бессмыслено и делает дизайн хрупким/ломким (brittle, как обычно пишут).

Вот именно что в данном. Если представить что у агрегируемых классов имеется на всех сотня открытых методов, которые надо предоставить (expose) клиентам и каких либо других противопоказаний к наследованию у вас нет, то что вы выберете — агрегацию и написать сотню методов для делегации или закрытое наследование?

P.S. А может плюнете и используете открытое наследование?

Здравствуйте, MaximE, Вы писали:

ME>Композиция ("has-a") и непубличное наследование ("implemented in terms of") — совсем разные вещи.

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

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>Здравствуйте, MaximE, Вы писали:

ME>>Композиция ("has-a") и непубличное наследование ("implemented in terms of") — совсем разные вещи.

ДН>Дайте, плз, мне какую нибудь ссылочку такую трактовку и я с радостью признаю свою ошибку. Я ж не спорить попусту сюда пришел...

Самая первая ссылка:

http://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=c%2B%2B+%22is%2Da%22+%22implemented+in+terms+of%22

Здравствуйте, MaximE, Вы писали:

ME>http://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=c%2B%2B+%22is%2Da%22+%22implemented+in+terms+of%22

По ссылке:

Bill Venners: Please differentiate HAS-A and IS- IMPLEMENTED-IN-TERMS-OF.

Scott Meyers: When you write software, you deal with two worlds. You deal with the world you want to model, the outside world. You also deal with a world that exists only inside the software, which involves just getting the code to work. HAS-A corresponds to something in the real world. A Car HAS Wheels or a Person HAS Friends. HAS-A corresponds to the application domain. IS-IMPLEMENTED-IN-TERMS-OF never exists in the real world; it is part of the implementation domain. So you couldn't say a Car IS-IMPLEMENTED-IN-TERMS-OF Wheels. A Car HAS Wheels. But you could say the ParkingLot IS-IMPLEMENTED-IN-TERMS-OF a List. There's no List in the real world. The List only exists inside the software. So HAS-A is a relationship between classes that exists in the application domain. IS-IMPLEMENTED-IN-TERMS-OF is a relationship between classes that exists in the implementation domain.

Bill Venners: That's great. That clarifies it for me.

Scott Meyers: It took me a few years to figure that out myself, actually.

Видно мои "a few years" еще не прошли, потому как я нифига не понял...
Потому как, его послушать, мой Car все таки has a wheel, несмотря на то, что сделано через наследование. ИМХО зря он тут ввел всякие application domain, implementation domain — толком ничего и не сказал.

Здравствуйте, jazzer, Вы писали:

J>>Они все — "is a", только public — это во всеуслышание, private — сам с собой, а protected — по секрету
J>

J>class VasyaPupkin
J>  : public Human,
J>    private SexualManiac,
J>    protected AIDS_Infected
J>{
J>...
J>};
J>

Ну и как воспользоваться тем, что VasyaPupkin "is-a" SexualManiac ?
Все же более логично пользоваться закрытым наследованием для выражения "has-a" (Вася имеет соответствующие наклонности) или, действительно, "is-implemented-in-terms-of". А от "is-a" остается только скрытая связь, которой нельзя воспользоваться.