So one of the things I've noticed since I've been at my new place of employment, is that people are passionate about their code! I love it! I have always been, and its great to be in a place where everyone else is as passionate about it as I am.
Onto the issue at hand. Along with passion, comes strong opinions (of course).
Statement: I always want to create an interface for any service or class that collaborates with other services or classes.
IMO (I've got one too!), testability is THE first class citizen (second only to working, value-adding software).
Having an interface on any collaborating service provides me the ability to (at least):
- Test after the fact
- Swap in a new implementation later
Why not? (my response to each in red)
- YAGNI - "Why do you need an interface if there is only one implementer? We'll create the interface or base class when there is a second implementer".
There already is a second implementer... the tests! Nuff said. (which is a nice segue into the next point...)
- Testability should not affect the design.
Ahem, isn't our goal working software? How do I know it works if I can't write tests for it? This directly opposes the entire idea of TDD. TDD is not so much about testing, as it is about it being a design tool.
- Just "subclass and override".
Have you ever read Working Effectively with Legacy Code? This is the epitome of a legacy code technique
Dear reader (I doubt there are any),
What do you think? Are there things I missed on either side of the equation? I want your opinions.