Есть ли аналоги дружественных методов и классов в C# ?

Необходимо получить доступ к private-полю и к private-методу класса из другого класса...

я думаю нет, в сишарпе все строго

Тогда какие варианты ?

Дык какие могут быть варианты?! Private-члены на то и private, чтобы они были доступны только внутри объекта.

Ну вот, скажем, ситуация такая. Объект класса Element может создаваться прикладным пользователем в своей программе. В то же время имеется объект SChart, который так же может создаваться и юзаться пользователем в своих программах.
Некоторый метод класса Element не может быть вызван прикладным пользователем по причине отсутствия в этом необходимости (этот метод используется другими public-методами этого же класса). Вполне резонно объявить этот метод как private.
В то же время объект класса SChart должен иметь доступ к этому private-методу класса Element. Если в этом случае мы откроем доступ (сделаем метод класса Element открытым), то тем самым мы его откроем его и для прикладного пользователя, который будет юзать как Element, так и SChart...
Как разрешить эту проблему в данном случае ?

Добавлено @ 21:17 
Idsa, праdила без исключений довольно редки, по крайней мере для C++...

Так за то люди и любят C#, что в нем все четко и логично  

Несмотря на то, что придуманная тобой ситуация немного надуманна, попробуем ее реализовать. Дружественные методы можно реализовать по-разному... я лишь предложу один вариант:

Так пойдет?

делайте метод публичным и не парьтесь. Что мешает пользователю вызвать этот "приватный" метод, передав объект SChar в примере Idsa? Там он как раз пользователем и вызывается, а не классом .
ИМХО без дружественных классов методу довольно трудно , если возможно вообще , определить кто его вызвал.
ЗЫ могу предложить такой прием(раз уж начали извращаться). Вызываемому методу передается константа, которую знаеть лишь класс SChar, а от пользователя она скрыта. 

Это сообщение отредактировал(а) Sartorius - 22.2.2007, 22:04

...что достигается неизбежным снижением гибкости языка...


Реальная ситуация из реального проекта...


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

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

Спросим у Sartorius'а... 

CyraxZ, а чего я? я ничего...    у меня кроме варианта с уникальной константой идей нет... 
Ну или сделать его protected и отнаследоваться от Element. 

Пока вопрос оставим открытым...

Решается использованием internal модификатора для мемберов (полей, свойств, методов) - в своей сборке такой мембер будет виден откуда угодно, а в прикладном коде (который по идее лежит в другой сборке) мембер недоступен. Потому как internal. Если нужно чтобы мембер был доступен в классах-наследниках, юзаем protected internal.

mr.DUDA, перечитай внимательно пост CyraxZ: нужно сделать все наоборот!

Idsa, читаю:



Дружественные методы в C++ дают одному классу доступ к private-полям (методам) другого класса, используя ключевое слово friend. Теперь вернёмся к нашим баранам (C#): класс не может работать с private-полями другого класса, за исключением случаев когда поле объявлено с модификатором internal. Развиваю тему: теперь нужно решить задачу, как "скрыть" приватное поле от прикладного кода ? Так: прикладной код и наш код (оба класса - с полем, и тот кому оно нужно) разносятся по разным dll/exe. Так обычно и поступают, делают общуюю длл-ку, которую подключают к приложению по reference.

Ещё вопросы ?