3 ms·

>> > And even in an OO language, no decent practitioner writes one-class-per-object. > But that's the stereotypical example of OO design. You have duck->paint(

>> > And even in an OO language, no decent practitioner writes one-class-per-object. > But that's the stereotypical example of OO design. You have duck->paint(), duck->quack(), duck->plunge() all in one class (file) and of course the dependency mess and the scattering of aspects throughout the project. So much nonsense here. One class per object is absolutely not the stereotypical example of OO design. class != file. And dependency management is usually a problem because junior devs pull in a billion half-baked libraries to solve a problem--it's not an inherent problem with OO and it's certainly not a problem with trying to model the real world. I'm not even particularly in love with OO. I particularly think that functional paradigms often do a better job of modeling the real world. What I'm really disagreeing with is the claim that modeling the real world is a bad practice. > And even if you make more classes, so that your design is more like one class per concept/aspect, I think the criticism of Mr. Acton is: if you have many instances of a given class, then there must be a better way than calling a method on each individual instance. If that was Acton's criticism, then he should have said that instead of saying that "code should be designed around a model of the world" is a lie. Particularly since if you're acting on a large list of objects, then representing it as if you're going through and then each object is acting is a pretty bad representation of reality. > In other words, the idea is that classes are fine (they promote modularization), but there shouldn't be more than one instance of each class. Now you're just confused. Acton specifically was criticizing one instance per class in the section I quoted, and now you're saying that's what he's supporting? And for the record, if there's only one instance of your class, you didn't need a class.

jstimpfle 10y ago
No need to get personal. > So much nonsense here. One class per object is absolutely not the stereotypical example of OO design. I didn't say that. I said: The stereotypical example is "one class per (concept / class of) real world thing(s)". Like "Rocket" or "Duck". > If that was Acton's criticism, then he should have said that instead of saying that "code should be designed around a model of the world" is a lie. It needs just a little context or reading between the lines to understand the intentions instead of twisting words to make accusations. > Now you're just confused. Acton specifically was criticizing one instance per class in the section I quoted, and now you're saying that's what he's supporting? I am not confused. He wasn't criticizing "one runtime instance per class", but "one per runtime instance per real world thing". That's something different. The quote reads rest assured that there is a "Rocket" class which contains data for exactly one rocket. I translate, he suggests to combine all "real world rockets" in a single runtime object instead of representing each rocket in its own runtime object. Concretely, he would make a "Rockets" class instead of a "Rocket" class, because that typically allows for simpler and more efficient implementation. (Of course, if there were also planes or missiles or bullets, he would think twice before making a Rockets class). As I commented elsewhere on this page, there are very close analogies to relational databases -- especially the column-store flavour.
- devishard 10y ago
  Okay, given your understanding of what he said, I can see why you might agree with him (although I don't), but critically, that's not what he said.
  - dottrap 10y ago
    Mike has given multiple talks on Data Oriented Design. Another example he gave at CppCon was a Chair class. In a real game, you may have a static chair, a dynamic lighting chair, a breakable chair, a physics chair. There is a tendency to make these all relate through some common Chair class because they all share some "chairness" in the real world. But in reality, the data and transformations each need have nothing in common and trying to shoehorn them into some relationship because it resembles something in the real world is counterproductive.

jstimpfle 10y ago

No need to get personal. > So much nonsense here. One class per object is absolutely not the stereotypical example of OO design. I didn't say that. I said: The stereotypical example is "one class per (concept / class of) real world thing(s)". Like "Rocket" or "Duck". > If that was Acton's criticism, then he should have said that instead of saying that "code should be designed around a model of the world" is a lie. It needs just a little context or reading between the lines to understand the intentions instead of twisting words to make accusations. > Now you're just confused. Acton specifically was criticizing one instance per class in the section I quoted, and now you're saying that's what he's supporting? I am not confused. He wasn't criticizing "one runtime instance per class", but "one per runtime instance per real world thing". That's something different. The quote reads rest assured that there is a "Rocket" class which contains data for exactly one rocket. I translate, he suggests to combine all "real world rockets" in a single runtime object instead of representing each rocket in its own runtime object. Concretely, he would make a "Rockets" class instead of a "Rocket" class, because that typically allows for simpler and more efficient implementation. (Of course, if there were also planes or missiles or bullets, he would think twice before making a Rockets class). As I commented elsewhere on this page, there are very close analogies to relational databases -- especially the column-store flavour.

devishard 10y ago
Okay, given your understanding of what he said, I can see why you might agree with him (although I don't), but critically, that's not what he said.
- dottrap 10y ago
  Mike has given multiple talks on Data Oriented Design. Another example he gave at CppCon was a Chair class. In a real game, you may have a static chair, a dynamic lighting chair, a breakable chair, a physics chair. There is a tendency to make these all relate through some common Chair class because they all share some "chairness" in the real world. But in reality, the data and transformations each need have nothing in common and trying to shoehorn them into some relationship because it resembles something in the real world is counterproductive.