In this previous post I mentioned that I'm not that impressed with the Template Method pattern. If you let them grow too big they be
come unreadable, untestable chunks of code that are tucked away in protected methods in subclasses that you don't call directly.
This is a simplified version of the class-diagram I showed in my last post. The main code-smell that caught my attention were the protected methods in the subclasses. The ReadHeader and ReadLine methods are only called by the ReadFile method. That's a good argument to keep them protected. But I'd like to test them separately.
Usually when you want to make code public just for testing it's a big sign the code is in the wrong class and it's refactoring time. The ReadHeader and ReadLine method shouldn't be in the TabularFileReader class but they should be in their own class hierarchy. This way they can be tested separately but it will still be encapsulated neatly because the LineReader property of the TabularFileReader is private so the calling code can't access the LineReader that's used to read the file. Another benefit is that I could get rid of a nasty code duplication between the ReadHeader and ReadLine function. The LineReader classes only know about lines and splitting them up into fields. The TabularFileReader knows about headers and fieldnames.
The code is also potentially more reusable. You can use the LineReaders separate from the TabularFileReader.
So let's recap... what have we done. The variation in the class that contained the Template Method has been refactored into a separate class hierarchy. This makes things more testable. The LineReader has become a strategy pattern. The TabularFileReader can be injected with the right strategy to make it do whatever we want.
When you want to know what's happening the code get's a lot more readable. You're calling the TablularFileReader directly so when you click 'go to definition' from your calling code you can at least see the ReadFile method.