Конкретно это я писал в ответ на вопрос, почему свободные функции предпочтительнее методов и чем плохи монолитные классы. 
Давайте углубимся в детали. Программист написал функцию метод, работающую для контейнера vector. Функция работает используя итераторы. Теперь мне тоже необходима эта функция и мне придется дублировать код, хотя этот код мог быть написан в виде свободной функции и использоваться для каждого контейнера (хороший пример алгоритмы STL).

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

Добавлено через 1 минуту и 31 секунду

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

Вы явно упускаете все, что Вам уже не одним постом пытаются объяснить..
скорость компиляции и тяга это все все мелкие проблемы..  самая главная проблема в напряжении мозга наличием лишних сущностей.. 
все остальное ерунда.. 
если в программа основанна на уже упомянутом классе string, то пусть будет что угодно, хоть "format c: "
но если Вы хотите строить из удобных кирпичиков, которые не нужно три дня шлифовать, прежде чем состыковать, 
и иметь такую стену, в которой при замене кирпича на другой аналогичный не нужно заново перебирать всю постройку, то тогда думаю стоит обратить более пристальное внимание на советы, приведенные выше... 

Мы тут говорим о двух моментах одновременно и все запутывается. Давайте разберемся.

имеем два утверждения.

1. класс не должен быть монолитным и должен предоставлять минимально возможный интерфейс. Остальные функции, которые можно написать на основе public интерфейса класса должны быть свободными.
2. не надо наследовать класс, если это НЕ необходимо.

Первый пункт возник из за приведенного ТС примера. По первому пункту все есть еще разногласия?

Это сообщение отредактировал(а) azesmcar - 17.2.2011, 22:35

azesmcar, первый вопрос менее очевидный

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

попробую ещё с двух сторон взгляд предоставить
(вообще-то думал с одной, но пока писал, увидел вторую )

1. с точки зрения пользователя дополнительной функциональности
Код, написанный в take_front, по сути, подходит для любого deque, однако он требует чтобы объект был именно типа MyDeque. Как объяснить пользователю (другому программисту) какими причинами руководствовался разработчик, когда добавлял такое ограничение? Чего ради?

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

Например, есть у нас std::deque.
Класс хороший, но кому-то не нравится, что там нет функции remove_first_half_of_elements. Решение простое - наследуем класс, добавляем метод.

Другому программисту не нравится, что нет функции duplicate_all_elements. Решение простое - наследуем класс, добавляем метод.

Третьему программисту захотелось и того, и того. Решение очевидное - множественное наследование (ну не писать же код заново). Сразу же выясняется, что наследование от std::deque не виртуальное, нужно править код.

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

Сравним с внешними функциями: хочешь функцию - подключай h-файл и пользуйся. Тянет какие-то зависимости - подключай и тягай с собой дополнительные библиотеки. Но только для той функциональности, которая тебе реально нужна. Не больше. Красота 

Это сообщение отредактировал(а) maxim1000 - 17.2.2011, 23:59

maxim1000, да, это похоже на правду жизни
в некоторых проектах постоянное добавление функциональности приводит к появлению глубокой иерархией в этак > 10 классов, перемежая с множественным наследованием ( обязательно где-нибудь встретится повторное наследование  )
этакий архитектурный коллапс

Это сообщение отредактировал(а) alexvs11 - 18.2.2011, 00:11

Ну и темка разрослась, по неосторожно брошенному мной вчера слову.
Спасибо всем, почитал с удовольствием.
А вообще, мое мнение такое. Если программер точно знает что делает, то на здоровье! Страуструп, например, где-то наследуется в своей книге от вектора. 
Ну ему можно (так же как и всем кто досконально понимает, что делает).
Сам я от стл никогда не наследуюсь. Так как далеко мне еще до глубокого понимания механизмов...
А вот goto, например, иногда применяю. И плевать, что там подумают. Есть случаи когда это оправдано.
так-же и здесь, вероятно есть случаи когда стоит нарушить правила. 
Но до этого нужно сначала дорости.

То было private наследование.

Один раз писал алгоритм и казалось вот он тот случай, мне нужен goto! Порадовался, но сделал с помощью switch.  



причем разница только в синтаксисе вызова

и



Это сообщение отредактировал(а) azesmcar - 18.2.2011, 06:13

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


это то ясно, не первый раз замужем 
Понимаете, я поднял тему вовсе не потому, что защищаю наследование от STL-классов, а потому, что внятного объяснения почему это плохо не видел. Впрочем также, как и использование goto, что не значит, что я буду говорить направо и налево: "использование goto - хорошо".

ok, всем большущее спасибо. закрываю "для галочки", но мониторить буду, так, что, если есть ещё мысли/идеи - welcome 

это не плохо   , просто "любой" другой вариант в общем случае лучше  

Добавлено через 39 секунд
а если есть лучшее, то зачем создавать себе лишние неудобства ?.. 

Добавлено через 1 минуту и 32 секунды
а так любое решение - плохое, но из двух зол принято выбирать меньшее © 

Добавлено через 3 минуты и 13 секунд
в общем при открытом наследовании от стл контейнера, его ценность как класса падает.. 
а при использовании свободной функции, ценность самого класса не изменяется, а появляется еще возможно ценная функция 

  
Да, но смысл явно здесь затуманен. Первый свитч вообще не понятно зачем. Некоторые для этой же цели любят применять
do{...; break; ...}while(0); лишь бы не применять goto. Зачем такие ухищрения? С goto было бы ясней. . А чем ясней, тем лучше.

volatile, если приведете пример с goto, который будет структурно ясней, "заработаете" +1 в репу   

Ну, собственно само напрашивается...
(просто убрал первый свитч, с ненужными case'ми который, имхо, и затуманивает дело.)

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


применительно к этой задачи он, имхо, удачнее подходит, чем goto или switch..

Это сообщение отредактировал(а) mes - 19.2.2011, 01:34