Sign in to follow this  
janta

[C#] Alternative to C++'s friend

Recommended Posts

Class names below don't refer to the .Net ones, they're a generic description of my "problem"
class Object { ... }

class Collection
{
    private Object[] objects;
}

class System
{
    public void DoSomethingUseful() { /* with collections */ }
    private Collection[] collections;
}
Here, System is the class that exposes functionality to other systems. It needs to access and alter the state of the objects in the collections. In C++ I would have made System a friend of Collection. What would you do here? 1. Redesign the whole thing to get rid of that intermediate Collection class? 2. Add an accessor to Collection to the Object[]? This is bad because no one is supposed to alter the objects in a Collection, except the System... 3. A mix of partial and internal (for example, make Collection partial, and add an internal accessor in System's assembly)? 4. Move part of the code in DoSomethingUsefull to Collection, passing necessary other collection(s) in parameter? 5. Something else... What is your opinion?

Share this post


Link to post
Share on other sites
They aren't. They could be, but big files are somewhat less manageable.
Would you suggest that I made Collection internal with all its members public?

Share this post


Link to post
Share on other sites
I hope it is not a nuance of a poor choice of examples, but why do you have a collection class instead of using a generic collection such as List<Objects>? Then you can directly manipulate them, as the collection is a member of System.

Edit: For instance, a collection of collections could be List<List<Objects>>

Share this post


Link to post
Share on other sites
Quote:
Original post by arbitus
I hope it is not a nuance of a poor choice of examples, but why do you have a collection class instead of using a generic collection such as List<Objects>? Then you can directly manipulate them, as the collection is a member of System.


I could do that, that would be my possible solution #1. Having the Collection class allows me to not have code that deals with a single collection only in the System class which I reserve to expose functionality and processing that involve two or more Collections (So that System doesn't grow to a huge class). The Collection class also allows me to store per-collection data (like an ID, some global parameters, etc.)

But I started this thread so that you can comment on this design, so I'm open to doing things differently

Share this post


Link to post
Share on other sites
Quote:
Original post by janta
They aren't. They could be, but big files are somewhat less manageable.
Would you suggest that I made Collection internal with all its members public?


My experience is that if two classes are tightly coupled enough to need friend-level access, then that's enough of a reason to have them in the same assembly. If they are tightly coupled but shouldn't be in the same assembly, you might want to ask yourself if you have a design problem.

Either way, I would suggest making the members in question internal, and moving the two to be in the same assembly (and refactoring as needed so that makes sense).

Share this post


Link to post
Share on other sites
I am not sure about the correctness of your design but depending on the actual effect you want a LinkDemand might provide kind of solution too.

Share this post


Link to post
Share on other sites
Quote:
Original post by janta
Quote:
Original post by arbitus
I hope it is not a nuance of a poor choice of examples, but why do you have a collection class instead of using a generic collection such as List<Objects>? Then you can directly manipulate them, as the collection is a member of System.


I could do that, that would be my possible solution #1. Having the Collection class allows me to not have code that deals with a single collection only in the System class which I reserve to expose functionality and processing that involve two or more Collections (So that System doesn't grow to a huge class). The Collection class also allows me to store per-collection data (like an ID, some global parameters, etc.)

But I started this thread so that you can comment on this design, so I'm open to doing things differently


That is going to be the difficulty here, because there is nothing analogous to "friend" in C#, so the design solution that fits your needs will vary depending on what you are hoping to achieve. I would go with the internal keyword and keep the classes in the same assembly. They are too tightly coupled to do otherwise IMO. Or perhaps you can rethink the necessary access modifiers on the Collection class.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this