Had to work with some code I wrote a few years ago where I went maximally polymorphic for the hell of it - it was just as painful as when working with badly documented and poorly tested dynamically checked code.
Show this thread
-
Because often the cost of developing the polymorphic version isn't high. When you write the concrete version, and you discover you need similar functionality again, you have a choice between generalizing the first one & updating its call site and writing a new concrete version.
Both of those are less desirable than simply using the polymorphic version you wrote the first time. That's not to say premature generalization is always a good idea: it certainly isn't. But it's not a universal truth that you should do the minimal that solves today's problem.
-
-
It really has to be a balancing act: how reusable can you make the first implementation? How likely is it that you'll need it? How difficult is it? How opaque will the implementation be?
-
*This*, on the other hand, is what I mean. Each approach has its own trade-offs, and you need to decide which is appropriate for each situation. I tend to err on the side of readability because I spend more time reading code than writing it, but that's entirely personal.
End of conversation
New conversation -
-
-
I didn't mean to argue that doing the strict minimum to solve today's problem is always the best way to go, but that always making things as abstract as possible because it might be useful later isn't. It's possible I got lost on the way though.
-
Yeah, I didn't want to make a strawman out of that, because I saw your original point was about "maximally-polymorphic" code. But I wanted to take the opportunity to argue against "doing the minimum possible".
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.