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

[Racheengel]

Встречный вопрос - зачем?

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

Отлично, а теперь представьте, что вам необходимо отнаследоваться и изменить или расширить приватную часть в наследнике. Код в дллке, исходники отсутствуют (сторонняя либа), что делать будем?

[Racheengel]

инвариант? не, не слышал.

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

[qate]

Отлично, а теперь представьте, что вам необходимо отнаследоваться и изменить или расширить приватную часть в наследнике. Код в дллке, исходники отсутствуют (сторонняя либа), что делать будем?

приватная часть - это внутренняя реализация этого класса
если создатель класса поместил чтото в приват, значит он показывает этим - это мое, не лезь сюда.
если ты пользователь класса - тебе в паблик
если ты наследник - ты можешь еще и protected
пользовать dll без исходников - ССЗБ )

[Racheengel]

если создатель класса поместил чтото в приват, значит он показывает этим - это мое, не лезь сюда.

А если там Большой Багъ ?

если ты пользователь класса - тебе в паблик
если ты наследник - ты можешь еще и protected
пользовать dll без исходников - ССЗБ )

А если либа коммерческая ?

Я не троллинга ради, это реальная проблема, которая возникает время от времени. Необходимо изменить реализацию приватной части в наследнике. protected - это отличный способ сказать человеку, что реализация внутренняя и так просто ее менять не следует. А что говорит приват? Только то, что код очень сильно завязан на конкретной последовательности обработки данных, и, типа, "работает - не трогай". Но, как правило, именно там и "не работает"

[qate]

А если либа коммерческая ?

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

если ее написали криво, то конструкция языка в этом не виноваты же )

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

[Bepec]

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

[_Bers]

инвариант? не, не слышал.

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

наличие инкапсуляции ещё не гарантия инварианта.
но её отсутствие - точно сводит инвариант на нет.

[Racheengel]

protected, отличное средство для инкапсуляции

а наличие private подрывает один из принципов ООП - наследуемость.

[_Bers]

protected, отличное средство для инкапсуляции

а наличие private подрывает один из принципов ООП - наследуемость.

1.
private ничего не подрывает.
лишь определяет контракт.

2.
вы в любом случае наследуете весь функционал и данные базового класса.
другое дело, что вы не всегда имеете к нему доступ.
и это не случайно. см пункт 1.

[Racheengel]

Приведите пример НЕОБХОДИМОГО использования private, а не protected. Т..е. когда без него либо совсем не обойтись, либо преимущества настолько велики.

[_Bers]

Приведите пример НЕОБХОДИМОГО использования private, а не protected. Т..е. когда без него либо совсем не обойтись, либо преимущества настолько велики.

приведите пример НЕОБХОДИМОГО использования модификаторов доступа вообще,
а так же квалификаторов const.

вы похоже не осознаете, насколько глупа ваша просьба.

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

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

но вы сами можете взять эти самые книжки и просто прочитать.
например: "Совершенный код" Макконелла.

[Racheengel]

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

bool doSomething(const QList& listIn, QList& listOut) const
{
...
}

const QList& listIn обозначает то, что listIn не должен меняться внутри doSomething. Во-первых, программист, видя это определение, понимает, что listIn является входным параметром, в отличие от listOut, а во-вторых, это дает больше возможностей компилятору оптимизировать данный код.

const в конце doSomething означает, что сам по себе метод не предполагает изменений состояния объекта (чем не инваринт?), а значит, написать в коде что-то типа

m_member = listIn;

компилятор не позволит, пока m_member не будет объявлен как mutable в заголовке класса.

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

Прежде чем обвинять людей в том, что они идиоты, докажите это. Не повторяйте книжные фразы. Просто приведите пример преимущества private против protected. Как видите, "глупую" просьбу насчет const я выполнил

[Igors]

Приведите пример НЕОБХОДИМОГО использования private, а не protected. Т..е. когда без него либо совсем не обойтись, либо преимущества настолько велики.

Не все можно исчерпать примерами, но преимущества private (как и const) действительно могут быть очень велики. Они позволяют программисту сделать "утверждение", проводить какую-то (не побоюсь этого слова) концепцию. Правильна она или нет - др вопрос. Да, это часто конфликтует с "гибкостью", c'est la vie

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

[Racheengel]

Просто получается, что все, что находится в привате - не имеет права на ошибку и на ее исправление (либо расширение функционала) в потомках. А это ограничивает, и не всегда в лучшую сторону.

[Igors]

Просто получается, что все, что находится в привате - не имеет права на ошибку и на ее исправление (либо расширение функционала) в потомках. А это ограничивает, и не всегда в лучшую сторону.

Да, так и есть. Но недостатки есть продолжение достоинств - и наоборот. А стремление "чтобы всем было хорошо" выглядит несколько наивно