Internal classes
I've created a back end/"engine" project in a solution. I followed the default and set all my classes to internal without thinking much of it. Now when i want to use a front end in a different project, I'm finding that i can't access the internal classes (obviously) and thus can't do things like pass instances of such classes to my UI. Is this c#'s not so subtle way of encouraging me to define an explicit outward facing "interface"?
13 Replies
No, it's C#'s way of telling you that it probably should be public
Hmm... alright.
that would certainly make everything easier...
in terms of library development it's best to restrict visibility as much as possible
because it's a lot easier to make something public than to take it away once people are using it
alright...
theoretically in your project you should have a "section" (the public api) dedicated to external access which is undoubtedly public
personally I think this may be a good case to use interfaces, especially if you use a lot of DI there
So would I use public interfaces to access the internal classes? Seems like an interesting idea.
this is generally what interfaces are for 😄 you make a public interface and the implementation is internal. you will notice one big convenience - you can inject whatever you want into implementation's contructor and all dependencies would still be internal, because interface does not expose a constructor.
(of course this is only one of many purposes of interfaces)
You can have all the interfaces in the world, if the implementation is private it is private
yes - when you explicitly register stuff in DI container, this is perfectly valid case to use interfaces with an implementation
I don't think anybody mentioned DI here
I said " especially if you use a lot of DI there", but yes fair enough, there was no mentioning DI from the author. I wanted to point it out as a probably good idea of designing an app (unless its not some game for example)
Thanks guys.