Hi Andy, I personally don't think it's a big deal. I also create interfaces for my classes just so that I can unit test the different parts of code independently. At the end of the day, if you don't create an interface then you're not really unit testing, because you're depending on actual instances of the dependencies. So I'd stick with what you're doing.
About visibility - I honestly don't think it matters if you're not creating a public API. And even then, the only reason I'd care about visibility would be to make the API easier to understand for consumers. I personally hate using internal visibility. In my experience, all it ever does is causes me grief. Especially when third party libraries end up making objects that I need to create for the sake of unit testing with internal visibility. My vote is to avoid internal and sealed like the plague. Basically, I wouldn't worry about it. Cheers, Adam On 25 March 2014 11:20, Andy <[email protected]> wrote: > 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. > -- Adam Connelly *Software Developer* <http://resdiary.com/> *View our Short Video presentation <http://www.youtube.com/watch?v=09TuCL1mOu4>* Sales.......+44 (0)207 871 7491 Support....+44 (0)207 871 7490 DDI..........+44 (0)141 404 1441 Restaurantdiary.com Ltd. Registered in Scotland | Company No. SC258100 | Registered Office: 75 Bothwell Street, G2 6TS VAT Registration Number: GB829960776 PCI Compliance<https://sealserver.trustwave.com/cert.php?customerId=62ba0c8cb2344f8789374c544a067258&size=65x36&style=invert> -- 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.
