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

[AzazelloAV]

Удалено

[_Bers]

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

1.
мы ничего такого не сообщаем компилятору.

2.
mutable? не, не слышал.
const_cast? не, не слышал.

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

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

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

[_Bers]

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

именно так.
именно с этой целью это и было сделанно.

попытка исправить говнокод за счет костылей в потомке - ещё больший говнокод.

[_Bers]

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

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

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

я хочу сказать, данная порочная практика от быдлокодера - не есть "хорошо".

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

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

[Racheengel]

1.
мы ничего такого не сообщаем компилятору.

Эх... не люблю телеги постить...

If an object is declared const, then (ISO/IEC 14882:2003 7.1.5.1(4)):

Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const object during its lifetime (3. results in undefined behavior.
Lets disregard objects that may have mutable members - the compiler is free to assume that the object will not be modified, therefore it can produce significant optimizations. These optimizations can include things like:

incorporating the object's value directly into the machines instruction opcodes
complete elimination of code that can never be reached because the const object is used in a conditional expression that is known at compile time
loop unrolling if the const object is controlling the number of iterations of a loop

2.
mutable? не, не слышал.
const_cast? не, не слышал.

Я про это писал. Жаль, что не слышали. У Страуструпа расписано.

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

Строго говоря, язык c++ не является необходимым, можно писать на ассемблере. И забыть про говнокод.

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

См.выше

[Racheengel]

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

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

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

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

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

[Igors]

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

Ну такая тональность хорошо известна. Вот напр (с др форума)

Когда это ООП успела стать новой парадигмой, и когда С++ перестал быть самой убогой реализацией ООП? Я бы ещё понял, если бы ТС заговорил о языках программирования типа Piet, но ООП в С++ без мультиметодов, зато со всякими ужасами, это...

Ах какой "продвинутый". Это вы тут паритесь с каким-то старьем - а он впереди планеты всей.

[_Bers]

Эх... не люблю телеги постить...

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

Строго говоря, язык c++ не является необходимым, можно писать на ассемблере. И забыть про говнокод.

тем не менее он используется.
и умеет private, и это не с проста.
это нужно для поддержки механизма инкапсуляции.
которая является одним из столпов на котором жиздеццо ООП.

вам осталось лишь понять, что это такое "инкапсуляция",
и зачем это нужно.

[_Bers]

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

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

(примичание: c++11 ввели дополнительное ключевое слов final, которое запрещает наследование.
в с++03 приходилось использовать особые трюки, что бы запретить наследование.
модификатор доступа private сам по себе наследоваться не запрещает)

защиту ставаят не просто так.

А потом решит проблему копипастом и построит "второй тоннель",  по вашему это нормально???

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

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

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

Код:

struct base
{
    virtual ~base(){}
    virtual work(int param)const = 0;  //<--- квалификатор
};

struct der: base
{
    virtual work(int param){ ... }  //<--- я хотеть без квалификатора!!!!
      //мой метод будет менять состояние наследника!!!!
};

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

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

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

[_Bers]

ООП задумывался для проектирования расширяемых приложений.

ОО-парадигма получила широчайшее распространение
потому что полностью отвечала требованиям бизнеса:
потребность в командной разработке.

приход оо ознаменовал новую эпоху в истории индустрии:
командная разработка.

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

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

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

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

вы о своей личной практике?
потому что объективно, ооп поимело бешенный саккцесс стори.

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

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

[Racheengel]

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

Ну такая тональность хорошо известна. Вот напр (с др форума)

Когда это ООП успела стать новой парадигмой, и когда С++ перестал быть самой убогой реализацией ООП? Я бы ещё понял, если бы ТС заговорил о языках программирования типа Piet, но ООП в С++ без мультиметодов, зато со всякими ужасами, это...

Ах какой "продвинутый". Это вы тут паритесь с каким-то старьем - а он впереди планеты всей.

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

[Racheengel]

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

Угу, угу... Слив защитан

потому что объективно, ооп поимело бешенный саккцесс стори.

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

20 лет было легко, и вдруг стало сложно Спасибо, поржал.

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

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

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

У вас что, так именно и было, да? Вы страдали от того, что коллеги не разделяли ваше желание все члены классов позасовывать в приваты и наделать геттеро-сеттеров? Сочувствую...

ОО-парадигма получила широчайшее распространение
потому что полностью отвечала требованиям бизнеса:
потребность в командной разработке.

приход оо ознаменовал новую эпоху в истории индустрии:
командная разработка.

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

А, ну да. До появления ООП и программирования-то не было. Бедные Страуструс с Виртом обливались слезами, когда кодили на С и Паскале и все ждали - боже, ниспошли нам Концептуальную Парадигму, чтобы мы прозрели

Вы знаете, есть большое различие между теорией и практикой. В вашем академическом мире все выглядит научно, красиво и безглючно. Ведь умные люди написали очень много умных книг, читай не хочу. И в книгах этих все прекрасно, приведены фрагменты Идеального Кода, описаны Правильные Паттерны, даны Рекомендации На Все Случаи Жизни. Все пропитано духом Инкапсуляций, Полиморфизма, Инвариантов (тут еще 100500 умных слов). Объектная модель непогрешима, интерфейсы лаконичны и однозначны, данные гомогенны, ВсеКакДолжноБыть. Просто прелесть и рай земной.

И тут приходит Продакшен... Вы видели легаси С-код, написанный в стиле спагетти на основе WinApi и портированный на С++ для того, чтобы обеспечить кроссплатформенность? А сторонние промышленные библиотеки, сочетающие в себе куски 30-летней давности и поддежку C++11? А полиморфизм на уровне C-функций? Множественное наследование, построенное на темплейтах, которые специализируются под каждый определенный класс? И ведь все это должно работать, причем максимально быстро, стабильно, не вылетать по причине null pointer assignment и нехватки памяти в самых неожиданных местах. И очень часто по причине того, что людям хочется сделать собственный велосипед, потому что "в умной книге был описан СуперМегаПаттерн" и они лепят его из подручных средств, не задумываясь о том, как это, собственно, будет использоваться в будущем.

Или код из серии "Так, вот тут вот надо, чтобы порядок вызова был именно такой и никакой иначе, а то функция вернет 0, а не 1... Не дай бог мой метод вызовут извне с другим энвайронментом... О! Бинго!! Захерячим его в приват!!! Решено!" Вот подобные возможности языка и порождают потом варианты с const_cast-ами и другими аналогичными методами обхода быдлокода (хотя сами при этом становятся быдлокодом).

Или мы наваяем write-only шаблон, который теоретически мог бы работать с классом А, если бы он наследовался от Б, но его надо использовать только с В, потому что в Б у нас метод DoSomeShit объявлен константным, хотя шаблон предполагает изменение некоторых состояний объекта, а В - это вынужденная копия А, только DoSomeShit там не конст...

Когда приходится поддерживать и расширять подобный код - тут и наступает ад. Но в Умных Книгах про это не пишут...

[_Bers]

Угу, угу... Слив защитан

детский сад.

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

верно.
поэтому я и предложил вам включить мозг,
и ознакомиться с понятием "инкапсуляции",
и не пороть чушь, как в #10

[Igors]

Вот допустим есть 2 программиста (или даже 2 команды). Первый четко следует всем канонам, активно применяет паттерны и крутые либы. Второй... та просто "быдлокодер", лепит const_cast, классы у него просто struct и.т.п.

Так вот, неоднократно замечал что рез-т выходит "наоборот". Недостаток техники может с лихвой компенсироваться более глубоким знанием предметной части, желанием с ней работать и, как следствие, более удачной архитектурой. Напротив, академический знаток часто чрезмерно увлекается абстракцией и в результате поверхностно относится к задаче. Другая болезнь (за)Знаек - "перфекционизм" и отсутствие гибкости, типа "вот это должно быть private - и точка!". Такая "нетолерантность к говнокоду" особенно болезненна когда выплывает ряд доделок/переделок которые, увы, часто вдребезги разбивают изначально такой стройный замысел. И еще весьма неприятный плюс (точнее минус): да-да, вот то самое "пороть чушь", "включить мозги" и.т.п. В душе каждый считает себя самым умным (иначе это не программист), но у одних хватает ума это не демонстрировать, а у других нет. 

Конечно я не призываю быдлокодить, лучше быть "богатым и здоровым" 

[qate]

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

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