koobas.hobune.stream
What's the best way to hide classes when sharing C#?
I've made a cool thing, and I want to share cool thing. Said thing has many C# classes that make it work, and some of them have names like Face, Vertex, Model, and so on. Needless to say I don't want to muck up peoples namespaces with these. These classes will only be used inside of the thing I'm sharing, and there's only one class the user needs access to to make the whole show work. What's the best way to hide the others?
Should I put them all in a namespace, and just have the user "using CoolThing'" in the script they need to use the cool thing in? There will only ever be once of these in a scene, and therefore this will have to be done on exactly one script. (which I have included for them).
Is there an easier/better way to isolate my internal classes from the rest of the world?
If you're developing a framework, meaning other people access your framework from a different assembly, the best way is to use the internal keyword.
If, for some reason you need to share the assembly with those other programmers, you can prevent polluting the global namespace unnecessarily and restrict access by other programmers by making all your not accessible classes nested private classes within the only public class. Sort of like a makeshift namespace (possibly within another namespace).
Consider the following:
public class PublicClass : MonoBehaviour{
private class HiddenClass{}
private class NotAccessibleClass{
HiddenClass h = new HiddenClass(); //works
}
}
public class TestClass{
PublicClass.NotAccessibleClass attempt; //compilation fail
}
Only PublicClass will be visible to the End-User (MonoDevelop's IntelliSense will show the 'hidden' classes if you try the dot-notation on it). Everything else works internally like it should, assuming you don't need to inherit from MonoBehaviour and use Unity-functions in the nested classes.
even if you use your own namespace, there's still a chance for some confusion when referencing your objects, etc. versus unity's own.
ideally, you'd prefix yours with something to avoid that situation, along with its own namespace.
