| > object oriented code for domain modeling I'm not sure about that. If we're talking about IT (information processing in general), then the domain model is just data representing facts and should probably be treated as that, and not some metaphorical simulation of the world. I've come up with a pretty useful test for when to apply OO: When you need to model a _computational unit_[0] in terms of _operational semantics_, then use OO. [0] Decidedly _not_ a simulation of a metaphor for the "real world". --- Examples: A resizable buffer: You want operations like adding, removing, preemptively resizing etc. on a buffer. It's useless to think of the internal bookkeeping of a buffer that is represented in its data structure when you use it. A database object: It wraps a driver, a connection pool etc. From the outside you want to configure it at the start, then you want to interact with it via operations. A HTTP server: You send messages to it via HTTP methods, you don't care about it's internal state, but only about your current representation of it (HATEOAS) and what you can do with it. A memory allocator: The name gives away that you can _do_ things with it. You first choose the allocator that fits your needs, but then you _operate_ on it via alloc/free etc. --- Some of us wince when we hear "OO", because it has been an overused paradigm. Some advocates of OO have been telling us that it is somehow total (similar to FP advocates) and people have been pushing back on this for a while now. When applied to information processing especially, it becomes ridiculous, complex and distracting. I call this "Kindergarten OO": You to write code as if you explain the problem to a child via metaphors. Computational objects however arise naturally and are very obvious. I don't care if those are encoded as classes, with closures or if we syntactically pretend as if they aren't objects. They are still objects. |