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

[Old]

Так вот, неоднократно замечал что рез-т выходит "наоборот".

Как вы можете заметить результат, если вы часто не в состоянии оценить другое решение?
Заявление по поводу: "недостаток техники компенсируется удачной архитектурой" развеселил совсем и сразу вспомнился класс MainWindow с более 200 методами, который получился после "удачного" рефакторинга.
В общем, традиционное заявление: "Быдлокодеры круче всех. Не надо учиться, все равно вас наймут на работу, пусть она и будет меняться, каждые три месяца".

[Racheengel]

Считаю, что Игорь практически во всем тут прав. Я насмотрелся в своей жизни и быдлокода, от которого глаза вырвать хочется, и СуперПуперКаноничъногоТруъКода "по всем аналам" теории (от которого хочется примерно того же самого). Как правило, ТруъКаноничныйъКодъ удивительно нежизеспособен из-за абстрагирования его от предметной области. Когда такой вот мегакод приходится саппортить другому программисту, и он понимает, что все члены класса были по непонятным причинам засунуты в приват-секцию (просто так, без объяснения причин, хотя их часто и нет - "ведь в книжке написано, что члны класса должны быть приватными"), ему остается только или переписывать половину кода, или быдлокодить, если на п.1 нет времени или исходников...

[Old]

Считаю, что Игорь практически во всем тут прав. Я насмотрелся в своей жизни и быдлокода, от которого глаза вырвать хочется, и СуперПуперКаноничъногоТруъКода "по всем аналам" теории (от которого хочется примерно того же самого). Как правило, ТруъКаноничныйъКодъ удивительно нежизеспособен из-за абстрагирования его от предметной области. Когда такой вот мегакод приходится саппортить другому программисту, и он понимает, что все члены класса были по непонятным причинам засунуты в приват-секцию (просто так, без объяснения причин, хотя их часто и нет - "ведь в книжке написано, что члны класса должны быть приватными"), ему остается только или переписывать половину кода, или быдлокодить, если на п.1 нет времени или исходников...

Я тоже насмотрелся за свои 30 лет в отрасли, и именно поэтому стараюсь все делать правильно в меру своих знаний. Поэтому, предлагать отказаться от приватных секций, по причине того что быдлокодеры не правильно ей пользуются, явно избыточно.
Скорее их надо учить, а пока они учаться разрабатывать прототипы классов за них. Вот я занимаюсь архитектурными решениями и сам пишу хедер-файл с классом, где расписываю все от имен до constов. Дальше отдаю его одному из своих программистов с подробным объяснением что он должен делать. А потом начинаются "циклы" - он мне рассказывает как он это будет делать, а я говорю свое мнение по этому. Только так. По другому они могут писать только в корзину. Кто более менее чему-то научился начинают работать группками, но все равно под постоянным контроллем.
Менеджмент отказывается нанимать специалистов, им проще брать средних программистов ведрами за еду.

[Racheengel]

конкретно const_cast это и есть удачная архитектура ? )

А ведь в моей практике был именно такой случай.... Пришло однажды на фирму "Светило ООП",  которое должно было разработать концептуальную архитектуру будущего фреймворка. Ваяло светило долго и вдумчиво, и в какой-то момент поделка разрослась до несколько тысяч классов, многие из которых юзали один базовый метод, определенный светилом как const. До поры до времни всех устраивало, пока не выяснилось, что в данном методе в некоторых порожденных классах ну просто необходимо  менять состояние объекта.... Просто Светило ООП не особо представляло себе, что проект так разрастется Причем, необходимость изменения состояния возникла в одном из классов, созданных данным Светилом... И оно таки понапихало в итоге  const_castoв и объявило это "особенностью архитектуры"...

[Old]

А ведь в моей практике был именно такой случай.... Пришло однажды на фирму "Светило ООП",  которое должно было разработать концептуальную архитектуру будущего фреймворка. Ваяло светило долго и вдумчиво, и в какой-то момент поделка разрослась до несколько тысяч классов, многие из которых юзали один базовый метод, определенный светилом как const. До поры до времни всех устраивало, пока не выяснилось, что в данном методе в некоторых порожденных классах ну просто необходимо  менять состояние объекта.... Просто Светило ООП не особо представляло себе, что проект так разрастется Причем, необходимость изменения состояния возникла в одном из классов, созданных данным Светилом... И оно таки понапихало в итоге  const_castoв и объявило это "особенностью архитектуры"...

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

[Igors]

...и он понимает, что все члены класса были по непонятным причинам засунуты в приват-секцию (просто так, без объяснения причин, хотя их часто и нет - "ведь в книжке написано, что члны класса должны быть приватными"), ему остается только или переписывать половину кода, или быдлокодить, если на п.1 нет времени или исходников...

Мой любимый пример

Код:

int & QPoint::rx()

Вот гениальное решение троллей! И волки сыты (все private), и овцам хорошо (доступ есть!). Полагаю начальник им просто сказал: "да, оно конечно по смыслу public, но сделайте private чтобы не было ненужных вопросов/дебатов"

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

[Old]

Мой любимый пример

Что тут можно сказать: все ошибаются и Тролли не были исключением.

[Racheengel]

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

Отнюдь. C++ дает прекрасную возможность по сокрытию данных с помощью protected-секции. Этим самым поддерживается и инкапсуляция данных, т.к. все, что не является публичным интерфейсом, закрыто для внешнего использования, и возможность наследования. private же грубо нарушает этот принцип, поскольку не обеспечивает обратной связи потомка с предком. После подобных "светил инкапсуляции и гур полиморфизма" и появляются конструкции вроде #define private protected (да, видел такое не раз).

Я просил уже привести пример преимущества использования private перед protected (пусть даже искусственно созданный). Если никто не в состоянии этого сделать - возникает вопрос, а так ли данная фича необходима?

Кстати возможно, что проект развалился бы раньше, если бы этот метод изначально был объявлен без const.

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

[Igors]

Я просил уже привести пример преимущества использования private перед protected (пусть даже искусственно созданный). Если никто не в состоянии этого сделать - возникает вопрос, а так ли данная фича необходима?

Не жульничайте Вы прекрасно понимаете что не все может быть показано примерами, есть и концептуальные вещи. Библия говорит что protected члены гораздо больше "подвержены злоупотреблениям". Рез-т отказа от private явно отрицательный, побуждает к интенсивному наследованию - ведь оно становится легким и легальным решением всех проблем. Но опять-таки, Вам прекрасно известно сколь часто наследование бывает неудачным. Как раз private это и пресекает и заставляет искать др решения которые часто оказываются лучше. Напр посылка ивента (вместо того чтобы лезть грязными руками).

"А что же делать если вот НАДО изменить, в оно (зараза) private  ". Ну значит кто-то из двоих неправ (и необязательно Вы). По крайней мере, проблема четко обнаружена

[Old]

После подобных "светил инкапсуляции и гур полиморфизма" и появляются конструкции вроде #define private protected (да, видел такое не раз).

Это не проблема языка, это проблема средних специалистов, которые не умеют им пользоваться. Глупо ломать язык, что бы у кого-то лучше получалось им пользоваться.
А вот для интереса, сколько раз вам приходилось применять подобные хаки с define при работе с Qt? А его разработчики очень активно пользуются private. А я и при наследовании часто использую квалификаторы отличные от public.

Я просил уже привести пример преимущества использования private перед protected (пусть даже искусственно созданный). Если никто не в состоянии этого сделать - возникает вопрос, а так ли данная фича необходима?

А так ли необходимы темплейты, итераторы, исключения? Спросите здесь на форуме.

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

Все ошибаются. Да.
Но это не повод менять язык.

[Racheengel]

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

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

А вот для интереса, сколько раз вам приходилось применять подобные хаки с define при работе с Qt? А его разработчики очень активно им пользуются. А я и при наследовании часто использую квалификаторы отличные от public.

Ну кутишники на самом деле многие вещи сделали достаточно хорошо расширяемыми. Хотя, иногда приходится обходить кривые места, особенно когда нужна собственная отрисовка, например. Иногда проще с нуля виджет накрапать, чем расширить готовый (опять же, слава богу, не часто, но все же).

А так ли необходимы темплейты, итераторы, исключения?

Все хорошо в меру. Без темплейтов трудновато бы было создавать контейнеры, без итераторов - ходить по ним. Исключения - вещь несколько спорная (знаю фирмы, в которых было в Code Guidelines строжайше запрещено юзать исключения), но в принципе идея их применения неплоха.

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

Все ошибаются. Да.
Но это не повод менять язык.

Почему же? Если некоторые вещи непродуманы и приводят к проблемам - их надо пересматривать.

[Old]

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

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

Почему же? Если некоторые вещи непродуманы и приводят к проблемам - их надо пересматривать.

Эти вещи не нужны вам - не пользуйтесь, но оставьте мне возможность решать их надобность для меня.

[Racheengel]

Почему, для тех кто не злоупотребляет эту возможность нужно убрать?

Потому, что она ПОТЕНЦИАЛЬНО опасна и проблем от (заведомо неправильного, или неспрогнозированного) использования будет гораздо больше, чем профита (в чем профит,  кстати, так никто объяснить внятно до сих пор и не смог).

Я приведу пример из реального мира - private это как смартфон с неснимаемым корпусом. Т.е. вы не можете ни аккумулятор поменять, если он сдох, ни карту памяти заменить - ничего. Выхода в итоге два - либо купить новый телефон, либо отнести в сервисник типа "дядя Вася в подвале", который что-то, вероятно, захакает (а может, и нет, если все намертво залито компаундом). Какие от этого профиты для ПОЛЬЗОВАТЕЛЯ?

[Old]

Почему, для тех кто не злоупотребляет эту возможность нужно убрать?

Потому, что она ПОТЕНЦИАЛЬНО опасна и проблем от (заведомо неправильного, или неспрогнозированного) использования будет гораздо больше, чем профита (в чем профит,  кстати, так никто объяснить внятно до сих пор и не смог).

Я приведу пример из реального мира - private это как смартфон с неснимаемым корпусом. Т.е. вы не можете ни аккумулятор поменять, если он сдох, ни карту памяти заменить - ничего. Выхода в итоге два - либо купить новый телефон, либо отнести в сервисник типа "дядя Вася в подвале", который что-то, вероятно, захакает (а может, и нет, если все намертво залито компаундом). Какие от этого профиты для ПОЛЬЗОВАТЕЛЯ?

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

[Racheengel]

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