[.net] Code Pattern searched (or similar)
Author
Hey there,
I'm programming with C# for more than 18 months now and I really like the language for personal usage.. but one thing that really bothers me is the absence of C++ like friend classes.
In C#, if you've got two separate classes that need to know each others internal resources, how would you do this? I normally nest the smaller one inside the bigger one if this isn't too crazy, so at least one can access the other ones data.. but that's just a bad surrogate.
Isn't there any C-Sharpish code pattern, style guide or hint for that situation that I do not know yet?
Concrete case: A SoundManager and SoundInstances / SoundResoruces.
Any advice?
If one class needs to know the internals of another class, you make a public properties and methods on the other class. Internal resources are just that, internal to the class.
Another 'option' is to use the internal keyword and put the two classes in a single assembly.
And you can combine this with InternalsVisibleToAttribute
And you can combine this with InternalsVisibleToAttribute
Author
I know both, I use both, and both methods aren't really a solution for this problem - they're just different things.
Author
Yeah, well... just wanted to hear if there was some kind of code pattern or trick to do similar class relations in C# too. Seems like a "no" then :D
This is generally considered bad form but you can emulate friend classes using "internal" and the InternalsVisibleTo attribute.
There's absolutely no reason to use friend classes here. Design a correct interface and work with that.
Quote:Concrete case: A SoundManager and SoundInstances / SoundResoruces.
There's absolutely no reason to use friend classes here. Design a correct interface and work with that.
Author
InternalsVisibleTo only works with two assemblies, so this is not an option here. Also I'm not interested in writing bad code, so any suggestion directly going with "This is bad, but.." won't help me much :D
How would you design this instead?
A SoundInstance is a sound that's currently playing. I've got a SoundManager who manages all SoundInstances alive. When creating a SoundInstance it registers itsself at the SoundManager.
The Soundmanager updates the SoundInstances and might need to know some internal data. I do not say, its necessary all the time - he just might.
Making the SoundInstance nested inside the SoundManager is just half the solution. It might also need to internally access the SoundManager, for example to register itsself there. Its possible to make that register function public but since noone else needs to access it, why make it visible to all?
Obviously I'm asking for how to do a good job, so "Design a correct interface and work with that." isn't really helpful.
How would you design this instead?
A SoundInstance is a sound that's currently playing. I've got a SoundManager who manages all SoundInstances alive. When creating a SoundInstance it registers itsself at the SoundManager.
The Soundmanager updates the SoundInstances and might need to know some internal data. I do not say, its necessary all the time - he just might.
Making the SoundInstance nested inside the SoundManager is just half the solution. It might also need to internally access the SoundManager, for example to register itsself there. Its possible to make that register function public but since noone else needs to access it, why make it visible to all?
Obviously I'm asking for how to do a good job, so "Design a correct interface and work with that." isn't really helpful.
Don't get too hung up on design paradigms you've picked up from other languages. If there's a specific part of your design that needs this C++ style access contract, you should consider describing to us what it is and seeing if somebody will help you re-factor it into a more C# friendly design.
Jans.
Jans.
Quote:
A SoundInstance is a sound that's currently playing. I've got a SoundManager who manages all SoundInstances alive. When creating a SoundInstance it registers itsself at the SoundManager.
It'd probably be better if SoundManager was a factory that created SoundInstances. It can then set properties in the sound instance and hook into sound instance events (OnPause, OnFinish, etc...). It can also register the sound before it returns it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
