Hi,

Do you use friend to avoid security problems of public functions ?

Yes, I always get a friend to keep a lookout when I urinate in public.

For example a public function "Notify" called by all class managed by this class when something change.

The user of the API should not have access to this function, but it's needed to be public to be called.

But it's not a security problem here.

Security problem could be a function which change a private array, only needed by class managed by the class which contains this function.

Since it's public, it can be called by the user of the API, which can cause problem.

If you're truly concerned with security, that is, you want to prevent malicious users of your API from doing things that could be harmful to other users or to you, then making functions private will do very little to help you achieve your goals of protection. If a malicious person wants to call a private function, they only need to discover its existence, find its location in the executable, determine the proper calling convention and parameters, and then they can freely call it with whatever parameter values they want. While the above steps aren't trivial, especially for your average script kiddie, for a well practiced malicious agent it's not that hard.

If on the other hand you want to protect an innocent user from naively doing things that might accidentally cause them or others hard, then yes, friend can sometimes be a tool to help you achieve this goal, although it is debatable if it often or ever the most appropriate tool. I don't have a strong opinion personally, except that when I do use it, I take extra care to ensure that it is justified, and that I'm not overlooking a better solution due to lack of imagination or experience. I'll use it more freely in prototypes because the code tends to be throw-away. In more long-lived code, or when refactoring code that I thought was going to be throw-away but apparently is outliving its expected lifespan, I am biased against it.

Note that when Microsoft designed C#, they thought that this usage was valuable and justifiable enough that they added the "internal" keyword which is even more blunt than C++'s "friend" keyword. Though I suspect there's just as much debate over this language feature as exists for "friend".

I personally suspect that there's always a better tool, a better design or architecture available for providing a convenient, safe, and efficient API without resorting to the use of "friend". However, sometimes the cost of finding that alternative design and implementing it might be higher than the cost of just taking the easy route and using "friend". It's up the the wisdom and experience of the decision-making engineer to distinguish between those cases.

I had forgotten the details of what friend in C++ does... Working in .Net land most of the time, I can't remember really needing it.

The only time that I remember ever creating friend functions was for C++ ostream stuff. In .Net, you would just override ToString() in most cases instead, however.

C#'s internal is a somewhat different beast. In a nutshell, it is coarser, and basically means public, but only within assembly boundaries*. In that case, it can be useful if you want to hide your implementations to external consumers of your library, and force users to go through your publicly exposed interfaces. Or if you have some utility code that shouldn't be exposed. Of course with reflection, you can always get at things if you try hard enough.

Unit-testing gets to be a pain, though. I'm not real excited about having to mark what could be private, static, pure helpers as internal in order to be able to write tests in a test assembly. Although that pain is often an indication that there are refactorings that should be made.

* there's the whole InternalsVisibleTo mess,which lets you whitelist certain defined assemblies to poke at your internal bits.