How does this address the issue that if B is a static class (regardless of its level of complexity), you can't test class A without also testing class B (because you can't get A to work against a "mock" of B without changing the source code of class A)?
The complexity of class B is only an issue if you decide that it's unimportant that tests of class A are actually also tests of class B -- only if B is completely trivial is it ok to disregard the dependency on B. Class A's source code must "spell the name" of class B explicitly when class B is a static class. But class A could instead operate on an instance of any object that implements the needed interface (perhaps getting that instance passed to its constructor). Thus, it is much easier to "mock" the functionality of class B if you use singleton rather than static classes. (Again, the complexity of class B is not relevant.) At 03:42 AM 7/18/2006, John Brett wrote >>If Class A has a hard dependency on class B, then I can't mock it out. Now >>I'm not just testing A, I'm also testing B. > >That sounds like a good definition of when to use static classes and when >to use singletons. > >Like Shawn, I use static classes for utility code fragments, but only where >the code has no dependencies on code outside of the framework. If the >class becomes more complex, it becomes a singleton. > >John J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
