Обращение к унаследованным свойствам внутри класса

[t2skler]

Есть класс:

class AAA {
private:
int PNum;
//...
}

И его наследник:

class BBB : public AAA {
private:
//...
public:
fn() {
PNum++; // как обратиться к свойству унаследованному от AAA ?
}

[Rififi]

t2skler

как обратиться к свойству унаследованному от AAA ?

Никак. Свойство private не для того вводили, чтобы кому попало данные отдавать.

[t2skler]

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

class AAA {
private:
int PNum;
//...
public:
void PFive() {
PNum += 5;
}
}

[Blade]

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

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

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

[_Bers]

На самом деле, можно получить доступ к приватным данным любого класса.
Только нужно выполнить ряд условий:

1. Нужно очень сильно этого хотеть, ибо это "взлом природной защиты класса".
2. Отдавать отчет себе в том, что делаешь, и какие могут быть последствия.
3. Нужно знать внутренне устройство класса, который необходимо подвергнуть взлому.
4. Что бы избавить себя от необходимости каждый раз вникать во внутреннее устройство класса-жертвы, можно использовать технику "манипулятивных классов". Но это противоречит пункту 2.

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

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

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

[Blade]

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

На самом деле, можно получить доступ к приватным данным любого класса.
Только нужно выполнить ряд условий:

1. Нужно очень сильно этого хотеть, ибо это "взлом природной защиты класса".
2. Отдавать отчет себе в том, что делаешь, и какие могут быть последствия.
3. Нужно знать внутренне устройство класса, который необходимо подвергнуть взлому.
4. Что бы избавить себя от необходимости каждый раз вникать во внутреннее устройство класса-жертвы, можно использовать технику "манипулятивных классов". Но это противоречит пункту 2.

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

Вы действительно считаете, что оно надо ТС?

[Ezhuk]

А создание паблик функции изменяющую Pnum в классе ААА не решает проблему?

[_Bers]

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

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

Вы действительно считаете, что оно надо ТС?

Да это так, для общего развития.
ТС произвел на меня впечатление человека, который изучает "правила" использования модификаторов доступа. Но он пока ещё не осознал "идею". То есть, он не вполне понимает, зачем это вообще нужно.

ТС нужно понять самую идею модификаторов доступа. А именно: в чем заключается их смысл? Для чего они нужны?

И тогда ему станет очевидно, почему потомки в общем случае не имеют доступа к приватным данным предка.

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


Допустим я сделал класс:

class СTool
{
public:
   ... //весь публичный интерфейс
protected:
   ... //позаботимся о будущем развитии инструмента
       //здесь методы и данные, которые будут доступны для потомков
private:
   ...  //сердце класса. Доступ разрешён только создателю класса
        //Всем остальным даже знать не нужно, что здесь происходит
};

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

Таким образом достигается негласное соглашение между разработчиком класса, и пользователями этого класса: "используйте возможности моего класса согласно его документации, и он гарантирует вам стабильную работу".

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

Если по какой то причине, для стабильной работы всей архитектуры потребовалось, что бы один кусок кода получил доступ к приватной зоне другого куска кода, то в 99,(9) случаев это означает, что сама по себе архитектура ущербна. Таких ситуаций быть не должно. Это - ошибка проектировщика.

Классы - это способ разделения ответственности за работоспособность всей системы между отдельным кусками кода.

Разные классы могут писать разные программисты. Поэтому, можно сказать, что классы - это способ разделения ответственности за работоспособность всей системы между отдельными программистами.

[t2skler]

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

Да это так, для общего развития.
ТС произвел на меня впечатление человека, который изучает "правила" использования модификаторов доступа. Но он пока ещё не осознал "идею". То есть, он не вполне понимает, зачем это вообще нужно.

ТС нужно понять самую идею модификаторов доступа. А именно: в чем заключается их смысл? Для чего они нужны?

И тогда ему станет очевидно, почему потомки в общем случае не имеют доступа к приватным данным предка.

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


Допустим я сделал класс:

class СTool
{
public:
   ... //весь публичный интерфейс
protected:
   ... //позаботимся о будущем развитии инструмента
       //здесь методы и данные, которые будут доступны для потомков
private:
   ...  //сердце класса. Доступ разрешён только создателю класса
        //Всем остальным даже знать не нужно, что здесь происходит
};

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

Таким образом достигается негласное соглашение между разработчиком класса, и пользователями этого класса: "используйте возможности моего класса согласно его документации, и он гарантирует вам стабильную работу".

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

Если по какой то причине, для стабильной работы всей архитектуры потребовалось, что бы один кусок кода получил доступ к приватной зоне другого куска кода, то в 99,(9) случаев это означает, что сама по себе архитектура ущербна. Таких ситуаций быть не должно. Это - ошибка проектировщика.

Классы - это способ разделения ответственности за работоспособность всей системы между отдельным кусками кода.

Разные классы могут писать разные программисты. Поэтому, можно сказать, что классы - это способ разделения ответственности за работоспособность всей системы между отдельными программистами.

Больше спасибо за полное объяснение работы с директивами доступа понятным языком