Сообщений в теме: 21

[Visual1]

Рассмотрим следующий пример на C#:

using System;

namespace ConsoleApplication1
{
	class Base
	{
		private int i = 5;
		private void Foo()
		{
			Console.WriteLine("Hello from private Foo()");
		}
		public static void Main()
		{
			Derived d = new Derived();
			d.i += 8;
			d.Foo();
			Console.WriteLine("d.i = {0}", d.i);
			Console.ReadLine();
		}	
	}

	class Derived : Base
	{   
	}

}

По правилам, прямой доступ к членам класса, объявленным с модификатором private, возможен только из этого же класса. Если необходим доступ к таким членам из производного класса, для этого имеется модификатор protected. Но пример компилируется и работает без единой ошибки! Я этого не могу объяснить. А вы?

[at_developer]

Интересно

[yedyge]

я, конечно, c# не знаю, но не находится ли вызов private void Foo() всё таки внутри класса Base, так же как и public static void Main()?

[Visual1]

Кстати, если Main() сделать тоже private, программа все равно компилируется и работает без ошибок!

Непонятно, зачем во всех книгах Main() всегда явно объявляют public...

[yedyge]

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

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

[Havoc]

/**/

Сообщение отредактировал Havoc: 14.05.2007, 17:23:08

[Коляныч]

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

Но ведь так и происходит... Вот если вынести Main в другой класс, хотя бы в Derived, то должна быть ошибка.

[T. Anre]

Кстати, если Main() сделать тоже private, программа все равно компилируется и работает без ошибок!

Непонятно, зачем во всех книгах Main() всегда явно объявляют public...

Объявление main-функции - дело музыканта на СиДиезе, т.к. точных требований к определению в документации нет.

[T. Anre]

я, конечно, c# не знаю, но не находится ли вызов private void Foo() всё таки внутри класса Base, так же как и public static void Main()?

Примерно, так и есть

[prodovets]

Console.WriteLine("");

Console.WriteLine("");

[Sham]

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

По правилам, прямой доступ к членам класса, объявленным с модификатором private, возможен только из этого же класса. Если необходим доступ к таким членам из производного класса, для этого имеется модификатор protected.

Сообщение отредактировал Sham: 17.05.2007, 23:36:20

[Visual1]

Пример компилируется, так как в классе Derived нет обращения к приватным полям и методам предка.

В данном примере есть обращение из переменной производного класса к приватным полям и методам класса-предка. Его трудно не заметить - см. код примера.

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

[Sham]

Я имел ввиду что нет явного обращения и в данном примере срабатывает наследование, т.е. что может предок, то может и его потомок.
См.

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

[Sham]

Да и еще, если в в Derived классе будет обращение к приватным полям или методам предка, то сработает механизм инкапсуляции(скрытие реализации) и выдаст ошибку.

[Коляныч]

В данном примере есть обращение из переменной производного класса к ...

Такого понятия даже нету - обращение может быть из метода, а не из переменной. Происходит обращение из метода Base.Main к приватной переменной Base.i, поэтому никак не возьму в толк где ты углядел криминал.

[Sham]

В данном примере есть обращение из переменной производного класса к ...

Такого понятия даже нету - обращение может быть из метода, а не из переменной.

Верно подмеченно, а я это пропустил
Кажется тема превращается во флейм.

[Visual1]

Такого понятия даже нету - обращение может быть из метода, а не из переменной.

Расскажи, что курил перед тем, как заявить такое?

Происходит обращение из метода Base.Main к приватной переменной Base.i,

Не из метода Base.Main, а из объектной переменной, имя которой должно быть обязательно указано перед именем вызываемого метода или именем поля, к которому происходит обращение (поскольку они не объявлены как static). В данном примере эта объектная переменная имеет тип класса-наследника.

поэтому никак не возьму в толк где ты углядел криминал.

Нет никакого криминала, все законно. Я просто привел интересный (на мой взгляд) пример. Он интересен тем, что атрибут private как у метода, так и у поля в базовом классе в данном случае не влияет на их доступность из переменной производного класса.

[Коляныч]

Такого понятия даже нету - обращение может быть из метода, а не из переменной.

Расскажи, что курил перед тем, как заявить такое?

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

Происходит обращение из метода Base.Main к приватной переменной Base.i,

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

Либо ты всё шиворот на выворот перепутал, либо читай выше.

поэтому никак не возьму в толк где ты углядел криминал.

Нет никакого криминала, все законно. Я просто привел интересный (на мой взгляд) пример. Он интересен тем, что атрибут private как у метода, так и у поля в базовом классе в данном случае не влияет на их доступность из переменной производного класса.

Имхо тебя смутил всего лишь тот факт, что в шарпе апкаст Derivet->Base происходит неявно, без необходимости писать static_cast<Base>(d). Других сложностей для понимания в упор не вижу.

[Visual1]

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

У меня "своеобразное представление" и "личные проблемы"? Хм, вроде бы раньше не было такого в твоей манере - переходить на личности. По теме: состояние класса должно быть надежно защищено - надеюсь, не станешь с этим спорить? А как это обеспечить? Сделать класс изолированным (sealed)? Это работает, но изолированные классы не всегда удобны в использовании (производные типы нужны довольно часто, да и что это за ООП без наследования). Изолированным класс следует делать только если заранее известно, что он не предназначен для наследования. Это трудно предсказать - и поэтому не зря компилятор C# делает любой класс по умолчанию неизолированным.

Поля данных класса всегда следует объявлять private - элементарное правило, думаю, никто не станет с этим спорить. Но, как видно из приведенного примера, это тоже не всегда помогает. Я показал одну из таких скрытых опасностей - дальше можете поступать по своему усмотрению:
а) пользоваться этим в своей практической работе (рекомендую);
б) говорить про меня все, что угодно (что у меня "личные проблемы с пониманием языков ООП" и т.д.).

[yedyge]

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