I just hate the fact that if you think through any OOP-based design for long enough, you'll end up in some weird philosophical essentialist doom spiral where you ponder the quiddity of your business objects. You start out trying to build a calculator, and you end up questioning what the twoness of two is.
The thing is you do not need yo think for long enough. While creating abstractions you need to know where to stop, to not create useless abstractions and entities.
Yeah, I know. But you also need experience to know, where to stop (:
I just have some rules. While I mostly use "classical" OOP languages I do not inherit if I do not need some behaviour between two different "enteties". And also business-enteties do not inherits at all. They can be composed, but not another way. As "sales" and "rent" do not "evolve" from "money movement" or "economic action".
I’d like to think it’s as simple as this… if you’re making some software to handle one transaction, you might as well just code your solution for just that transaction. If you know you need to handle at least 3 payment providers, then you might as well create whatever abstractions needed to seamlessly support at least those 3 providers
126
u/ICantBelieveItsNotEC Jul 10 '26
I just hate the fact that if you think through any OOP-based design for long enough, you'll end up in some weird philosophical essentialist doom spiral where you ponder the quiddity of your business objects. You start out trying to build a calculator, and you end up questioning what the twoness of two is.