C++ 'friend' keyword

  • Thread starter Thread starter Ben Galvin
  • Start date Start date
B

Ben Galvin

Hi,

I'm looking for an equivalent to the C++ 'friend' keyword in C# (for those
who don't know, this lets you give a specific class access to all the
private/protected members of another class).

I'm trying to write an object persistence mechanism where all of the
persistence logic for each class is situated in a seperate class (the Mapper
design pattern). The object itself is completely unaware of how it is being
persisted. This lets someone in the future write a new persistence layer
(e.g. to a different DBMS) without modifying the object code. The difficulty
is that this persistence class needs priviledged access to the class it is
trying to persist (i.e. it needs to set/get private members which ordinarily
shouldn't be accessed by code outside the class). In C++ you can do this
with the 'friend' keyword.

I'm aware you can do this with the 'internal' keyword, however this seems
much too coarse. I don't want to allow every piece of code in the assembly
to mess around with the internals of every other class. I don't want to use
a 3rd party object persistence framework as it needs to be very fast, and I
need a lot of control over it.

Is there any other way of doing this cleanly, or plans to allow this in C#
2.0?

Thanks,

Ben
 
"internal" keyword is replacement for "friend" in c#.

internal void myFunction()
{

}
 
Hi,

I'm looking for an equivalent to the C++ 'friend' keyword in C# (for those
who don't know, this lets you give a specific class access to all the
private/protected members of another class).

I'm trying to write an object persistence mechanism where all of the
persistence logic for each class is situated in a seperate class (the Mapper
design pattern). The object itself is completely unaware of how it is being
persisted. This lets someone in the future write a new persistence layer
(e.g. to a different DBMS) without modifying the object code. The difficulty
is that this persistence class needs priviledged access to the class it is
trying to persist (i.e. it needs to set/get private members which ordinarily
shouldn't be accessed by code outside the class). In C++ you can do this
with the 'friend' keyword.

I'm aware you can do this with the 'internal' keyword, however this seems
much too coarse. I don't want to allow every piece of code in the assembly
to mess around with the internals of every other class. I don't want to use
a 3rd party object persistence framework as it needs to be very fast, and I
need a lot of control over it.

Is there any other way of doing this cleanly, or plans to allow this in C#
2.0?

Thanks,

Ben
Click to expand...

Perhaps sadly, there is no exact equivalent: 'internal' is as close as
you can get.
However, a class defined within another class, such as:

public class Outer {
.....
public class Inner {
private Inner (Outer myOuter) {...}
}
}

has access to the privates of the outer defining class. You could also
add a constructor to Inner which takes an Outer (probably the instance
of Outer which contains it). This is how the GoF Memento pattern would
be implemented in C# and might be of help to you.
Other approaches I have seen include having constructors which take a
DataRow (for creation) and providing a method which either returns XML
(or some similar structure) or a DataRow for something else to use for
insert/update.
My own experience is that for reasonable performance and simplicity the
class itself[1] generates the SQL required for inserts/updates, which is
passed to something else for execution. If you possibly have different
RDBMS's as the backend this is an obvious case for the Strategy pattern.
This - to me - also ends up with the simplest structures. Sure, it pollutes
the classes with persistence code but OR is a difficult problem and you'll
find it very, very, hard to come up with a design which at some point doesn't
have to loose some sort of 'OO purity'. There are some good articles about
it on Scott Ambler's site (I think some of them have been withdrawn - he
want's you to buy his book!) at http://www.ambysoft.com/persistenceLayer.html


[1] I regard an Inner class as I mentioned to be really part of the Outer,
containing class. Delegating the SQL generation to that class helps in
making clear that the SQL stuff is not part of the main purpose of Outer
and makes it look slightly cleaner.
 
Back
Top