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

С++ для начинающих

Войти
Регистрация
Восстановить пароль
 
 
Рейтинг: Рейтинг темы: голосов - 11, средняя оценка - 4.64
Nishen
347 / 185 / 70
Регистрация: 26.02.2015
Сообщений: 908
#1

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

09.07.2015, 18:43. Просмотров 1797. Ответов 61
Метки нет (Все метки)

Всем привет!
Из книги Р. Лафоре относительно спецификатора доступа protected:
Таким образом, если вы пишете класс, который впоследствии будет использоваться как базовый класс при наследовании, то данные, к которым нужно будет иметь доступ, следует объявлять как protected.
Далее пишется следующее:
Существуют и недостатки использования спецификатора доступа protected... это делает члены, объявленные как protected, значительно менее защищенными, чем объявленные как private.
Возникает вопросы: так когда же стоит использовать protected? Как я могу знать, захочет ли кто-нибудь использовать мой класс, как базовый? И как не доиграться со спецификаторами доступа? Как быть, если я хочу использовать чужой класс, но поля класса закрыты спецификатором private?
0
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
09.07.2015, 18:43
Здравствуйте! Я подобрал для вас темы с ответами на вопрос Пишем свой класс, спецификатор доступа protected (C++):

Пишем свой чекер - C++
Я хочу написать свой чекер, но не знаю с чего начать? Кто знает основные принцип работы чекеров прошу объясните.

пишем свой троян с нуля - C++
Всем привет)))соглашусь, что изобретаю велосипед, но хочется сделать все своими ручками не прибегая к open source и т.п. для повышения...

Пишем свой интерпретатор языка BASIC - C++
***************** Благодаря форуму и Evg в частности интерпретатор развивается, потихоньку превращаясь в простенький интерпретатор...

Спецификатор доступа и виртуальные функции - C++
Как я понимаю, спецификатор доступа задается только в том классе, где функция объявляется виртуальной? Получается во время исполнения не...

Ключ доступа protected - C++
В каких случаях рекомендовано использовать этот ключ доступа? Если можно, то приведите примеры.:help:

protected или не protected : ) - C++
собстно не могу решить как поступить. есть абстрактный класс окошка, являющийся базовым для всех окошек. есть 3 варианта...

Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
egor2116
339 / 370 / 42
Регистрация: 20.01.2013
Сообщений: 1,123
10.07.2015, 10:34 #31
Однако это не причина читать придурков.
Однако Вы должны согласится, что начинающему изучать данный ЯП, тяжело понять какой автор хорош, а какого не следует читать, пока начинающий не прочитает и не сравнит и не попробует на практике или не спросит совета форуме.
Я думаю все или большинство должны наступить и/или наступают на грабли, что бы понять что есть хорошо и правильно и почему именно так, а чего делать не стоит и почему, и к чему это может привести в дальнейшем.
0
Mr.X
Эксперт С++
3049 / 1694 / 265
Регистрация: 03.05.2010
Сообщений: 3,867
10.07.2015, 11:28 #32
Цитата Сообщение от egor2116 Посмотреть сообщение
начинающему изучать данный ЯП, тяжело понять какой автор хорош
Умный человек или косящий под умного спросит и послушает умных и знающих, ну а некоторым, как известно, закон не писан.
0
egor2116
339 / 370 / 42
Регистрация: 20.01.2013
Сообщений: 1,123
10.07.2015, 11:32 #33
спросит и послушает
умных и знающих или косящих под умных и знающих, но навряд ли поймет, почему нужно делать именно так, а не как то по другому, это он сможет понять только с опытом.
0
ct0r
Игогошка!
1773 / 675 / 42
Регистрация: 19.08.2012
Сообщений: 1,287
Завершенные тесты: 1
10.07.2015, 11:44 #34
Цитата Сообщение от hoggy Посмотреть сообщение
что это за закон такой?
То есть вы даже Джоэла Сполски не читали? А гуглить умеете? Первая ссылка в поиске.

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

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

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

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

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

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

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

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

Цитата Сообщение от ct0r Посмотреть сообщение
а только раздувают код, уменьшая понятность и читабельность.
Только если не получается или же лень давать сущностям адекватные имена
0
Avazart
Эксперт С++
7191 / 5365 / 280
Регистрация: 10.12.2010
Сообщений: 23,673
Записей в блоге: 17
10.07.2015, 12:34 #36
Цитата Сообщение от egor2116 Посмотреть сообщение
Хотелось бы Вашу книжку прочесть
Просто у человека который прочел больше чем одну книжку есть с чем сравнить (например с Маерсом,Саттером,Александреску итд).
0
egor2116
339 / 370 / 42
Регистрация: 20.01.2013
Сообщений: 1,123
10.07.2015, 12:36 #37
Просто у человека который прочел больше чем одну книжку
Об этом так же шел разговор выше, если бы вы его прочитали, а не взяли первое попавшееся сообщение.
0
Avazart
Эксперт С++
7191 / 5365 / 280
Регистрация: 10.12.2010
Сообщений: 23,673
Записей в блоге: 17
10.07.2015, 12:41 #38
Цитата Сообщение от ct0r Посмотреть сообщение
Порочная практика - это фиксить изнутри вызывающую сторону, маскируя ее баги.
О чем конкретно речь? Что-то можно фиксить/инорирвать что происходит из ошибок изнутри ибо в контексте этого объекта это не ошибка, а нормальное поведение, а что-то приводит к тому что нужно изменять описание ошибки и пробрасывать выше это все сугубо от задачи.
Но тупо "оставлять как есть" вероятно допустимо только на этапе "сырой/первичной" разработки и то только когда не понятно что есть что.

Добавлено через 1 минуту
Цитата Сообщение от egor2116 Посмотреть сообщение
Об этом так же шел разговор выше, если бы вы его прочитали, а не взяли первое попавшееся сообщение.
Ну так чему вопросы и сомнения о дурке с паблик данными в Лафоре?
0
egor2116
339 / 370 / 42
Регистрация: 20.01.2013
Сообщений: 1,123
10.07.2015, 12:47 #39
Ну так чему вопросы
Да в общем то разговор исчерпал себя.
Вообще то как я понял речь шла про protected поля у базового класса и мое общение с Mr.X было связано не с этим, а с автором этого учебника, но как я сказал наш разговор с ним себя исчерпал.
0
ct0r
Игогошка!
1773 / 675 / 42
Регистрация: 19.08.2012
Сообщений: 1,287
Завершенные тесты: 1
10.07.2015, 14:44 #40
Цитата Сообщение от Voivoid Посмотреть сообщение
Только если не получается или же лень давать сущностям адекватные имена
Дело не столько в именовании. Больше классов - больше надо держать в памяти (какие-то их особенности, exception safety, etc) - больше файлов - сложнее физическая структура проекта - труднее навигация (особенно в условиях отсутствия возможности использования IDE или на проекте, использующем bjam для сборки). Каждая ситуация по-своему уникальна, и делать SRP и DI догмами не стоит.

Цитата Сообщение от Avazart Посмотреть сообщение
О чем конкретно речь? Что-то можно фиксить/инорирвать что происходит из ошибок изнутри ибо в контексте этого объекта это не ошибка, а нормальное поведение, а что-то приводит к тому что нужно изменять описание ошибки и пробрасывать выше это все сугубо от задачи.
Но тупо "оставлять как есть" вероятно допустимо только на этапе "сырой/первичной" разработки и то только когда не понятно что есть что.
Я не совсем понял, что ты имеешь в виду, но речь вот о чем. Предположим, что у нас есть класс даты. Мы можем. Либо все время проверять дату на валидность и не допускать левых дат. Либо создать контракт использования класса, contract violation оставить ведущим к UB, повтыкать ассертов, наплевать на нарушение инвариантов в релизе. Я считаю, что оба подхода нормальны и имеют право на применение, в зависимости от ситуации. hoggy активно продвигает первый вариант с сохранением инвариантов всегда. Либо он не различает терминологию. Либо выражает свою мысль неясно.
0
Avazart
Эксперт С++
7191 / 5365 / 280
Регистрация: 10.12.2010
Сообщений: 23,673
Записей в блоге: 17
10.07.2015, 14:52 #41
Цитата Сообщение от ct0r Посмотреть сообщение
Либо все время проверять дату на валидность и не допускать левых дат.
Ну вообще-то достаточно проверять дату при вводе/задании.
Если же вы допустите некорректный ввод, то вы получите не предвиденные последствия (вообще это как бы банально и ежу понятно) которые вы потом уже никак не отловите и не обнаружите и в этом нет ничего хорошего.
0
ct0r
Игогошка!
1773 / 675 / 42
Регистрация: 19.08.2012
Сообщений: 1,287
Завершенные тесты: 1
10.07.2015, 14:58 #42
Цитата Сообщение от Avazart Посмотреть сообщение
Ну вообще-то достаточно проверять дату при вводе/задании.
Если же вы допустите некорректный ввод, то вы получите не предвиденные последствия (вообще это как бы банально и ежу понятно) которые вы потом уже никак не отловите и не обнаружите и в этом нет ничего хорошего.
Ну это все понятно. Только мне кажется, что ты говоришь о всем приложении в целом, а я о проектировании библиотечного класса, который не в курсе, проверяешь ты там снаружи свои данные, или уверен в их правильности, или еще что.

PS где-то я уверен, что передаю верные данные. Где-то не уверен. И здесь правильный подход - проверять корректность в использующей класс части только там, где нужно. Этим и будут сохраняться инварианты класса и избегаться UB. А в классе оставить только ассерты и не пытаться сохранить инварианты любой ценой.
0
Avazart
Эксперт С++
7191 / 5365 / 280
Регистрация: 10.12.2010
Сообщений: 23,673
Записей в блоге: 17
10.07.2015, 15:03 #43
К примеру

C++
1
2
3
4
5
6
7
8
Date from,to;
 
from.setDate(" .... ");
to.setDate("10.07.2015");
 
int days=  daysBetween(from,to);
 
std::cout<< days <<std::endl;
Если не делать валидацию при вводе то вы никогда не поймете почему days получился некорректном, ибо дофига варинтов:

1. from - задано невалидным
2. to - задано невалидным
3. daysBetween() работает не верно.

Добавлено через 3 минуты
Цитата Сообщение от ct0r Посмотреть сообщение
Только мне кажется, что ты говоришь о всем приложении в целом, а я о проектировании библиотечного класса
А библиотечные классы не строятся один на другом?

Цитата Сообщение от ct0r Посмотреть сообщение
а я о проектировании библиотечного класса, который не в курсе, проверяешь ты там снаружи свои данные,
Должен быть уверен в том что ты проверяешь, как должна быть осуществлена проверка что бы не допустить багов должно быть отображено в документации библиотеки.
0
ct0r
Игогошка!
1773 / 675 / 42
Регистрация: 19.08.2012
Сообщений: 1,287
Завершенные тесты: 1
10.07.2015, 15:12 #44
Цитата Сообщение от Avazart Посмотреть сообщение
Если не делать валидацию при вводе то вы никогда не поймете почему days получился некорректном, ибо дофига варинтов:
Само собой. Но проверки - это не обязательно ответственность именно класса.

Цитата Сообщение от Avazart Посмотреть сообщение
А библиотечные классы не строятся один на другом?
Какая разница? Всегда есть используемый класс и использующий.

Цитата Сообщение от Avazart Посмотреть сообщение
Должен быть уверен в том что ты проверяешь, как должна быть осуществлена проверка что бы не допустить багов должно быть отображено в документации библиотеки.
Да, очевидно, что контракты должны быть прописаны в документации и ассертами.

Добавлено через 3 минуты
Совсем хорошо, если еще негативные тесты есть.
0
Avazart
Эксперт С++
7191 / 5365 / 280
Регистрация: 10.12.2010
Сообщений: 23,673
Записей в блоге: 17
10.07.2015, 15:20 #45
Цитата Сообщение от ct0r Посмотреть сообщение
Какая разница? Всегда есть используемый класс и использующий.
Да любой класс используемый, вопрос уровня. Для того и пишут классы- для возможности повторного использования, а не копипаста кода. Вот как раз отсутствие проверок и делает код непригодным к повторному использованию ибо "человек" должен слишком много знать об этом кривом классе и слишком много сделать проверок руками... и возможно окажется что легче будет писать с нуля нежели использовать этот класс.

Добавлено через 2 минуты
Цитата Сообщение от ct0r Посмотреть сообщение
Само собой. Но проверки - это не обязательно ответственность именно класса.
А кого тогда эта ответственность?
Класс должен отвечать за то что ему поручают, т.е за то с чем его ассоциируют,
Класс "дата" не должен хранить класс "строку" ( как в моем примере: from.setDate(" .... "); ) он должен хранить именно дату, а не что иное.
0
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
10.07.2015, 15:20
Привет! Вот еще темы с ответами:

базовый и производный класс, в базовом объявлена переменная "protected", она недоступна по имени в производном классе! template <class T> воду мутит! - C++
Друзья! Вот код #include &lt;stdio.h&gt; template &lt;class T&gt; class otets { protected: int peremennaya; }; template &lt;class...

Свой класс в С++ - C++
Пытаюсь сделать класс массива точнее переписать код из учебника, но так как код приводится не целый а кусками то что в данный момент...

Создать свой класс - C++
сижу книжку читаю (уже пару недель), там по чуть-чуть все время про классы (в каждой главе) рассказывают, а как полностью сконструировать...

Строки свой класс - C++
Вобщем в чем проблема, нужно реализовать строковый класс начальная структура такова Str.h #include &lt;iostream&gt; class MyString ...


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

Или воспользуйтесь поиском по форуму:
Yandex
Объявления
10.07.2015, 15:20
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Рейтинг@Mail.ru