Форум программистов, компьютерный форум CyberForum.ru

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

Восстановить пароль Регистрация
 
 
Рейтинг: Рейтинг темы: голосов - 11, средняя оценка - 4.64
Nishen
 Аватар для Nishen
171 / 77 / 28
Регистрация: 26.02.2015
Сообщений: 455
09.07.2015, 18:43     Пишем свой класс, спецификатор доступа protected #1
Всем привет!
Из книги Р. Лафоре относительно спецификатора доступа protected:
Таким образом, если вы пишете класс, который впоследствии будет использоваться как базовый класс при наследовании, то данные, к которым нужно будет иметь доступ, следует объявлять как protected.
Далее пишется следующее:
Существуют и недостатки использования спецификатора доступа protected... это делает члены, объявленные как protected, значительно менее защищенными, чем объявленные как private.
Возникает вопросы: так когда же стоит использовать protected? Как я могу знать, захочет ли кто-нибудь использовать мой класс, как базовый? И как не доиграться со спецификаторами доступа? Как быть, если я хочу использовать чужой класс, но поля класса закрыты спецификатором private?
После регистрации реклама в сообщениях будет скрыта и будут доступны все возможности форума.
Mr.X
Эксперт С++
 Аватар для Mr.X
2799 / 1575 / 246
Регистрация: 03.05.2010
Сообщений: 3,657
10.07.2015, 00:21     Пишем свой класс, спецификатор доступа protected #21
Цитата Сообщение от xEmpire Посмотреть сообщение
суперкласса
Цитата Сообщение от hoggy Посмотреть сообщение
суперкласса
В С++ нету таких словей.
После регистрации реклама в сообщениях будет скрыта и будут доступны все возможности форума.
ct0r
C++/Haskell
 Аватар для ct0r
1549 / 568 / 39
Регистрация: 19.08.2012
Сообщений: 1,174
Завершенные тесты: 1
10.07.2015, 03:13     Пишем свой класс, спецификатор доступа protected #22
Цитата Сообщение от hoggy Посмотреть сообщение
суть инкапсуляции:
возможность использовать функционал без необходимости знать детали внутренней реализации.
(нам не нужно знать какие есть данные-члены у суперкласса, что бы дергать его методы)
Забавно, что часто приходится узнавать детали внутренней реализации и при инкапсуляции в коде. Отголоски закона дырявых абстракций.

Цитата Сообщение от hoggy Посмотреть сообщение
суть инварианта:
компонент гарантирует стабильность своей работы (отсутствие крашей, утечек ресурсов и тп),
независимо от корректности вызывающей стороны.
Что такое инвариант - всем понятно. А вот что обозначает словосочетание "суть инварианта" - мне неведомо. Тем более что компонент не обязан гарантировать сохранение своих инвариантов всегда. Соблюдение инвариантов вполне может зависеть от каких-то внешних условий.

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

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

Цитата Сообщение от hoggy Посмотреть сообщение
архитектура, которая состоит из компонентов,
которые никому ничего не гарантирует - подвережна многочисленным ошибкам.
плохо расширяется. хрупкая (плохо переносит изменения), и тп.
Ну "никому ничего" - это уже преувеличение. Компоненты всегда будут что-то гарантировать при выполнении определенных предусловий.
hoggy
5225 / 2116 / 403
Регистрация: 15.11.2014
Сообщений: 4,800
Завершенные тесты: 1
10.07.2015, 06:15     Пишем свой класс, спецификатор доступа protected #23
Цитата Сообщение от ct0r Посмотреть сообщение
Отголоски закона дырявых абстракций.
что это за закон такой?

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

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

Цитата Сообщение от ct0r Посмотреть сообщение
невыполнение предусловий ведет к неопределенному поведению.
порочная практика.

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

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

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

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

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

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

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

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


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

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

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

вдумайтесь в эту фразу:
способность гарантировать стабильность своей работы не зависимо от корректности вызывающей стороны.
Voivoid
 Аватар для Voivoid
580 / 256 / 12
Регистрация: 31.03.2013
Сообщений: 1,284
10.07.2015, 07:18     Пишем свой класс, спецификатор доступа protected #24
Цитата Сообщение от ct0r Посмотреть сообщение
Очень часто, чтобы не чесать правое ухо левой пяткой, при модульном тестировании нужные private-члены делаются public-членами с соответствующим комментарием, что, мол, это только для тестовых целей.
А разгадка проста - в этом классе нарушен single responsibility principle и/или не используется dependency injection.
egor2116
 Аватар для egor2116
337 / 368 / 42
Регистрация: 20.01.2013
Сообщений: 1,100
10.07.2015, 09:29     Пишем свой класс, спецификатор доступа protected #25
Еще одна глупость этого Лафоре.
Хотелось бы Вашу книжку прочесть
Mr.X
Эксперт С++
 Аватар для Mr.X
2799 / 1575 / 246
Регистрация: 03.05.2010
Сообщений: 3,657
10.07.2015, 09:51     Пишем свой класс, спецификатор доступа protected #26
Цитата Сообщение от egor2116 Посмотреть сообщение
Хотелось бы Вашу книжку прочесть
Т.е. все, кто еще не написал книжки, должны восторгаться придурком Лафоре?
Чтобы судить о вкусе омлета не обязательно уметь нести яйца.
egor2116
 Аватар для egor2116
337 / 368 / 42
Регистрация: 20.01.2013
Сообщений: 1,100
10.07.2015, 09:56     Пишем свой класс, спецификатор доступа protected #27
Т.е. все, кто еще не написал книжки, должны восторгаться придурком Лафоре?
Да я не предлагаю ни кем восторгаться. Вы просто очень категоричны. Вы пишите программы без ошибок и все ими восторгаются, и не у кого нет мнения что какую нибудь часть можно было реализовать по другому не так как у Вас?
Mr.X
Эксперт С++
 Аватар для Mr.X
2799 / 1575 / 246
Регистрация: 03.05.2010
Сообщений: 3,657
10.07.2015, 10:12     Пишем свой класс, спецификатор доступа protected #28
Цитата Сообщение от egor2116 Посмотреть сообщение
Вы просто очень категоричны.
Да ладно! Лафоре полнейший невежда в той области, в которой он собрался учить других. Только от тех ляпов, что здесь на форуме процитированы, у нормального человека уши вянут, а ведь некоторые люди еще и специально засир@ют себе мозги, читая его дерьмокнижки.
egor2116
 Аватар для egor2116
337 / 368 / 42
Регистрация: 20.01.2013
Сообщений: 1,100
10.07.2015, 10:16     Пишем свой класс, спецификатор доступа protected #29
"Лафоре полнейший невежда в той области." "Только от тех ляпов"
Возможно, но нужно не забывать что данная литература является переводом и тут нужно обратить так же внимание на переводчика т.к. литература техническая и насыщена соответствующей терминологией, а также
у нормального человека уши вянут
человек который интересуется данной тематикой профессионально должен прочитать далеко не одного автора и не один раз.
Mr.X
Эксперт С++
 Аватар для Mr.X
2799 / 1575 / 246
Регистрация: 03.05.2010
Сообщений: 3,657
10.07.2015, 10:22     Пишем свой класс, спецификатор доступа protected #30
Цитата Сообщение от egor2116 Посмотреть сообщение
человек который интересуется данной тематикой профессионально должен прочитать далеко не одного автора и не один раз.
Однако это не причина читать придурков. Литературы самого высокого качества столько, что жизни не хватит, чтобы ее прочесть.
egor2116
 Аватар для egor2116
337 / 368 / 42
Регистрация: 20.01.2013
Сообщений: 1,100
10.07.2015, 10:34     Пишем свой класс, спецификатор доступа protected #31
Однако это не причина читать придурков.
Однако Вы должны согласится, что начинающему изучать данный ЯП, тяжело понять какой автор хорош, а какого не следует читать, пока начинающий не прочитает и не сравнит и не попробует на практике или не спросит совета форуме.
Я думаю все или большинство должны наступить и/или наступают на грабли, что бы понять что есть хорошо и правильно и почему именно так, а чего делать не стоит и почему, и к чему это может привести в дальнейшем.
Mr.X
Эксперт С++
 Аватар для Mr.X
2799 / 1575 / 246
Регистрация: 03.05.2010
Сообщений: 3,657
10.07.2015, 11:28     Пишем свой класс, спецификатор доступа protected #32
Цитата Сообщение от egor2116 Посмотреть сообщение
начинающему изучать данный ЯП, тяжело понять какой автор хорош
Умный человек или косящий под умного спросит и послушает умных и знающих, ну а некоторым, как известно, закон не писан.
egor2116
 Аватар для egor2116
337 / 368 / 42
Регистрация: 20.01.2013
Сообщений: 1,100
10.07.2015, 11:32     Пишем свой класс, спецификатор доступа protected #33
спросит и послушает
умных и знающих или косящих под умных и знающих, но навряд ли поймет, почему нужно делать именно так, а не как то по другому, это он сможет понять только с опытом.
ct0r
C++/Haskell
 Аватар для ct0r
1549 / 568 / 39
Регистрация: 19.08.2012
Сообщений: 1,174
Завершенные тесты: 1
10.07.2015, 11:44     Пишем свой класс, спецификатор доступа protected #34
Цитата Сообщение от hoggy Посмотреть сообщение
что это за закон такой?
То есть вы даже Джоэла Сполски не читали? А гуглить умеете? Первая ссылка в поиске.

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

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

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

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

Цитата Сообщение от hoggy Посмотреть сообщение
препроцессор.
дефайн-паблик-морозов.
Эээ, нет, благодарю

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

Цитата Сообщение от hoggy Посмотреть сообщение
видно вы действительно так и не поняли сути инварианта.
вдумайтесь в эту фразу:
В огороде бузина, а в Киеве дядька? Ваш ответ на мою цитату ассоциируется с ней чуть меньше, чем никак.

Цитата Сообщение от Voivoid Посмотреть сообщение
А разгадка проста - в этом классе нарушен single responsibility principle и/или не используется dependency injection.
Если в классе есть куча сильно связанных между собой данных, которые должны находиться в определенном согласованном состоянии, то что тогда? Еще не стоит забывать про тот факт, что хоть SRP и DI это хорошо, но слепое следование им может породить кучу мелких сущностей, которые в принципе не так уж и нужны, а только раздувают код, уменьшая понятность и читабельность.
Voivoid
 Аватар для Voivoid
580 / 256 / 12
Регистрация: 31.03.2013
Сообщений: 1,284
10.07.2015, 11:52     Пишем свой класс, спецификатор доступа protected #35
Цитата Сообщение от ct0r Посмотреть сообщение
Если в классе есть куча сильно связанных между собой данных, которые должны находиться в определенном согласованном состоянии, то что тогда?
Под такой формулировкой может скрываться все что угодно, надо смотреть код

Цитата Сообщение от ct0r Посмотреть сообщение
а только раздувают код, уменьшая понятность и читабельность.
Только если не получается или же лень давать сущностям адекватные имена
Avazart
 Аватар для Avazart
6900 / 5140 / 252
Регистрация: 10.12.2010
Сообщений: 22,580
Записей в блоге: 17
10.07.2015, 12:34     Пишем свой класс, спецификатор доступа protected #36
Цитата Сообщение от egor2116 Посмотреть сообщение
Хотелось бы Вашу книжку прочесть
Просто у человека который прочел больше чем одну книжку есть с чем сравнить (например с Маерсом,Саттером,Александреску итд).
egor2116
 Аватар для egor2116
337 / 368 / 42
Регистрация: 20.01.2013
Сообщений: 1,100
10.07.2015, 12:36     Пишем свой класс, спецификатор доступа protected #37
Просто у человека который прочел больше чем одну книжку
Об этом так же шел разговор выше, если бы вы его прочитали, а не взяли первое попавшееся сообщение.
Avazart
 Аватар для Avazart
6900 / 5140 / 252
Регистрация: 10.12.2010
Сообщений: 22,580
Записей в блоге: 17
10.07.2015, 12:41     Пишем свой класс, спецификатор доступа protected #38
Цитата Сообщение от ct0r Посмотреть сообщение
Порочная практика - это фиксить изнутри вызывающую сторону, маскируя ее баги.
О чем конкретно речь? Что-то можно фиксить/инорирвать что происходит из ошибок изнутри ибо в контексте этого объекта это не ошибка, а нормальное поведение, а что-то приводит к тому что нужно изменять описание ошибки и пробрасывать выше это все сугубо от задачи.
Но тупо "оставлять как есть" вероятно допустимо только на этапе "сырой/первичной" разработки и то только когда не понятно что есть что.

Добавлено через 1 минуту
Цитата Сообщение от egor2116 Посмотреть сообщение
Об этом так же шел разговор выше, если бы вы его прочитали, а не взяли первое попавшееся сообщение.
Ну так чему вопросы и сомнения о дурке с паблик данными в Лафоре?
egor2116
 Аватар для egor2116
337 / 368 / 42
Регистрация: 20.01.2013
Сообщений: 1,100
10.07.2015, 12:47     Пишем свой класс, спецификатор доступа protected #39
Ну так чему вопросы
Да в общем то разговор исчерпал себя.
Вообще то как я понял речь шла про protected поля у базового класса и мое общение с Mr.X было связано не с этим, а с автором этого учебника, но как я сказал наш разговор с ним себя исчерпал.
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
10.07.2015, 14:44     Пишем свой класс, спецификатор доступа protected
Еще ссылки по теме:

Спецификатор доступа и виртуальные функции C++
C++ пишем свой троян с нуля
Пишем свой чекер C++

Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
ct0r
C++/Haskell
 Аватар для ct0r
1549 / 568 / 39
Регистрация: 19.08.2012
Сообщений: 1,174
Завершенные тесты: 1
10.07.2015, 14:44     Пишем свой класс, спецификатор доступа protected #40
Цитата Сообщение от Voivoid Посмотреть сообщение
Только если не получается или же лень давать сущностям адекватные имена
Дело не столько в именовании. Больше классов - больше надо держать в памяти (какие-то их особенности, exception safety, etc) - больше файлов - сложнее физическая структура проекта - труднее навигация (особенно в условиях отсутствия возможности использования IDE или на проекте, использующем bjam для сборки). Каждая ситуация по-своему уникальна, и делать SRP и DI догмами не стоит.

Цитата Сообщение от Avazart Посмотреть сообщение
О чем конкретно речь? Что-то можно фиксить/инорирвать что происходит из ошибок изнутри ибо в контексте этого объекта это не ошибка, а нормальное поведение, а что-то приводит к тому что нужно изменять описание ошибки и пробрасывать выше это все сугубо от задачи.
Но тупо "оставлять как есть" вероятно допустимо только на этапе "сырой/первичной" разработки и то только когда не понятно что есть что.
Я не совсем понял, что ты имеешь в виду, но речь вот о чем. Предположим, что у нас есть класс даты. Мы можем. Либо все время проверять дату на валидность и не допускать левых дат. Либо создать контракт использования класса, contract violation оставить ведущим к UB, повтыкать ассертов, наплевать на нарушение инвариантов в релизе. Я считаю, что оба подхода нормальны и имеют право на применение, в зависимости от ситуации. hoggy активно продвигает первый вариант с сохранением инвариантов всегда. Либо он не различает терминологию. Либо выражает свою мысль неясно.
Yandex
Объявления
10.07.2015, 14:44     Пишем свой класс, спецификатор доступа protected
Ответ Создать тему
Опции темы

Текущее время: 18:10. Часовой пояс GMT +3.
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2016, vBulletin Solutions, Inc.
Рейтинг@Mail.ru