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

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

Войти
Регистрация
Восстановить пароль
 
 
Рейтинг: Рейтинг темы: голосов - 11, средняя оценка - 4.64
Nishen
397 / 236 / 79
Регистрация: 26.02.2015
Сообщений: 1,075
Завершенные тесты: 2
#1

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

09.07.2015, 18:43. Просмотров 1905. Ответов 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 варианта...

61
Avazart
Эксперт С++
7246 / 5418 / 297
Регистрация: 10.12.2010
Сообщений: 24,042
Записей в блоге: 17
09.07.2015, 21:31 #16
xEmpire, Не уловил мысли.

Что к примеру будет если мы захотим изменить "базовое" поведение ? И вместо x нам нужно будет считать x1+x2 ?

C++
1
2
3
4
5
class Foo 
{
    protected:
        int _x;
};
И

C++
1
2
3
4
5
6
7
class Foo
 {
    private:
          int x_;    
    protected:
         int x()const{ return x_; }
};

C++
1
2
3
4
5
6
7
8
9
10
class Foo
{
    private:
          int x1_,x2_;    
    protected:
         int x()const
         { 
             return x1_+x2_; // Изменение которое допустим потребуется в будущем.
         } 
};
Интерфейс не изменился, а поведение изменилось, но наследники это "не ощутят" в плане в них изменять ничего не придется если они использую метод, а не член класса.
0
xEmpire
25 / 25 / 9
Регистрация: 07.12.2012
Сообщений: 169
Завершенные тесты: 1
09.07.2015, 22:54 #17
Цитата Сообщение от hoggy Посмотреть сообщение
это нормально - иметь не виртуальную функцию-член.
которая для всех работает одинаково.

только причем здесь данные-члены?
Ну если у нас есть абстрактный класс, следовательно создать экземпляр этого класса не возможно.
Если в нашем классе есть методы, которые должны быть для наследников реализованы по разному, они объявленные как чистые виртуальные методы, иначе это просто методы.
Если чистый виртуальный метод должен быть реализацией (в наследуемом классе у перекрытого метода будет изменена область видимости на protected | private), а не интерфейсом в наследуемом классе, то он должен быть объявлен с областью видимости protected иначе, если использовать этот метод виртуальным вызовом, то вызов этого метода будет разрешен, независимо, какая область видимости этого метода в наследнике.
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <iostream>
 
class Foo {
public:
    virtual void Test() const = 0 ;    
};
 
class Bar : public Foo {
    void Test() const override
    {
         std::cout << "test";
    }
};
 
int main() {
    Foo *p = new Bar();
    p->Test(); // вызов функции будет разрешен
}
При расширении этого класса (наследуем интерфейс), переопределяя виртуальные методы при их реализации обращаясь к данным-членам суперкласса, зачем нам использовать get и set методы, если хочется работать напрямую? Почему не сделать в суперклассе данных защищенным, а в наследуемом сделать их закрытыми и при расширении работать с данными напрямую, а при работе извне -используя set и get методы?
0
Avazart
Эксперт С++
7246 / 5418 / 297
Регистрация: 10.12.2010
Сообщений: 24,042
Записей в блоге: 17
09.07.2015, 23:04 #18
Цитата Сообщение от xEmpire Посмотреть сообщение
если хочется работать напрямую?
Когда хочется, бьем по кривым рукам что бы не хотелось лезть туда куда не стоит.

Добавлено через 2 минуты
Цитата Сообщение от xEmpire Посмотреть сообщение
очему не сделать в суперклассе данных защищенным, а в наследуемом сделать их закрытыми и при расширении работать с данными напрямую, а при работе извне -используя set и get методы?
Вы предлагаете самого старта нарушить инкапсуляцию, а потом героически попытаться это дело исправить?
0
xEmpire
25 / 25 / 9
Регистрация: 07.12.2012
Сообщений: 169
Завершенные тесты: 1
09.07.2015, 23:13 #19
Avazart, Не знаю по чему, но при чтении топика, мне почему-то показалось, что при public наследовании, protected становится public, а тут такие дела
0
hoggy
6691 / 2873 / 493
Регистрация: 15.11.2014
Сообщений: 6,465
Завершенные тесты: 1
09.07.2015, 23:51 #20
Цитата Сообщение от xEmpire Посмотреть сообщение
При расширении этого класса (наследуем интерфейс), переопределяя виртуальные методы при их реализации обращаясь к данным-членам суперкласса, зачем нам использовать get и set методы, если хочется работать напрямую?
наряду с понятием "инкапсуляция" есть ещё понятие "инвариант".

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


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

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


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

и такой компонент вам уже ничего гарантировать не сможет.

архитектура, которая состоит из компонентов,
которые никому ничего не гарантирует - подвережна многочисленным ошибкам.
плохо расширяется. хрупкая (плохо переносит изменения), и тп.
2
Mr.X
Эксперт С++
3051 / 1696 / 265
Регистрация: 03.05.2010
Сообщений: 3,867
10.07.2015, 00:21 #21
Цитата Сообщение от xEmpire Посмотреть сообщение
суперкласса
Цитата Сообщение от hoggy Посмотреть сообщение
суперкласса
В С++ нету таких словей.
0
ct0r
Игогошка!
1776 / 678 / 42
Регистрация: 19.08.2012
Сообщений: 1,294
Завершенные тесты: 1
10.07.2015, 03:13 #22
Цитата Сообщение от hoggy Посмотреть сообщение
суть инкапсуляции:
возможность использовать функционал без необходимости знать детали внутренней реализации.
(нам не нужно знать какие есть данные-члены у суперкласса, что бы дергать его методы)
Забавно, что часто приходится узнавать детали внутренней реализации и при инкапсуляции в коде. Отголоски закона дырявых абстракций.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

вдумайтесь в эту фразу:
способность гарантировать стабильность своей работы не зависимо от корректности вызывающей стороны.
0
Voivoid
675 / 278 / 12
Регистрация: 31.03.2013
Сообщений: 1,339
10.07.2015, 07:18 #24
Цитата Сообщение от ct0r Посмотреть сообщение
Очень часто, чтобы не чесать правое ухо левой пяткой, при модульном тестировании нужные private-члены делаются public-членами с соответствующим комментарием, что, мол, это только для тестовых целей.
А разгадка проста - в этом классе нарушен single responsibility principle и/или не используется dependency injection.
0
egor2116
342 / 373 / 42
Регистрация: 20.01.2013
Сообщений: 1,132
10.07.2015, 09:29 #25
Еще одна глупость этого Лафоре.
Хотелось бы Вашу книжку прочесть
0
Mr.X
Эксперт С++
3051 / 1696 / 265
Регистрация: 03.05.2010
Сообщений: 3,867
10.07.2015, 09:51 #26
Цитата Сообщение от egor2116 Посмотреть сообщение
Хотелось бы Вашу книжку прочесть
Т.е. все, кто еще не написал книжки, должны восторгаться придурком Лафоре?
Чтобы судить о вкусе омлета не обязательно уметь нести яйца.
0
egor2116
342 / 373 / 42
Регистрация: 20.01.2013
Сообщений: 1,132
10.07.2015, 09:56 #27
Т.е. все, кто еще не написал книжки, должны восторгаться придурком Лафоре?
Да я не предлагаю ни кем восторгаться. Вы просто очень категоричны. Вы пишите программы без ошибок и все ими восторгаются, и не у кого нет мнения что какую нибудь часть можно было реализовать по другому не так как у Вас?
0
Mr.X
Эксперт С++
3051 / 1696 / 265
Регистрация: 03.05.2010
Сообщений: 3,867
10.07.2015, 10:12 #28
Цитата Сообщение от egor2116 Посмотреть сообщение
Вы просто очень категоричны.
Да ладно! Лафоре полнейший невежда в той области, в которой он собрался учить других. Только от тех ляпов, что здесь на форуме процитированы, у нормального человека уши вянут, а ведь некоторые люди еще и специально засир@ют себе мозги, читая его дерьмокнижки.
0
egor2116
342 / 373 / 42
Регистрация: 20.01.2013
Сообщений: 1,132
10.07.2015, 10:16 #29
"Лафоре полнейший невежда в той области." "Только от тех ляпов"
Возможно, но нужно не забывать что данная литература является переводом и тут нужно обратить так же внимание на переводчика т.к. литература техническая и насыщена соответствующей терминологией, а также
у нормального человека уши вянут
человек который интересуется данной тематикой профессионально должен прочитать далеко не одного автора и не один раз.
0
Mr.X
Эксперт С++
3051 / 1696 / 265
Регистрация: 03.05.2010
Сообщений: 3,867
10.07.2015, 10:22 #30
Цитата Сообщение от egor2116 Посмотреть сообщение
человек который интересуется данной тематикой профессионально должен прочитать далеко не одного автора и не один раз.
Однако это не причина читать придурков. Литературы самого высокого качества столько, что жизни не хватит, чтобы ее прочесть.
1
10.07.2015, 10:22
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
10.07.2015, 10:22
Привет! Вот еще темы с ответами:

базовый и производный класс, в базовом объявлена переменная "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 ...


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

Или воспользуйтесь поиском по форуму:
30
Ответ Создать тему
Опции темы

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