4 ms·
> A chair is a chair, in real life. But in terms of data-transformations, in terms of what we do, these classes are really only superficially similar. In the co
by rualca 6y ago
> A chair is a chair, in real life. But in terms of data-transformations, in terms of what we do, these classes are really only superficially similar. In the context of a game, we have a Chair, a PhysicsChair, a StaticChair, a BreakableChair. These things are not at all similar.
I feel like that comment either takes a very literal and naive analysis to the problem or fails to identify the objects being used.
Just because the word "chair" pops up in a few objects that does not mean they are supposed to be the same thing, and thus modeled as specialization of a common Chair class.
For example, PhysicsChair makes sense as a specialization of a physics-related class, not a Chair-related class. Breakable hair would also make sense as a specializationof a physics object, which might be comprised of multiple discrete elements or track damage to generate new particles when a threshold is reached. If we take the single responsibility principle seriously, it makes sense to have specialized physics and graphics classes that implement the functional requirements of handling a chair.
This by no means implies that class Chair should be a superclass of all these other cases, or even that it makes sense to even consider them to be related at all. A failure to identify the models and their functional relationships doesn't mean that your domain has to include relationships that don't really exist nor make sense.
- MaxBarraclough 6y ago> Just because the word "chair" pops up in a few objects that does not mean they are supposed to be the same thing, and thus modeled as specialization of a common Chair class. You agree with his point that class hierarchies shouldn't necessary model reality. > For example, PhysicsChair makes sense as a specialization of a physics-related class, not a Chair-related class. Right, that's his point. > A failure to identify the models and their functional relationships doesn't mean that your domain has to include relationships that don't really exist nor make sense. Again, that's the point he's making. In terms of modelling the world, they're all just different kinds of chair, but that's doesn't mean you should model it that way in code, with object-oriented types.
- rualca 6y ago> You agree with his point that class hierarchies shouldn't necessary model reality. I'm pointing out that this assertion is meaningless, because it completely misrepresents what is actually done with class hierarchies. The class hierarchies in the domain models (i.e., Chair) is never the class hierarchies used by components in the the service layer (i.e., PhysicsChair). Functional requirements of specific services never sleep into the domain model. Call it bounded context, single responsibility principle, or encapsulation, but even if we play little semantics games a home is not the same as a mobile home. Pinning together unrelated concepts based on the naive belief that sharing a keyword is enough to bundle concepts together just misrepresents the whole issue as a straw man. > Right, that's his point. No,the point is that it's absurd to talk about class hierarchies with this example, based alone on the simplistic idea that having the word "chair" appear in the identifier is all you need to logically bundle unrelated concepts. The example is poorly thought through even through the perspective of a straw man. > Again, that's the point he's making. In terms of modelling the world (...) That's what you are failing to understand: they are not modeling the world. At all. And from the start. Only the domain model (chair) models the world. The rest is not the domain model, but data types used in the service layer to meet functional requirements (i.e., PhysicsChair). Let's put it bluntly: the straw man you are trying to defend is something that no one one the world at all ever mixes up. Ever.