The way I would test the parser would be to input a string representing a representative line of CSV and then assert on the object that was output. Then you jus

The way I would test the parser would be to input a string representing a representative line of CSV and then assert on the object that was output. Then you just do the simplest implementation that could work (which would probably look similar to your last code snippet), and only refactor that into multiple classes if you have a good reason. I don't think the "right" way you describe is somehow not following the principles of clean/GOOS/test driven code. They are still good principles to follow, but I think you've demonstrated that you can't follow them without weighing many different concerns at once - and that it's really hard to tell which ones should be more important than others until you've had some hard-earned experience.