3 ms·
Here are some nice comments on LTU that explain what I think the GP meant. http://lambda-the-ultimate.org/node/3265#comment-48061 http://lambda-the-ultimate.or
by tree_of_item 15y ago
Here are some nice comments on LTU that explain what I think the GP meant.
http://lambda-the-ultimate.org/node/3265#comment-48061 http://lambda-the-ultimate.org/node/3265#comment-48061
http://lambda-the-ultimate.org/node/3265#comment-48063 http://lambda-the-ultimate.org/node/3265#comment-48063
The general idea is that your objects should model the program, not the domain.
Games may blur this line since they are simulations in some respect, which is a situation where you actually do want to model the domain. That doesn't mean you need anything as unsubtle as classes with a 1:1 correspondence to domain objects, though, which is what this article is about.
- Natsu 15y agoI think the problem exists because people hear "object" and they think of physical objects, when, as you say, the objects in OOP are supposed to be something more abstract: a means of gathering together common code and common data, not a means of creating digital mirrors of real objects.
- gte910h 15y agoObjects when not doing a simulation are merely syntactic sugar of keeping the data and the functions that act on them very close to each other in a very tightly coupled way, while keeping other functions more loosely coupled. Trying to simulate things that don't require simulation (aka, modeling physical properties), is a bad idea. You're not really making a program then, but a very specific, complicated subset that requires way more work and doesn't get your job done.