Hacker News new | ask | show | jobs
by Rayhem 608 days ago
I've come to understand that software has two axes: the problem domain and the software domain.

The problem domain is things like your physical model. Your 3d mesh. Financial transactions. All things that need to be represented in software.

The software domain is things like components and queries. Things you can build in-software to realize your problem domain on a computer.

Defining a component and the behaviors of a component has nothing at all to do with the problem domain; it's purely an artifact of software to make your system more extensible/reliable/faster/whatever. But this is the part that's OOP excels at because you get to write the rules of your component taxonomy in its entirety. You have a ThingDoer class that can accept any number of Components to give it the behaviors you need, and then you start writing out components to model your problem domain. The objects and their behaviors remain at the level of "how do I put these pieces together". OOP sucks for the problem domain, though, because you're always stuck trying to munge some limited inheritance tree (animal <- dog <- wolf) onto the Real World and it's always going to miss something. Far better to build atomic building blocks that are expressive enough to compose into whatever you need.