5 ms·

> I see OO as a good way of abstracting the data away from the logic of your program. Why would you want to do this?

jbooth 13y ago
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." -- Linus If your data structures don't exist outside of your functional code acting on them, it's hard to reason about the data structures themselves in a vacuum.
- weavejester 13y ago
  Isn't this an argument against hiding your data structures behind an opaque object structure?
  - jbooth 13y ago
    To my mind, it's an argument for explicit definition of data structures (from me, not Linus). It seems to me that structs and/or objects do that pretty well. I'm not sure what you're talking about with 'opaque object structure'. class MyClass { member1, member2 } seems pretty transparent to me. Anyways, I was just explaining why many people prefer to have struct/object definitions separated from the code that operates on them. YMMV, you don't have to agree.
    - weavejester 13y ago
      If you're just treating a object as a map of keys to values, then it can be fairly transparent, but unless you're using a language like Javascript, where maps and objects are synonymous, objects are much more difficult to work with. It's hard to transverse them, or to merge them, or often even to look up a list of keys. I'd suggest that a better solution would be to just use maps, at least in languages with good support for raw data structures.
      - jbooth 13y ago
        "It's hard to transverse them, or to merge them, or often even to look up a list of keys." That's exactly what I'm arguing against in my comment on making your important structs/objects and their relationships explicit. Randomly mutating them together all over your program might seem more flexible but at a cost of making you worry about your code rather than your data definitions. And that's without even getting into performance implications. If you actually need a Map, of course, that's a different situation than the ones I'm thinking.
        weavejester 13y ago
        Using a map doesn't necessarily mean random mutation, or giving up on your type system. In languages with immutable data structures and a sophisticated type system, you can type-check the keys and values in a map.
strictfp 13y ago
Late answer, but nevertheless... I don't particularly think that it's a good idea, but I believe that the original intention was to build "living" data. So you would look at your object structure and could treat it as data, but internally some objects could be proxies to backend system and fetch data on-demand. Some data fields might also be calculated from other fields. This is the idea which Java promotes by having the JavaBean standard. You never know if your data element is backed by actual data or is the result of a computation. This type of abstraction can simplify certain problems by giving the illusion of a simple data structure, whereas a lot of computations are taking place behind the scene when the data is traversed. This abstraction is used in may ORM frameworks for instance. You can follow relations between entities and these will be lazily loaded behind the scene as you move around in the object graph. The problem is that such a living object can only live in its own environment. For ORMs, you cannot move outside the current DB transaction, or else the objects "die". To see some of these problems in the Java world, google "LazyInitializationException". Pure data, on the other hand, is "dead by definition" so to speak. It does not contain any own logic and can be moved between environments without any problem. The backside of pure data is the very fact that it is dead, that is that you often have to accompany it with logic to interpret it. With live objects, the interpreting logic is intertwined with the data. This is both the advantage and flaw of OO. With OO, you have data and logic close together, and have to pay the price if you try to pry them apart. With FP, you have the data separately, and have to cope with the mental load of knowing which logic you need to apply where in your data structures in order to interpret them.

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." -- Linus If your data structures don't exist outside of your functional code acting on them, it's hard to reason about the data structures themselves in a vacuum.

weavejester 13y ago
Isn't this an argument against hiding your data structures behind an opaque object structure?
- jbooth 13y ago
  To my mind, it's an argument for explicit definition of data structures (from me, not Linus). It seems to me that structs and/or objects do that pretty well. I'm not sure what you're talking about with 'opaque object structure'. class MyClass { member1, member2 } seems pretty transparent to me. Anyways, I was just explaining why many people prefer to have struct/object definitions separated from the code that operates on them. YMMV, you don't have to agree.
  - weavejester 13y ago
    If you're just treating a object as a map of keys to values, then it can be fairly transparent, but unless you're using a language like Javascript, where maps and objects are synonymous, objects are much more difficult to work with. It's hard to transverse them, or to merge them, or often even to look up a list of keys. I'd suggest that a better solution would be to just use maps, at least in languages with good support for raw data structures.
    - jbooth 13y ago
      "It's hard to transverse them, or to merge them, or often even to look up a list of keys." That's exactly what I'm arguing against in my comment on making your important structs/objects and their relationships explicit. Randomly mutating them together all over your program might seem more flexible but at a cost of making you worry about your code rather than your data definitions. And that's without even getting into performance implications. If you actually need a Map, of course, that's a different situation than the ones I'm thinking.
      - weavejester 13y ago
        Using a map doesn't necessarily mean random mutation, or giving up on your type system. In languages with immutable data structures and a sophisticated type system, you can type-check the keys and values in a map.

strictfp 13y ago

Late answer, but nevertheless... I don't particularly think that it's a good idea, but I believe that the original intention was to build "living" data. So you would look at your object structure and could treat it as data, but internally some objects could be proxies to backend system and fetch data on-demand. Some data fields might also be calculated from other fields. This is the idea which Java promotes by having the JavaBean standard. You never know if your data element is backed by actual data or is the result of a computation. This type of abstraction can simplify certain problems by giving the illusion of a simple data structure, whereas a lot of computations are taking place behind the scene when the data is traversed. This abstraction is used in may ORM frameworks for instance. You can follow relations between entities and these will be lazily loaded behind the scene as you move around in the object graph. The problem is that such a living object can only live in its own environment. For ORMs, you cannot move outside the current DB transaction, or else the objects "die". To see some of these problems in the Java world, google "LazyInitializationException". Pure data, on the other hand, is "dead by definition" so to speak. It does not contain any own logic and can be moved between environments without any problem. The backside of pure data is the very fact that it is dead, that is that you often have to accompany it with logic to interpret it. With live objects, the interpreting logic is intertwined with the data. This is both the advantage and flaw of OO. With OO, you have data and logic close together, and have to pay the price if you try to pry them apart. With FP, you have the data separately, and have to cope with the mental load of knowing which logic you need to apply where in your data structures in order to interpret them.