4 ms·

> "Tightly binding data and code" allows you to maintain complex invariants via code Not sure I understand what this means. Could you give an example?

fdupress 6y ago
A good example would be a complex state machine, where you rely on the fact that the state is only modified by the state machine code to make sure it remains well-formed, and the control-flow itself heavily relies on the state being well-formed (think of a TLS session, for example). But then again, what you want there is modularity, which OOP provides, but is also well-supported in other paradigms.
- Gibbon1 6y ago
  Yeah but you don't need OOP to do that. See opaque pointer's in a number of non OOP languages.
  - augustk 6y ago
    These are called Abstract Data Types.
    - garethjrowlands 6y ago
      This paper describes the differences between objects and ADTs, https://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf https://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOO...
  - billisonline 6y ago
    You don't need OOP to do anything! But in the state machine example, it provides a coherent and readily understandable metaphor (object modifies its own private state; callers can tell it what to do but not how) for the task at hand. Isn't that the goal of a programming paradigm?
AnimalMuppet 6y ago
I'm not the one you're asking. But... Here's a data structure that represents a bill of materials. It has a list of components, and a total cost, which is the sum of the costs of the components on the list. That's the invariant - that the total cost is the sum of the costs of the components in the list. If it's just a structure, then someone can add or remove a component, and forget to update the total cost, and the invariant is violated. But if it's an object, if the code is bound to the data (in the way OOP normally calls encapsulation), then only the member functions can modify the structure. So if you want to add a component, you have to use the object's addComponent method, which (in a properly debugged object) isn't going to forget to update the total cost. Now, you could say that the structure could have a code library to go with it, and that could have an addComponent function. That's true. But the user doesn't have to use that function - they can mess with the list directly, if they think they know what they're doing. Whereas with OOP encapsulation, they have to use the existing function. That function can guarantee that the object's invariants are maintained.
- ghayes 6y ago
  For what it’s worth, with ADTs and non-exposed constructors you can achieve the same result (i.e. only the creating module can actually _build_ such a list but other modules can read the data).
  - tsimionescu 6y ago
    Sure, there are usually equivalent mechanisms in all languages, because it is a good pattern. And yes, especially in OOP purism, it can also go over board, but there are absolutely use cases where tightly binding data and code is very useful (whether you do it with private members, ADTs, forward structure declaration, name mangling etc is less relevant, I think).
  - zozbot234 6y ago
    "Abstract data types and non-exposed constructors" is enough to give you object-based code, which is not too far from a definition of "the good parts" of OOP. Though some could quibble that "object-based" doesn't include sensible ideas such as composition, interface inheritance, delegation etc.

fdupress 6y ago

A good example would be a complex state machine, where you rely on the fact that the state is only modified by the state machine code to make sure it remains well-formed, and the control-flow itself heavily relies on the state being well-formed (think of a TLS session, for example). But then again, what you want there is modularity, which OOP provides, but is also well-supported in other paradigms.

Gibbon1 6y ago
Yeah but you don't need OOP to do that. See opaque pointer's in a number of non OOP languages.
- augustk 6y ago
  These are called Abstract Data Types.
  - garethjrowlands 6y ago
    This paper describes the differences between objects and ADTs, https://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf https://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOO...
- billisonline 6y ago
  You don't need OOP to do anything! But in the state machine example, it provides a coherent and readily understandable metaphor (object modifies its own private state; callers can tell it what to do but not how) for the task at hand. Isn't that the goal of a programming paradigm?

AnimalMuppet 6y ago

I'm not the one you're asking. But... Here's a data structure that represents a bill of materials. It has a list of components, and a total cost, which is the sum of the costs of the components on the list. That's the invariant - that the total cost is the sum of the costs of the components in the list. If it's just a structure, then someone can add or remove a component, and forget to update the total cost, and the invariant is violated. But if it's an object, if the code is bound to the data (in the way OOP normally calls encapsulation), then only the member functions can modify the structure. So if you want to add a component, you have to use the object's addComponent method, which (in a properly debugged object) isn't going to forget to update the total cost. Now, you could say that the structure could have a code library to go with it, and that could have an addComponent function. That's true. But the user doesn't have to use that function - they can mess with the list directly, if they think they know what they're doing. Whereas with OOP encapsulation, they have to use the existing function. That function can guarantee that the object's invariants are maintained.

ghayes 6y ago
For what it’s worth, with ADTs and non-exposed constructors you can achieve the same result (i.e. only the creating module can actually _build_ such a list but other modules can read the data).
- tsimionescu 6y ago
  Sure, there are usually equivalent mechanisms in all languages, because it is a good pattern. And yes, especially in OOP purism, it can also go over board, but there are absolutely use cases where tightly binding data and code is very useful (whether you do it with private members, ADTs, forward structure declaration, name mangling etc is less relevant, I think).
- zozbot234 6y ago
  "Abstract data types and non-exposed constructors" is enough to give you object-based code, which is not too far from a definition of "the good parts" of OOP. Though some could quibble that "object-based" doesn't include sensible ideas such as composition, interface inheritance, delegation etc.