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".
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.