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

[AzazelloAV]

Никакого практического либо теоретического смысла данный пост не имеет.
Это просто рассуждения в субботний вечер.

Зачем собственно в хедерах приватные функции?
Краеугольный камень ООП, скрыть реализацию. Реализация, как правило, в протектед и в приват. Если с протектед все понятно, то зачем же сувать приватные функции в хеадер. Они спокойно могли бы жить в cpp.

Да, может быть визуально проще читать класс в хедере.
Но! Это противорчит самой концепции ООП, мы вообще о них не должны ничего знать, а во вторых, вон исходники Qt читаем, и ничего с их приватными классами.
Где, где хоть один плюс при использовании приватный функций в хедере - кроме того что так принято и ожидаемо.

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

ПЛЮСЫ отсутсвия приватных функций в хедере малозначительны, но все же есть.
Убыстряем компиляцию (при изменении хедера)
Уменьшаем простыню хедера

МИНУСЫ
Все таки мы ожидаем, что приватные функции есть, и может ступор быть в 2-3 секунды при их отсутствии.
Как то хаком все таки возможно сделать приват видимым в наследуемом классе. Ну, тут люд такой, что не думаю будет пользоваться таким приемом.
Ваш вариант.

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

[Johnik]

PIMPL, в Qt этот паттерн активно используется.

[AzazelloAV]

PIMPL, в Qt этот паттерн активно используется.

Да все знают, что он там используется. Когда Вы пишете не для разработчиков Qt, вы пишите, так как пишите, по старинке. У Qt своя парадигма, вы же под неё не подстраиваетесь. Тем более, что официально у них  - для бинарной совместимости. Какая такая бинарная совместимость у мелкого, даже пусть крупного проекта. Просто любой "крупный" Ваш проект мелкий по сравнению с Qt, и, тем более, конечный, в отличии от Qt.

Опять видно вопрос не верно задал и не те акценты расставил.

Хорошо, сформулирую лаконично - при каких условиях кто-то или Вы согласится перейти на эту парадигму.

Я специально не спросил про Qt. Я акцент сделал на C++, как таковой. Приватные классы и прятанье приватов - это разный уровень, не все готовы тратить на разработку! и продуманость столько времени.

Чтобы не было дальше сравнений с Qt  - http://habrahabr.ru/post/76248/

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

[Johnik]

Хорошо, сформулирую лаконично - при каких условиях кто-то или Вы согласится перейти на эту парадигму.

Я его использую, в основном по этим причинам (из статьи, что вы привели):
5. Увеличивается скорость сборки приложения (что очень актуально).
6. Прячется вся ненужная реализация от клиента, в отличие от приватных методов, pimpl объявление и реализацию не видно вообще.

[AzazelloAV]

Я его использую, в основном по этим причинам (из статьи, что вы привели):
5. Увеличивается скорость сборки приложения (что очень актуально).
6. Прячется вся ненужная реализация от клиента, в отличие от приватных методов, pimpl объявление и реализацию не видно вообще.

У меня будет просьба к Вам - не спешите отвечать на этот пост.
Согласен со всеми Вашими пунктами.
Но! Я Вам говорил про то же самое, а Вы мне привели идеологию Qt. При чём здесь сокрытие приватный функций и приватные классы?
Ну как минимум никакой new не вызывается. Вы посмотрите продуманность классов Qt. У меня нету столько ресурсов, чтобы это реализовать.Мало того, не все классы Qt имеют приватные классы. Для меня вообще удивительно, Qt пошло по принципу медленной эволюции, где на этом же принципе загнулись все проекты - либо обрасли хламом (пример gtk), либо ушли в бездну. С каждой версией настолько мелкие изменения, однако как паровоз вперёд летит. Мы можем себе такое позвоилить, оглядываясь на команду разработчиков Qt? Да конечно нет.

Прячется вся ненужная реализация от клиента, в отличие от приватных методов, pimpl объявление и реализацию не видно вообще.

Ничего там не прячется. Вы клиент Qt, и что? От вас прячется реализация приватных классов? Каким образом?

[vbv]

Добрый!

Скажу так:
С точки зрения работоспособности кода - возможно надобности нет.
Но.
1. С точки зрения ООП (объектно-ориентированного проектирования) их наличие необходимо. Подробности опущу.
2. Полнота класса должна быть т.к. класс может быть унаследован и некоторые методы могут, для примера, не/стать virtual. Или появиться собственная реализация. Или разделиться на части.....
3. Так-же отсутствие подобного механизма в заголовке серьезно будет мешать принципу циклической разработки при том-же ООП (только в данном случае программировании).

Но это на вскидку.
А на мой, лично, взгляд главное это целостность описания при применении ООП.

[Igors]

Зачем собственно в хедерах приватные функции?

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

Вообще я часто начинаю класс - все public. Если в какой-то момент чувствую что-то пошло не так - вот тогда закрываю члены в private и дописываю нужные геттеры/сеттеры. Казалось бы, почему не "сделать сразу правильно" - все private. Такая приватность часто оказывается "псевдо", фактически public, формально прикрытый get/set

[_Bers]

Зачем собственно в хедерах приватные функции?
Краеугольный камень ООП, скрыть реализацию. Реализация, как правило, в протектед и в приват. Если с протектед все понятно, то зачем же сувать приватные функции в хеадер. Они спокойно могли бы жить в cpp.

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

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

однако инкапсуляция не ставит перед собой цель эти самые детали скрыть.

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

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

[qate]

Зачем собственно в хедерах приватные функции?

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

[Johnik]

Вы мне привели идеологию Qt.

Не было такого, я писал: "PIMPL, в Qt этот паттерн активно используется."
Просто в Qt уже есть удобный набор средств для использования этого паттерна. Пишите свои методы, не будете ни от кого зависеть.

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

У меня для этого визард есть, все делается очень быстро.

Ничего там не прячется. Вы клиент Qt, и что? От вас прячется реализация приватных классов? Каким образом?

Как минимум, в IDE "автодополнятор" видит только то что нужно, без всякого приватного "мусора".

[Racheengel]

Считаю, что приватные методы - это излишество языка.
public и protected вполне достаточны для поддержки ООП-идеологии.
Наличие private на практике только мешает - иначе бы не было введено костыля типа friend-классов.

[qate]

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

как быть, если надо закрыть потомкам приватную часть предка ?

[Racheengel]

как быть, если надо закрыть потомкам приватную часть предка ?

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

[sergek]

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

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

[_Bers]

как быть, если надо закрыть потомкам приватную часть предка ?

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

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