4 ms·
It is really hard to decide on the best way to model, since it doesn't resemble any real-world programming problem. But OO culture has an unfortunate tradition
by olavk 12y ago
It is really hard to decide on the best way to model, since it doesn't resemble any real-world programming problem.
But OO culture has an unfortunate tradition of using bad examples by using physical objects as analogies for objects in code. Cars, fruits, students, teachers, whatever. Problem is, objects in code rarely correspond to physical objects. In the cases where physical objects are represented, it is most often in the form of database entities, which are typically treated like data-objects, which makes the discussion in the example moot.
- JoeAltmaier 12y agoBetter examples? Behaviors. States. Event processing machinery. Objects to help support those things. Containers are also used to demonstrate OO, but they're so abstract only a compiler geek could love them.
- spdustin 12y agoIn my experience as a technical instructor -- who frequently has to introduce concepts like the HTML DOM to students who have a hard enough time with markup -- overly simplified metaphors can get over the "can't learn, too hard!" barrier that adults tend to put up when they're expected to learn something new. FWIW, I use the car metaphor, and as a class, we all break it down into simplified properties, methods and events.
- adwn 12y agoYou hit the nail on the head. Objects in OO shouldn't be a projection of the problem domain, they're a way to structure the program (there's some overlap, of course). Many people seem to get this wrong, probably in part due to introductory examples doing it wrong.
- platz 12y agoI suppose you disagree with Eric Evans method of Domain Driven Design (DDD - http://domainlanguage.com/ http://domainlanguage.com/) Don't people who practice DDD, including Martin Fowler, commonly talk about the benefits of some of it's concepts, while modeling the Domain using Aggregrate Roots, Bounded Contexts, etc?
- huherto 12y agoMartin Folwer talks about several approaches for handling domain logic. Transaction Script, Domain Model, Table Module, and Service Logic. He explains the trade offs of each on the Patterns of Enterprise Application Architecture book.
- platz 12y agoSince then he has also written a lot more as well, for example http://martinfowler.com/tags/domain%20driven%20design.html http://martinfowler.com/tags/domain%20driven%20design.html . While less a direct connection, folks who use DDD a lot also find CQRS (command query responsibility separation) a natural fit and are often seen being used together.
- huherto 12y agoYeah, that makes sense. It simplifies both.
- huherto 12y agoThose examples are used for teaching because they are interesting for novices. In a real project, you use your objects that are useful for organizing your code. Modules, layers, gateways to external systems, etc.