5 ms·

I totally disagree that #2 is a lie. Code should be designed around a model of some part of the world, it's just that what the author is describing is a pretty

I totally disagree that #2 is a lie. Code should be designed around a model of some part of the world, it's just that what the author is describing is a pretty bad way of modeling the world. Take this part: "If there's a rocket in the game, rest assured that there is a "Rocket" class (Assuming the code is C++) which contains data for exactly one rocket and does rockety stuff. With no regard at all for what data tranformation is really being done, or for the layout of the data. Or for that matter, without the basic understanding that where there's one thing, there's probably more than one." This is an enormous straw man. You don't need to be using C++, or even a real OO language, to design your code around a model of the world. I'd go so far as to say that C++ is a pretty poor choice of language for modeling the real world. And even in an OO language, no decent practitioner writes one-class-per-object. That's not how objects are intended to work, and even pretty bad practitioners of OO don't usually screw it up that badly. And the underlying thing here is that if you model interactions in the real world accurately, at least the parts that are relevant to what you're trying to do, the data transformations and layout tend to fall into place naturally. Of course there are exceptions; we don't have leak-free abstractions yet.

jstimpfle 10y ago
> 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. These have definitely been problems in my own software design attempts and in many of the projects I've seen. 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. 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. Can't see a straw man there.
- devishard 10y ago
  >> > 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.
deleted 10y ago
[deleted]
Ace17 10y ago
What we call the "real world" already is a model ... and a simplistic one. 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. My argument isn't related to performance. I don't have a problem with having a "Rocket" class ; however, if this class is responsible for everything "Rockety" (audio rendering, video rendering, serialization, target following, collision detection, ...), then it's gathering lots of dependencies at one single point, making the class painfull to reuse, and more generally painfull to depend upon. I've seen this, and it's a design nightmare. Were you going to reuse this "Rocket" class in another application anyway? Does the rest of your application sees rockets as instances of "Rocket" classes?
- devishard 10y ago
  > 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.

jstimpfle 10y ago

> 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. These have definitely been problems in my own software design attempts and in many of the projects I've seen. 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. 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. Can't see a straw man there.

devishard 10y ago
>> > 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.

deleted 10y ago

[deleted]

Ace17 10y ago

What we call the "real world" already is a model ... and a simplistic one. 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. My argument isn't related to performance. I don't have a problem with having a "Rocket" class ; however, if this class is responsible for everything "Rockety" (audio rendering, video rendering, serialization, target following, collision detection, ...), then it's gathering lots of dependencies at one single point, making the class painfull to reuse, and more generally painfull to depend upon. I've seen this, and it's a design nightmare. Were you going to reuse this "Rocket" class in another application anyway? Does the rest of your application sees rockets as instances of "Rocket" classes?

devishard 10y ago
> 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.