Какова ценность частных членов здесь? - PullRequest
0 голосов
/ 25 января 2011

Если у меня есть два класса A и B, такие, что B inehrits A.Другими словами, A является базовым классом, а B является производным классом.

Теперь предположим, что класс A имеет private членов.Поскольку класс B унаследован от класса A, члены с закрытыми данными стали частью класса B.

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

Спасибо.

Ответы [ 6 ]

3 голосов
/ 25 января 2011

Они никак не могут использоваться функциями-членами B, но они будут полезны для функций-членов A, на которые, в свою очередь, будет полагаться B. Это просто еще один уровень инкапсуляции (B не должно волновать, как реализована функциональность A).

2 голосов
/ 25 января 2011

Цель "private" - сообщить разработчикам, которые пишут класс B, что они не должны иметь доступ к этому члену.

Разработчик класса A использует член определенным образом, к которому разработчики класса B не должны беспокоиться.

2 голосов
/ 25 января 2011

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

1 голос
/ 25 января 2011

Члены A объектов B будут такими, какими они нужны вашему объекту для представления того, что вы представляете с ним.Методы класса, вероятно, используют их, и вы, вероятно, вызовете некоторые методы класса А.Вы должны заботиться только об общедоступном (или защищенном) интерфейсе A и использовать его.

Например: если A - это реализация сокета протокола TCP / IP, которая имеет методы записи и чтения, B может бытьРеализация SSL поверх A. Вы (в основном) переопределяете чтение и запись, чтобы выполнить шифрование, а затем использовать A :: read и A :: write для фактической записи и чтения из / в сокет.Вам вообще не нужно знать, какой у вас сокет (или детали протокола TCP) в этом дизайне, поэтому A абстрагирует его для вас, и у вас нет к нему доступа.

0 голосов
/ 25 января 2011

Потому что, хотите верьте, хотите нет, вы не хотите связывать B с деталями реализации A. Представьте сценарий с самым простым видом использования:

struct A
{
protected:
  int x;
};

struct B
{
  void f() { ... access x and use as input ... }
};

Теперь давайте предположим, чтотребуется изменение вашего продукта, и теперь A не имеет переменной x, а вместо этого выбирает значение x, которое должно быть представлено каким-либо другим способом, возможно, составом.Поскольку B обращается к члену напрямую, вы должны изменить любой B, который вы создали, чтобы захватить x через любой новый механизм, который не существует.Чем больше вам нужно изменить, тем больше места для проблем.

Если бы вы вместо этого сделали xa приватным участником и предоставили защищенный получатель, у вас не было бы этой проблемы.

Опять же,это самый простой пример.В общем, такие значения, как x, используются в реализации поведения A, и B не должен заботиться о том, как реализовано поведение, и при этом он не должен иметь доступа к нему.

0 голосов
/ 25 января 2011

Это останется - частный член.

Я не знаю, где вы видели, что к ним нельзя получить доступ?

...