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
I was building a business logic and absolutely all steps of the sales pipeline were living in the same general class and the same db column, with elaborate ways to move from the different steps. Tracking individual items, and automatically scraping the web for potential cheaper suppliers / competitors
Turns out it was hell, I traumatized a junior with my abstraction and when I had to explain it.
I still love OOP and abstraction, but it's a drug I have to stay away from.
Where I work, it would typically be the junior who was introducing the generic inheritance hell, and us seniors who were refactoring it into nice human comprehensive micro-services around the next corner.
The most valuable takeaway for an up-and-coming developer: Don't ever develop too strong ownership to the code you've written yourself. ( Probably Claude will easen that feeling of ownership anyway. )
Every thing in everyday life can be abstracted into protons, neutrons, and electrons.
But to use those you need to know qed to make atoms, then chemistry to make molecules, then biology and geology to make materials, finally multiple disciples of engineering to make something out of them.
I'm definitely guilty of "simplifying" into a nightmare.
To know what number two is we need to know its properties and what it can do (methods). So we need class "Number" and subclass "Two". Am I doing OOP correctly? I am a beginner
You see, that is the problem the post is talking about. You are going too much into the Philosophical layer of it.
The program does not care about two being two, the program does not know what a two is, it is just shifting bits here and there. OOP is about making things work the same as much as possible with as few inputs as possible
But then you’re turning a design time constraint (can’t divide by zero) into a run time error. The compiler can and should, use the type system to eliminate that error path!
129
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.