Приватные методы

[Old]

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

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

[Bepec]

Хых.
Пример класс скачивания странички.
Используем как класс определения доступности интернета

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

[Old]

Хых.
Пример класс скачивания странички.
Используем как класс определения доступности интернета

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

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

[Racheengel]

QWidget

[Old]

QWidget

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

[ViTech]

Я лично вижу лишь одно оправданное применение привата: какие-нибудь локальные "хелперы", которые на 200% больше нигде не понадобятся, чем в данном конкретном классе. Но и тогда, вы никогда не знаете, как будет использоваться ваш код в будущем другими людьми...

Радикальный взгляд с другой стороны:
(Building user interfaces for object-oriented systems)

1. All data is private. Period. (This rule applies to all implementation details, not just the data.)
2. get and set functions are evil. (They're just elaborate ways to make the data public.)
3. Never ask an object for the information you need to do something; rather, ask the object that has the information to do the work for you.
4. It must be possible to make any change to the way an object is implemented, no matter how significant that change may be, by modifying the single class that defines that object.

Как думаете, что скажет автор этой статьи, если запретить ему использовать private? И я согласен с его доводами. А с Вашими нет.

Protected-секции недостаточно.

Код

C++ (Qt)
 
class Status
{
...
}
 
class A
{
    A() : m_status() {}
 
protected:
    const Status & status() const { return m_status; }
 
private:
    Status m_status;
}
 

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

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

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

[Igors]

Код

C++ (Qt)
protected:
    const Status & status() const { return m_status; }
 
private:
    Status m_status;
}
 

Ну а чего возвращаем по ссылке, провоцируя const_cast? 

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

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

[m_ax]

Ах как легко делать выводы вот на таком примерчике с нулевым ф-ционалом

Основной посыл здесь в том, что отказываясь от привата, вы, фактически, только представьте: развязываете руки целой команде "Практиков" (с большой буквы П) из подмостерья Racheengel, например..
Представляете, чем это чревато? А эти люди ещё всерьёз говорят о

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

 
Так вот, отказ от приват, открывает эту потенциальную опасность, поподя ваш код не в те руки)

И да, нет ничего практичнее хорошей теории)

[ViTech]

Код

C++ (Qt)
protected:
    const Status & status() const { return m_status; }
 
private:
    Status m_status;
}
 

Ну а чего возвращаем по ссылке, провоцируя const_cast? 

Хороший вопрос . А как надо? Как бы Вы метод status() написали?

Ах как легко делать выводы вот на таком примерчике с нулевым ф-ционалом

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

[Old]

Хороший вопрос . А как надо? Как бы Вы метод status() написали?

Возвращать по значению.

[Igors]

Хороший вопрос . А как надо? Как бы Вы метод status() написали?

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

Основной посыл здесь в том, что отказываясь от привата, вы, фактически, только представьте: развязываете руки целой команде "Практиков" (с большой буквы П) из подмостерья Racheengel, например..
Представляете, чем это чревато?

Та ничем, это дорога в светлое будущее. А вообще private - это скорее светлая сторона языка, особенно по сравнению с таким калом как template ...

[m_ax]

Та ничем, это дорога в светлое будущее.

Ну судя по заявлениям типа:

с таким калом как template ...

Это скорее, дорога в тёмное прошлое, даже не скорее, а точно 

[Racheengel]

развязываете руки целой команде "Практиков" (с большой буквы П) из подмостерья Racheengel, например..

Мои подмастерья вполне безобидные и без необходимости const_cast не пихают во все дыры (ну, или по рукам вовремя получают). Я не писал, вообще-то, что мы СОВСЕМ не используем приват. Но на практике почему-то от него было больше проблем, чем позитива. Или сделать данные приватными и на каждую переменную завести по геттеросеттеру (java style) - это хорошая практика???

Как бы Вы метод status() написали?

Нормальный метод, возврат по ссылке исключает создание копии. Что с ней дальше будут делать - вопрос, если очередной Гуру Полиморфизма придет, то const_cast напишет Он же ГУРУ.

А вообще private - это скорее светлая сторона языка, особенно по сравнению с таким калом как template ...

Если под "калом" имеется в виду синтаксис - соглашусь. Если т.н. "метапогромирование" - то тоже соглашусь (но это все-таки больше проблема Гур, чем темплейтов). Но в целом-то фича важная и нужная, когда правильно используется, а не write-only.

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

[Old]

Нормальный метод, возврат по ссылке исключает создание копии. Что с ней дальше будут делать - вопрос, если очередной Гуру Полиморфизма придет, то const_cast напишет Он же ГУРУ.

А если нет такого члена как m_status, а статус вернуть надо?
А если сейчас такой член есть, а через год он станет не нужен и его уберут, а статус возвращать по прежнему надо?

[Racheengel]

А если нет такого члена как m_status, а статус вернуть надо?

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

А если сейчас такой член есть, а через год он станет не нужен и его уберут, а статус возвращать по прежнему надо?

По-моему, у Вас тут противоречие. Нужен статус или нет? Если да - зачем его убирать? Если нет - зачем его возвращать?