4 ms·

> Lots of classes don't have a "real world" equivalent (linked lists, allocators, renderers, finite-state machines, functors, observers, octrees, parsers/loader

> Lots of classes don't have a "real world" equivalent (linked lists, allocators, renderers, finite-state machines, functors, observers, octrees, parsers/loaders...). The "real world" will mostly give you incentive to abuse inheritance, while missing what the interfaces and abstractions are. This is a pretty myopic view of what exists in the real world. Lists absolutely exist in the real world: a shopping list, a to-do list, a list of messages received. Lists are such a common data structure because they frequently provide a good model of things in the real world, in this case, a way that humans organize sequential items, tasks, or messages. As for your other examples, sure, some of them are pretty poor pretty poor representations of what exists. And that's a great argument for why you should find a better abstraction. My argument from square one was that you should be modeling your things off the real world. > everything "Rockety" (audio rendering, video rendering, serialization, target following, collision detection, ...) Really? In what world do you live where Rockets render audio? Again, this is just a straw man. What you're describing isn't even attempting to model reality, so you can't use it as a basis for arguing against modeling reality.

jstimpfle 10y ago
As I already said, your tone is annoying. Your parent's arguments are very clearly presented (and perfectly sensible); there is no need to twist words to "prove" him wrong. >> everything "Rockety" (audio rendering, video rendering, serialization, target following, collision detection, ...) > Really? In what world do you live where Rockets render audio? Please, stop putting words into others' mouths. Actually what you do is my understanding of straw mans.
- devishard 10y ago
  I'm not saying that he said rockets render audio, I'm saying that has nothing to do with modeling the real world. If you're criticizing the idea of modeling the real world, we should talk about actual models of the real world.
  - jstimpfle 10y ago
    We agree it's not a good way. But it's how the stereotypical OOP project will implement it. The other way I'm familiar with is implementing rocket audio rendering at a central location (where also sheep and houses audio rendering is implemented). That's the data oriented way. But the "drawback" is that one then needs access to the "raw" rocket data (one could still do it with a Rocket class, but would have to make a very complicated data-getter interface). Not very OO. Thanks for your friendly reaction to my criticism, by the way.
Ace17 10y ago
> Really? In what world do you live where Rockets render audio? a shooter video game using procedural generation / sound synthesis?
- devishard 10y ago
  That's not "modeling the world", or if it is, it's a very bad model of the real world. Rockets don't render audio.
  - Ace17 10y ago
    Rockets do make their own rocket noise, don't they? (if you prefer, we can call this "sound synthesis" instead of "audio rendering"). My point is that this code probably shouldn't be in the same class than, for example, the "target following" code. It would be an obvious violation the single responsibility principle (SRP). Actually, I've seen lots of SRP violations caused by blindly "modelling the real world" (shape drawing functions inside the "Picture" class, inverted inheritance hierarchies, focusing on implementation reuse instead of focusing on interfaces, Square class derived from Rectangle class, ...). This alone is not a good enough design guide, and is sometimes counterproductive. Have a look at how game developers struggle with deep class hierarchies. Many of them are moving, for the better, to Entity/Component based designs. This is a step back from "real-world modelling" (since you don't need/have a "Rocket" class anymore).
Ace17 10y ago
(Please note that I was specifically talking about "linked" lists: when we use them, their "linked" part rarely matches something in the real-world) OK, let's go for more examples of well-used classes not representing real-world things: a solver, an interpreter, a compiler, an AST, an arithmetic expression, a grammar, a saved game, a DSP filter, a target architecture, a process, a thread, an AI script, ... My "Rocket" example isn't a strawman, it's a counter-example. You can ignore the audio rendering part if you don't find it plausible.

jstimpfle 10y ago

As I already said, your tone is annoying. Your parent's arguments are very clearly presented (and perfectly sensible); there is no need to twist words to "prove" him wrong. >> everything "Rockety" (audio rendering, video rendering, serialization, target following, collision detection, ...) > Really? In what world do you live where Rockets render audio? Please, stop putting words into others' mouths. Actually what you do is my understanding of straw mans.

devishard 10y ago
I'm not saying that he said rockets render audio, I'm saying that has nothing to do with modeling the real world. If you're criticizing the idea of modeling the real world, we should talk about actual models of the real world.
- jstimpfle 10y ago
  We agree it's not a good way. But it's how the stereotypical OOP project will implement it. The other way I'm familiar with is implementing rocket audio rendering at a central location (where also sheep and houses audio rendering is implemented). That's the data oriented way. But the "drawback" is that one then needs access to the "raw" rocket data (one could still do it with a Rocket class, but would have to make a very complicated data-getter interface). Not very OO. Thanks for your friendly reaction to my criticism, by the way.

Ace17 10y ago

> Really? In what world do you live where Rockets render audio? a shooter video game using procedural generation / sound synthesis?

devishard 10y ago
That's not "modeling the world", or if it is, it's a very bad model of the real world. Rockets don't render audio.
- Ace17 10y ago
  Rockets do make their own rocket noise, don't they? (if you prefer, we can call this "sound synthesis" instead of "audio rendering"). My point is that this code probably shouldn't be in the same class than, for example, the "target following" code. It would be an obvious violation the single responsibility principle (SRP). Actually, I've seen lots of SRP violations caused by blindly "modelling the real world" (shape drawing functions inside the "Picture" class, inverted inheritance hierarchies, focusing on implementation reuse instead of focusing on interfaces, Square class derived from Rectangle class, ...). This alone is not a good enough design guide, and is sometimes counterproductive. Have a look at how game developers struggle with deep class hierarchies. Many of them are moving, for the better, to Entity/Component based designs. This is a step back from "real-world modelling" (since you don't need/have a "Rocket" class anymore).

Ace17 10y ago

(Please note that I was specifically talking about "linked" lists: when we use them, their "linked" part rarely matches something in the real-world) OK, let's go for more examples of well-used classes not representing real-world things: a solver, an interpreter, a compiler, an AST, an arithmetic expression, a grammar, a saved game, a DSP filter, a target architecture, a process, a thread, an AI script, ... My "Rocket" example isn't a strawman, it's a counter-example. You can ignore the audio rendering part if you don't find it plausible.