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

Nishen · Регистрация: 26.02.2015

Author24 — интернет-сервис помощи студентам

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

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

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

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

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

@Ouroboros-SK · 09.07.2015, 18:51

В хороших классах предоставляется доступ к private, через методы get и set.

Добавлено через 2 минуты
т.е

C++

class A
{
public:
  type getB();
  void setB(B);
private:
  type B;
};

Добавлено через 1 минуту
А protected чаще всего лепят в абстрактных классах или в классах, которые могут быть расширены.
Как правило, при проектировании понятно, какие классы будут расширятся, а какие нет.

@Avazart · 09.07.2015, 19:25

Сообщение от Ouroboros-SK

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

В protected обычно помещают методы, а не члены класса.

Члены класса делают private как правило.
Если же вы видите класс в котором члены класса открыты то этот класс либо какой-то особенный(например не предназначенный для наследования) либо он просто так криво написан.

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

Сообщение от Nishen

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

Использовать доступ через предусмотренные для этого методы.

@hoggy · 09.07.2015, 20:48

Сообщение от Nishen

Возникает вопросы: так когда же стоит использовать protected?

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

Сообщение от Nishen

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

об этом думают на этапе проектирования:
зачем вообще нужен этот базовый класс?

@Mr.X · 09.07.2015, 20:59

Сообщение от Nishen

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

Еще одна глупость этого Лафоре. Сколько уже его ляпов цитировали здесь на форуме. Поражает непонятная популярность этого шарлатана. Охота же людям замусоривать себе мозги.

@xEmpire · 09.07.2015, 21:03

Avazart, Чем плох вариант использовать данные с областью видимости protected и переопределять область видимости на private (используя using) в наследуемом классе?

@Avazart · 09.07.2015, 21:04

xEmpire, Пример кода?

@hoggy · 09.07.2015, 21:05

Сообщение от xEmpire

Чем плох вариант использовать данные с областью видимости protected и переопределять область видимости на private в наследуемом классе?

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

@xEmpire · 09.07.2015, 21:14

Avazart, да хоть

C++

class Foo {
    protected:
        int _x;
};
 
class Bar : public Foo {
    private:
        using Foo::_x;
};

Добавлено через 5 минут
hoggy, ну а если это абстрактный класс, и цели делать его интерфейсом (Pure Abstract Class) нет?

@hoggy · 09.07.2015, 21:16

Сообщение от xEmpire

ну а если это абстрактный класс, и цели делать его интерфейсом (Pure Abstract Class) нет?

какая разница?

вы понимаете вообще,
откуда пошла такая манера делать все данные-члены классов приватными?

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

вот зачем это нужно?

@Avazart · 09.07.2015, 21:16

Ок, зачем тогда вообще объявлять _x в классе Foo ?

@Mr.X · 09.07.2015, 21:17

Сообщение от xEmpire

чем плох вариант использовать данные с областью видимости protected

Основной принцип ООП - это минимизация зависимостей. Если в базовом классе данные protected, то классы-наследники будут зависеть от реализации базового класса, что нарушает этот принцип.
Ну и согласно принципу инкапсуляции класс должен сам управлять своими данными, а тут ими будет управлять еще кто-то, т.е. инкапсуляция нарушается. В общем, все это сильно противоречит принципам ООП.

@Avazart · 09.07.2015, 21:20

Сообщение от xEmpire

ну а если это абстрактный класс, и цели делать его интерфейсом (Pure Abstract Class) нет?

Ок а что дает вообще абстрактность и полиморфизм?
Одинаковый "внешний" вид/интерфейс, но возможно разное поведение (от класса к классу)
_x и вообще член класса в данном случае дает возможность варьировать поведением?
Ведь нет виртуальных членов данных? есть виртуальные методы.

@xEmpire · 09.07.2015, 21:21

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

@hoggy · 09.07.2015, 21:24

Сообщение от xEmpire

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

это нормально - иметь не виртуальную функцию-член.
которая для всех работает одинаково.

только причем здесь данные-члены?

@Avazart · 09.07.2015, 21:31

xEmpire, Не уловил мысли.

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

C++

class Foo 
{
    protected:
        int _x;
};

И

C++

class Foo
 {
    private:
          int x_;    
    protected:
         int x()const{ return x_; }
};

C++

class Foo
{
    private:
          int x1_,x2_;    
    protected:
         int x()const
         { 
             return x1_+x2_; // Изменение которое допустим потребуется в будущем.
         } 
};

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

@xEmpire · 09.07.2015, 22:54

Сообщение от hoggy

это нормально - иметь не виртуальную функцию-член.
которая для всех работает одинаково.

только причем здесь данные-члены?

Ну если у нас есть абстрактный класс, следовательно создать экземпляр этого класса не возможно.
Если в нашем классе есть методы, которые должны быть для наследников реализованы по разному, они объявленные как чистые виртуальные методы, иначе это просто методы.
Если чистый виртуальный метод должен быть реализацией (в наследуемом классе у перекрытого метода будет изменена область видимости на protected | private), а не интерфейсом в наследуемом классе, то он должен быть объявлен с областью видимости protected иначе, если использовать этот метод виртуальным вызовом, то вызов этого метода будет разрешен, независимо, какая область видимости этого метода в наследнике.

C++

#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 методы?

@Avazart · 09.07.2015, 23:04

Сообщение от xEmpire

если хочется работать напрямую?

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

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

Сообщение от xEmpire

очему не сделать в суперклассе данных защищенным, а в наследуемом сделать их закрытыми и при расширении работать с данными напрямую, а при работе извне -используя set и get методы?

Вы предлагаете самого старта нарушить инкапсуляцию, а потом героически попытаться это дело исправить?

@xEmpire · 09.07.2015, 23:13

Avazart, Не знаю по чему, но при чтении топика, мне почему-то показалось, что при public наследовании, protected становится public, а тут такие дела

@hoggy · 09.07.2015, 23:51

Сообщение от xEmpire

При расширении этого класса (наследуем интерфейс), переопределяя виртуальные методы при их реализации обращаясь к данным-членам суперкласса, зачем нам использовать get и set методы, если хочется работать напрямую?

наряду с понятием "инкапсуляция" есть ещё понятие "инвариант".

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

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

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

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

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

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

@hoggy 8739 / 4317 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	09.07.2015, 21:16	10
	Сообщение от xEmpire ну а если это абстрактный класс, и цели делать его интерфейсом (Pure Abstract Class) нет? какая разница? вы понимаете вообще, откуда пошла такая манера делать все данные-члены классов приватными? во многих книгах пишут: по хорошему все данные-члены класса должны быть приватными. вот зачем это нужно? 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	09.07.2015, 21:16	11
	Ок, зачем тогда вообще объявлять _x в классе Foo ? 0

@Mr.X 3225 / 1752 / 436 Регистрация: 03.05.2010 Сообщений: 3,867
	09.07.2015, 21:17	12
	Сообщение от xEmpire чем плох вариант использовать данные с областью видимости protected Основной принцип ООП - это минимизация зависимостей. Если в базовом классе данные protected, то классы-наследники будут зависеть от реализации базового класса, что нарушает этот принцип. Ну и согласно принципу инкапсуляции класс должен сам управлять своими данными, а тут ими будет управлять еще кто-то, т.е. инкапсуляция нарушается. В общем, все это сильно противоречит принципам ООП. 2

Nishen 1352 / 851 / 365 Регистрация: 26.02.2015 Сообщений: 3,799
		1
	Пишем свой класс, спецификатор доступа protected 09.07.2015, 18:43. Показов 5096. Ответов 61 Метки нет (Все метки) Всем привет! Из книги Р. Лафоре относительно спецификатора доступа protected: Таким образом, если вы пишете класс, который впоследствии будет использоваться как базовый класс при наследовании, то данные, к которым нужно будет иметь доступ, следует объявлять как protected. Далее пишется следующее: Существуют и недостатки использования спецификатора доступа protected... это делает члены, объявленные как protected, значительно менее защищенными, чем объявленные как private. Возникает вопросы: так когда же стоит использовать protected? Как я могу знать, захочет ли кто-нибудь использовать мой класс, как базовый? И как не доиграться со спецификаторами доступа? Как быть, если я хочу использовать чужой класс, но поля класса закрыты спецификатором private? 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	09.07.2015, 19:25	3
	Сообщение от Ouroboros-SK А protected чаще всего лепят в абстрактных классах или в классах, которые могут быть расширены. В protected обычно помещают методы, а не члены класса. Члены класса делают private как правило. Если же вы видите класс в котором члены класса открыты то этот класс либо какой-то особенный(например не предназначенный для наследования) либо он просто так криво написан. Добавлено через 5 минут Сообщение от Nishen Как быть, если я хочу использовать чужой класс, но поля класса закрыты спецификатором private? Использовать доступ через предусмотренные для этого методы. 0

@hoggy 8739 / 4317 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	09.07.2015, 20:48	4
	Сообщение от Nishen Возникает вопросы: так когда же стоит использовать protected? в эту секцию помещается функционал, который должен быть доступен наследникам класса. Сообщение от Nishen Как я могу знать, захочет ли кто-нибудь использовать мой класс, как базовый? об этом думают на этапе проектирования: зачем вообще нужен этот базовый класс? 0

@Mr.X 3225 / 1752 / 436 Регистрация: 03.05.2010 Сообщений: 3,867
	09.07.2015, 20:59	5
	Сообщение от Nishen Таким образом, если вы пишете класс, который впоследствии будет использоваться как базовый класс при наследовании, то данные, к которым нужно будет иметь доступ, следует объявлять как protected. Еще одна глупость этого Лафоре. Сколько уже его ляпов цитировали здесь на форуме. Поражает непонятная популярность этого шарлатана. Охота же людям замусоривать себе мозги. 1

@xEmpire 25 / 25 / 11 Регистрация: 07.12.2012 Сообщений: 169
	09.07.2015, 21:03	6
	Avazart, Чем плох вариант использовать данные с областью видимости protected и переопределять область видимости на private (используя using) в наследуемом классе? 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	09.07.2015, 21:04	7
	xEmpire, Пример кода? 0

@hoggy 8739 / 4317 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	09.07.2015, 21:05	8
	Сообщение от xEmpire Чем плох вариант использовать данные с областью видимости protected и переопределять область видимости на private в наследуемом классе? очевидно тем, что они не приватные в базовом классе. и следовательно, код обладает всеми недостатками такого рода проектирования. 1

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	09.07.2015, 21:20	13
	Сообщение от xEmpire ну а если это абстрактный класс, и цели делать его интерфейсом (Pure Abstract Class) нет? Ок а что дает вообще абстрактность и полиморфизм? Одинаковый "внешний" вид/интерфейс, но возможно разное поведение (от класса к классу) _x и вообще член класса в данном случае дает возможность варьировать поведением? Ведь нет виртуальных членов данных? есть виртуальные методы. 0

@xEmpire 25 / 25 / 11 Регистрация: 07.12.2012 Сообщений: 169
	09.07.2015, 21:21	14
	Avazart, ну например у нас есть абстрактный класс, в котором помимо чистых виртуальных методах есть метод, который выполняется в наследуемых классах одинаково, следовательно проще определить переменные здесь, и реализовать данный метод здесь используя данные переменные, а в наследуемых классах переопределить уровень доступа на закрытый. 0

@hoggy 8739 / 4317 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	09.07.2015, 21:24	15
	Сообщение от xEmpire есть метод, который выполняется в наследуемых классах одинаково, следовательно проще определить переменные здесь, и реализовать данный метод здесь используя данные переменные, а в наследуемых классах переопределить уровень доступа на закрытый. это нормально - иметь не виртуальную функцию-член. которая для всех работает одинаково. только причем здесь данные-члены? 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	09.07.2015, 23:04	18
	Сообщение от xEmpire если хочется работать напрямую? Когда хочется, бьем по кривым рукам что бы не хотелось лезть туда куда не стоит. Добавлено через 2 минуты Сообщение от xEmpire очему не сделать в суперклассе данных защищенным, а в наследуемом сделать их закрытыми и при расширении работать с данными напрямую, а при работе извне -используя set и get методы? Вы предлагаете самого старта нарушить инкапсуляцию, а потом героически попытаться это дело исправить? 0

@xEmpire 25 / 25 / 11 Регистрация: 07.12.2012 Сообщений: 169
	09.07.2015, 23:13	19
	Avazart, Не знаю по чему, но при чтении топика, мне почему-то показалось, что при public наследовании, protected становится public, а тут такие дела 0

@hoggy 8739 / 4317 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	09.07.2015, 23:51	20
	Сообщение от xEmpire При расширении этого класса (наследуем интерфейс), переопределяя виртуальные методы при их реализации обращаясь к данным-членам суперкласса, зачем нам использовать get и set методы, если хочется работать напрямую? наряду с понятием "инкапсуляция" есть ещё понятие "инвариант". суть инкапсуляции: возможность использовать функционал без необходимости знать детали внутренней реализации. (нам не нужно знать какие есть данные-члены у суперкласса, что бы дергать его методы) суть инварианта: компонент гарантирует стабильность своей работы (отсутствие крашей, утечек ресурсов и тп), независимо от корректности вызывающей стороны. то есть, даже если вызывающая сторона запускает функцию с плохими аргументами, инвариантный компонент это пофиксит, и обработает ошибку. и никаких сбоев в его работе не будет. но если бы данные-члены были открытыми, тогда любой желающий мог бы залезть, и как то их подкрутить. и такой компонент вам уже ничего гарантировать не сможет. архитектура, которая состоит из компонентов, которые никому ничего не гарантирует - подвережна многочисленным ошибкам. плохо расширяется. хрупкая (плохо переносит изменения), и тп. 2