Friend Class in C#

[mehdi62b]

Hello everybody,
I know we have Friend Class in C++ but I wanted to know whether I can use friend class in C#,
I figured out that its possible to use friend class in VB.NET(from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vblr7/html/vakeyFriend.asp)
but it seems I cant use it in C# (because of this link (http://www.faqts.com/knowledge_base/view.phtml/aid/24737/fid/791))
am I right?
Thanks in advance.

[Norfy]

Do you have an example or is this just a general question?

One other possibility to "internal" is to use inner classes which can be declared as "private" to their outer class.

[mehdi62b]

Thanks for checking my problem,
I meant from Friend Class something there is in C++(not in VB.NET or C#.NET)
Internal(C#.NET)==Friend(VB.NET)!=Friend(C++)
Friend classes in C++ let just one class access another class
Take a look at my example

C++
class wheel{
friend class car;//car can access wheel without any restriction
friend class bus;//bus can access wheel without any restriction
//other declarations for wheel
};
class car{
//declarations for car
};
class bus{
//declarations for bus
};

as you see I didnt use Nested Classes,(I used Composite Classes instead)
I dont know how I can convert my C++ example to C#(without using Nested Classes)
(if I use Nested classes I have to declare Wheel class
in every bus or car class ...)

[Norfy]

Your given example would be solved by 'Car' and 'Bus' having a common base class and 'Wheel' being a 'nested' class of that.

I would be interested to see a 'real-world' problem that required the C++ 'friend'.

If 'Wheel' has any "interesting" behaviour, why break encapsulation and give "access without any restriction"?

[darwen]

I can think of quite a few examples where friends are necessary in C++.

Consider an observer class :


class CObserver
{
protected:
virtual void OnMessage() = 0;
} ;


The OnMessage function will need to be called by whatever it's observing - but we don't want any other class to be able to call it.

Therefore we use a friend :


class CToBeObserved;

class CObserver
{
friend CToBeObserved;

protected:
virtual void OnMessage() = 0;
} ;

class CToBeObserved
{
private
void SomethingHappens()
{
m_pObserver->OnMessage();
}
};


Now, friends in VB.NET aren't the same as friends in C++. Friends in C++ effectively give permission for one class to have access to the protected and private methods and variables on another. Access is ONLY given to the specified classes.

Friends in VB.NET give access to all classes in the same assembly.

In short, there aren't any friends in .NET like the C++ friends.

However, there are ways around the problem. I've got an article coming out showing how to do it in certain instances - e.g. this observer pattern above.

The trick is to have an intermediate class imbetween the observer and the observee which has an event. The observer hooks into the event, which is fired by the observee calling a public member on the intermediate class.

Not a perfect solution, but it does prevent access to the protected members on the observer class.

Of course all of this is taken care of with events in .NET anyway - which removes much of the need for friends.

You can declare methods in C# as being 'internal' which means they are not visible to classes outside of the containing assembly. This sort of removes the problem really.

Darwen.

[boudino]

There is no simple couterpart of C++'s friend in C#.

If you need one class to access private/protected members of another and you want to avoid inheritance, than you can define the friend class as nested class. E.g. If B should have access to A's members, you can

public class A
{
public class B
{
...
}
...
}

[Norfy]

Hi Darwen,

sorry I wasn't clear, but I meant a real-world example in C# that required the C++ friend concept.

As you say, "Of course all of this is taken care of with events in .NET anyway - which removes much of the need for friends".

The use of interfaces also helps to remove the need.

In your C++ example I'm not sure why OnMessage would need to be protected. In general it would only be called by the Observed but could be called directly if required. "Protected" methods are usually internal to a class. The use of "friend" here has broken encapsulation.

Observer Pattern in C# (http://www.dofactory.com/Patterns/PatternObserver.aspx)

[mehdi62b]

Thanks to everybody helped me here,
I did it like below.

public abstract class Vehicle
{
protected class Wheel
{
// details of wheel
}
protected Wheel wheel;
// vehicle details
}

public class Car : Vehicle
{
// car specifics
}

public class Bus : Vehicle
{
// bus specifics
}

I think it would be a good idea?

[Complete]

I would like to revive this topic.

Are we saying that there is no such thing as a friend class in C#?

I am using a dll in my C# project that I have the source code for and yet I do not want to modify the existing code. I have inherited the class and I can use my inherited class any way I want. The problem is that most of the code in the parent class has protected methods. Will using a friend somehow make it possible to access or call these protected methods?

[BigEd781]

You can always call protected methods of the base class in a derived class, you cannot call private methods of the base class.

[MadHatter]

reflection is also an option (albeit as poor a design choice as a friend in C++).

[Mutant_Fruit]

class CToBeObserved;

class CObserver
{
friend CToBeObserved;

protected:
virtual void OnMessage() = 0;
} ;

class CToBeObserved
{
private
void SomethingHappens()
{
m_pObserver->OnMessage();
}
};


But this isn't the observer pattern. You're supposed to be oberving 'CToBeObserved', so the event should be on 'CToBeObserved' and that should be the only class raising 'OnMessage'. You don't require friend to make this work right, you just need to use the observer pattern correctly ;) The usual pattern in C# is to allow subclasses to raise the event too:


public abstract class BaseClass
{
public event EventHandler<MessageSentEventArgs> MessageSent;

protected virtual void RaiseMessageSent (object o, MessageSentEventArgs e)
{
EventHandler<MessageSentEventArgs> h = MessageSent;
if (h != null)
h (o, e);
}
}

Now all subclasses can control when MessageSent is raised. Observers have no say in the matter, they just 'observe' when the event is raised. In your example, you're doing the opposite, you're telling each observer that the change has happened which requires the use of 'friend' to make it work.