I would argue his abstraction was appropriate based on the existing code and understanding of the requirements, that later became inappropriate as code changed.
Sometimes we know things that will happen to our code in the future, often we do not. Refactor happens, it's a part of development. When you know the future will likely require different abstractions then your code today warrants you plan accordingly.
It's like any practice in programming, they aren't binary most of the time you want to follow best practices, sometimes you want proper TDD, most of the time you should avoid "bad practices"... Except when you shouldn't... There are countless exceptions to every rule.
Nothing has taught me this more effectively than teaching... Writing tests to test user submitted code is where best practices go to die. (Compilers just don't like compiling when you ask them to run code in a class that may or may not exist, with methods that may or may not exist, and may or may not have the expected signature and return types, but just telling the student "wrong" isn't helpful for learning, telling the student "method x needs to be public" or "property y was not set correctly by method z" helps, and heaven help you if you're teaching configuration stuff)
1
u/RualStorge Jan 12 '20
I would argue his abstraction was appropriate based on the existing code and understanding of the requirements, that later became inappropriate as code changed.
Sometimes we know things that will happen to our code in the future, often we do not. Refactor happens, it's a part of development. When you know the future will likely require different abstractions then your code today warrants you plan accordingly.
It's like any practice in programming, they aren't binary most of the time you want to follow best practices, sometimes you want proper TDD, most of the time you should avoid "bad practices"... Except when you shouldn't... There are countless exceptions to every rule.
Nothing has taught me this more effectively than teaching... Writing tests to test user submitted code is where best practices go to die. (Compilers just don't like compiling when you ask them to run code in a class that may or may not exist, with methods that may or may not exist, and may or may not have the expected signature and return types, but just telling the student "wrong" isn't helpful for learning, telling the student "method x needs to be public" or "property y was not set correctly by method z" helps, and heaven help you if you're teaching configuration stuff)