I'm developing a WPF desktop app, which is fairly "self-contained" - there is no public API or anything like that. I'm using Castle Windsor for my DI needs. While I understand the need for interfaces where there a possibility of change, I still often end up creating an interface for each class, even though there will only ever be one concrete implementation. I do this just to make it easier to unit test a class, allowing me to mock the interfaces injected into its ctr. If I didn't create these interfaces, the only way to mock such dependencies seems to require the addition of a public, parameterless constructor to those classes, and make their members "public virtual". Neither approach feels quite right - adding artifacts in my code just to support unit testing. How do others tackle this?
I also struggle a bit with class visibility. I find that most of my classes are internal, but with public constructors (to satisfy Castle Windsor), and public members (to satisfy unit testing, as above). Again, it doesn't feel right having this odd mix of visibility in a class - or am I worrying unnecessarily? Similarly, let's say I have some public classes (e.g. helpers) in a shared/reusable library, and these have dependencies of their own that I don't want exposing publicly. I can't make these dependencies internal (you can't inject an internal class into a public ctr), so these classes end up being public too. Is this a problem, or does visibility only become important when developing some kind of customer API? Thanks in advance Andy -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/castle-project-users. For more options, visit https://groups.google.com/d/optout.
