Unit Testing, Agile Development, Leadership & .NET - By Roy Osherove
Dealing with legacy code
Maybe I'm imagining here, but "interfaces everywhere" seems like a Code Smell to me. One way to help preserve security while not forcing every class to have an interface would be to allow mocking of arbitrary classes as long as the mocking class is in the same assembly as the class being mocked. Of course, there is alwalways ILMerge...
I feel that making all methods virtual, avoiding the sealed keyword like fire and extracting an interface from every class and using it extensively are great propositions for possibly a vast majority of all the code out there.
Still, if you are writing for performance and have performance in mind, virtual methods cost you, non-sealed methods cost you, and interface dispatch costs you even more. After all, correctness is a must, but performance is very valuable (and sometimes a must) as well.
So while your suggestions might be valuable in general, I think it would have been appropriate to note that there are many many exceptions to these rules.
Design Patterns/Software Design/Agile The Presenter First Pattern End to End, or, Another Run on the Hamster Wheel of Life Build your own CAB Part #8 - Assigning Responsibilities in a Model View Presenter Architecture Build your own CAB Part #9 - Domain
Pingback from TDD Articles « blog / plan
Pingback from Niceboomer and the future of changes » Blog Archive » Tips for Testable code and for testing legacy code