3 ms·
A more practical way of discussing this would be a concrete example of a business need, implemented in both paradigms - object-oriented design relying on inheri
by romankolpak 11y ago
A more practical way of discussing this would be a concrete example of a business need, implemented in both paradigms - object-oriented design relying on inheritence and then a more typical to FP design based on composability. Then by simply comparing the two we could draw some conclusions about code size, simplicity, maintainability and so on.
- lmm 11y agoThere's no way to do a small example because it's an issue that only happens when you already have a large codebase. Say you have a large, complex object - and you can argue that's already assuming something about your development path. And then you want to offer a variant that has slightly different behaviour (say it has an extra line when you print it, and one of the calculation methods should return 2x as much for this variant, and another method should return 0.5x as much - and again, that's making intrusive assumptions about the wider design). That kind of scenario really does happen all the time in real-word functional code (at least for me), but it's impossible to make it a rigorous example where partisans can't say "don't do that then".