Пишем свой класс, спецификатор доступа protected

Всем привет!
Из книги Р. Лафоре относительно спецификатора доступа protected:

Таким образом, если вы пишете класс, который впоследствии будет использоваться как базовый класс при наследовании, то данные, к которым нужно будет иметь доступ, следует объявлять как protected.

Далее пишется следующее:

Существуют и недостатки использования спецификатора доступа protected... это делает члены, объявленные как protected, значительно менее защищенными, чем объявленные как private.

Возникает вопросы: так когда же стоит использовать protected? Как я могу знать, захочет ли кто-нибудь использовать мой класс, как базовый? И как не доиграться со спецификаторами доступа? Как быть, если я хочу использовать чужой класс, но поля класса закрыты спецификатором private?

0

Сообщение от xEmpire суперкласса

Сообщение от hoggy суперкласса

В С++ нету таких словей.

0

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

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

Сообщение от hoggy суть инварианта: компонент гарантирует стабильность своей работы (отсутствие крашей, утечек ресурсов и тп), независимо от корректности вызывающей стороны.

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

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

Далеко не всегда так названный "инвариантный компонент" - это хорошо. Все зависит от ситуации. Иногда очень удобно и полезно забить на инварианты и сделать DbC (Design by Contract), подразумевая, что невыполнение предусловий ведет к неопределенному поведению. Это предотвращает маскировку багов и делает код более быстрым. Иногда наоборот, стоит последовать принципам DP (Defensive Programming) и повтыкать ассерты и рантайм-проверки там, где ожидается неправильное использование функционала. Не стоит думать за всех и во всех ситуациях стараться сохранить инварианты любой ценой.

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

Все эти формальные слова private, protected, public и налагаемые ими ограничения - фигня. По сути их можно читать как просто документацию от проектировщика класса. Очень часто, чтобы не чесать правое ухо левой пяткой, при модульном тестировании нужные private-члены делаются public-членами с соответствующим комментарием, что, мол, это только для тестовых целей.

Сообщение от hoggy архитектура, которая состоит из компонентов, которые никому ничего не гарантирует - подвережна многочисленным ошибкам. плохо расширяется. хрупкая (плохо переносит изменения), и тп.

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

0

Сообщение от ct0r Отголоски закона дырявых абстракций.

что это за закон такой?

Сообщение от ct0r Что такое инвариант - всем понятно. А вот что обозначает словосочетание "суть инварианта" - мне неведомо.

суть понятия.

Сообщение от ct0r Далеко не всегда так названный "инвариантный компонент" - это хорошо. Все зависит от ситуации.

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

Сообщение от ct0r невыполнение предусловий ведет к неопределенному поведению.

порочная практика.

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

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

но на бою такого быть не должно.

Сообщение от ct0r Не стоит думать за всех и во всех ситуациях стараться сохранить инварианты любой ценой.

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

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

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

существует несколько техник на этот случай:

1.
уродливые имена функций, которые завершаются подчеркиванием.
(действует прицип привентивной защиты:
сделайте так, что бы использовать механизм неправильно было неудобно)

2.
препроцессор.
дефайн-паблик-морозов.


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

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

Сообщение от ct0r Ну "никому ничего" - это уже преувеличение. Компоненты всегда будут что-то гарантировать при выполнении определенных предусловий.

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

вдумайтесь в эту фразу:

способность гарантировать стабильность своей работы не зависимо от корректности вызывающей стороны.

0

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

А разгадка проста - в этом классе нарушен single responsibility principle и/или не используется dependency injection.

0

Еще одна глупость этого Лафоре.

Хотелось бы Вашу книжку прочесть

0

Сообщение от egor2116 Хотелось бы Вашу книжку прочесть

Т.е. все, кто еще не написал книжки, должны восторгаться придурком Лафоре?
Чтобы судить о вкусе омлета не обязательно уметь нести яйца.

0

Т.е. все, кто еще не написал книжки, должны восторгаться придурком Лафоре?

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

0

Сообщение от egor2116 Вы просто очень категоричны.

Да ладно! Лафоре полнейший невежда в той области, в которой он собрался учить других. Только от тех ляпов, что здесь на форуме процитированы, у нормального человека уши вянут, а ведь некоторые люди еще и специально засир@ют себе мозги, читая его дерьмокнижки.

0

"Лафоре полнейший невежда в той области." "Только от тех ляпов"

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

у нормального человека уши вянут

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

0

Сообщение от egor2116 человек который интересуется данной тематикой профессионально должен прочитать далеко не одного автора и не один раз.

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

1

Однако это не причина читать придурков.

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

0

Сообщение от egor2116 начинающему изучать данный ЯП, тяжело понять какой автор хорош

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

0

спросит и послушает

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

0

Сообщение от hoggy что это за закон такой?

То есть вы даже Джоэла Сполски не читали? А гуглить умеете? Первая ссылка в поиске.

Сообщение от hoggy порочная практика.

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

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

А кто-то предлагает убрать обработку ошибок? Или пренебрегает качеством? Я ничего такого не предлагал.

Сообщение от hoggy ассерт проверки в релизе не кушают. зато код читабельный, и спать можно спокойно.

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

Сообщение от hoggy уродливые имена функций, которые завершаются подчеркиванием. (действует прицип привентивной защиты: сделайте так, что бы использовать механизм неправильно было неудобно)

Этак я и тестирование сделаю неудобным. А кто захочет - подчеркивание все равно не проблема дописать.

Сообщение от hoggy препроцессор. дефайн-паблик-морозов.

Эээ, нет, благодарю

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

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

Сообщение от hoggy видно вы действительно так и не поняли сути инварианта. вдумайтесь в эту фразу:

В огороде бузина, а в Киеве дядька? Ваш ответ на мою цитату ассоциируется с ней чуть меньше, чем никак.

Сообщение от Voivoid А разгадка проста - в этом классе нарушен single responsibility principle и/или не используется dependency injection.

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

0

Сообщение от ct0r Если в классе есть куча сильно связанных между собой данных, которые должны находиться в определенном согласованном состоянии, то что тогда?

Под такой формулировкой может скрываться все что угодно, надо смотреть код

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

Только если не получается или же лень давать сущностям адекватные имена

0

Сообщение от egor2116 Хотелось бы Вашу книжку прочесть

Просто у человека который прочел больше чем одну книжку есть с чем сравнить (например с Маерсом,Саттером,Александреску итд).

0

Просто у человека который прочел больше чем одну книжку

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

0

Сообщение от ct0r Порочная практика - это фиксить изнутри вызывающую сторону, маскируя ее баги.

О чем конкретно речь? Что-то можно фиксить/инорирвать что происходит из ошибок изнутри ибо в контексте этого объекта это не ошибка, а нормальное поведение, а что-то приводит к тому что нужно изменять описание ошибки и пробрасывать выше это все сугубо от задачи.
Но тупо "оставлять как есть" вероятно допустимо только на этапе "сырой/первичной" разработки и то только когда не понятно что есть что.

Добавлено через 1 минуту

Сообщение от egor2116 Об этом так же шел разговор выше, если бы вы его прочитали, а не взяли первое попавшееся сообщение.

Ну так чему вопросы и сомнения о дурке с паблик данными в Лафоре?

0

Ну так чему вопросы

Да в общем то разговор исчерпал себя.
Вообще то как я понял речь шла про protected поля у базового класса и мое общение с Mr.X было связано не с этим, а с автором этого учебника, но как я сказал наш разговор с ним себя исчерпал.

0

Сообщение от Voivoid Только если не получается или же лень давать сущностям адекватные имена

Дело не столько в именовании. Больше классов - больше надо держать в памяти (какие-то их особенности, exception safety, etc) - больше файлов - сложнее физическая структура проекта - труднее навигация (особенно в условиях отсутствия возможности использования IDE или на проекте, использующем bjam для сборки). Каждая ситуация по-своему уникальна, и делать SRP и DI догмами не стоит.

Сообщение от Avazart О чем конкретно речь? Что-то можно фиксить/инорирвать что происходит из ошибок изнутри ибо в контексте этого объекта это не ошибка, а нормальное поведение, а что-то приводит к тому что нужно изменять описание ошибки и пробрасывать выше это все сугубо от задачи. Но тупо "оставлять как есть" вероятно допустимо только на этапе "сырой/первичной" разработки и то только когда не понятно что есть что.

Я не совсем понял, что ты имеешь в виду, но речь вот о чем. Предположим, что у нас есть класс даты. Мы можем. Либо все время проверять дату на валидность и не допускать левых дат. Либо создать контракт использования класса, contract violation оставить ведущим к UB, повтыкать ассертов, наплевать на нарушение инвариантов в релизе. Я считаю, что оба подхода нормальны и имеют право на применение, в зависимости от ситуации. hoggy активно продвигает первый вариант с сохранением инвариантов всегда. Либо он не различает терминологию. Либо выражает свою мысль неясно.

0