4 ms·

I think the key differentiater is that OOP (in some versions) wants to hide the data and not just implementation details. For example, a hash map data structur

I think the key differentiater is that OOP (in some versions) wants to hide the data and not just implementation details. For example, a hash map data structure hides the details of how the hash map is implemented, but it doesn't hide the data. In some versions of OO, the object should not only hide the implementation details but also the data. Any function that needs that data MUST be a method of that object. That's where things go haywire.

jayd16 6y ago
Hash maps hide lots of internal state though. I think the difference is hash maps have a clear, battle tested API and its obvious what should be promised by the interface and what should be internal implementation. Devs aren't clairvoyant so when we're making a new type we might sometimes get this wrong. But this is a fundamental issue with type systems in general and not OOP, is it not?
- addicted44 6y ago
  Hash maps also don't (usually) have external effects. There arent many hash map methods that will actually modify the data. Standard OOP, on the other hand, seems to encourage such behavior. So, for example, a Company object could contain a bunch of Department objects, each of which contained a bunch of Employee objects. These people objects could also be referenced in areas outside of the company object. If I called a company.giveFinanceDepartmentARaiseInDollars(10000) function on the Company object, it would have an unpredictable impact on the Department/Employee objects. It may also have cascading effects in other parts of the application that may not be clear. On the other hand, if you represented this as a company hashmap, with the keys the department structs, you would have to do something like the following instead: company["finance"].employees.forEach(x => x.salary = x.salary + 10000); company["finance"].base_salary = company["finance"].base_salary 10000 This contrived example shows some of the pros/cons. OOP allows us to hide a lot of behavior/changes, which may mean less repetitive code. OTOH, it hides a lot of behavior/changes.
  - meheleventyone 6y ago
    I think the problem is that your example is too contrived and you can hide implementation details by just having a function giveFinanceDepartmentARaiseInDollars(company, dollarAmount) that exhibits the same issues as the “object oriented version”. More generally the issue of global mutable state and keeping your own sanity as a developer is a problem across paradigms.
    - addicted 6y ago
      The real problem with my example was that I modified the strict instead of returning a new one. My “functional” code wasn’t actually functional. If I had written that correctly, by returning a modified copy using a map instead of modifying the strict in a loop, your example would also be covered, because the function you’re describing would not modify any of its inputs, but instead would return a new copy. And the function wouldn’t have any side effects either, so it would once again be completely clear what’s happening.
      - meheleventyone 6y ago
        But now you have a stale data problem.
        garethjrowlands 6y ago
        Creating a new value only gives you a stale data problem if you had pointers to the old value. You don't have to have pointers like that, it's a choice. To take an obvious example, you might load a value from a database (company or employees, say), create a new value (with the higher salary, say), then write the new value to the database.
        winstonewert 6y ago
        I think the point being made here was that alternative approach don't eliminate the difficulties of global state. Simply using immutable object doesn't make all your problems go away, it makes them different. I think it makes them better, but let's not pretend that all the challenges of dealing with state can be eliminated.
- MasonOfSpoons 6y ago
  It really isn't, as OOP languages don't traditionally provide robust mechanisms around immutability. And why would they? The core design of OOP is to wrap mutable state behind methods which control that mutation. OOP was in many ways a reaction to C; shared mutable structs are harmful, so let's invent privacy. Most of the languages which are suggested to be superior alternatives to OOP in this thread have immutable data records and algebraic data types as core building blocks. These are very different than C-style structs, as they can provide stronger safety guarantees without a massive ream of boilerplate. A class or method interface promises unfortunately little around essential topics like mutability, concurrency, or termination.
  - pjmlp 6y ago
    You can already do that via modules or fake modules in C translation units. What OOP offers on top of modules is extendability and polymorphism. And these two capabilities are possible to achieve in various ways.
  - jayd16 6y ago
    >The core design of OOP is to wrap mutable state behind methods which control that mutation. That is the mechanism for immutability that is traditionally provided. It is easy to opt out of that protection. Java and C# are getting records. They're a convenience but are in no way opposed or counter to OOP.
- winstonewert 6y ago
  Sure, hash maps hide lots of internal state which isn't relevant to outside code. Where things would get silly is if you tried to make all state internal. But that's what some purist OO approaches would do for business objects.
karpierz 6y ago
In what versions of OO does a hash map hide the data? The definition of a map requires that you can access the data.
- tsimionescu 6y ago
  'the data' is a vague concept. Usually, a hash map doesn't expose, for example, the bu met array, or the length of the bucket array. Sure, you can ask the hash map to give you the contents associated with a hash key, but you can't access the entire data structure that the hash map represents. By contrast, in an 'extreme procedural' style, you would have a struct that is an array of buckets and an integer, and functions that can take such a struct and return information from some particular place inside it. In normal use you would just use the function, but if you're passing your hash map to someone else, there is no longer a guarantee that the length field still matches the actual buckets, or that objects are still arranged into buckets based on their hashes.
- winstonewert 6y ago
  A hashmap wouldn't hide the data. But say, a Customer object might. A purist OO might insist that you shouldn't have a GetName() method because any code which needs the Customer's name should be method on Customer.
  - UnFleshedOne 6y ago
    This particular example is probably a bad illustration, with all the recent rage about PII and privacy. In some cases (such as this) you want to make sure data doesn't leak all over the place and anything accessing it follows a strict path. Anybody modifying Customer object would hopefully be in the right mindset regarding personal information, but once it gets out as a string from GetName or GetEmail, all bets are off, it gets into all kind of logs. Anything security related is the same.
    - winstonewert 6y ago
      I'm having a hard time seeing how OOP style data hiding could be effective at controlling PII. Is this a method you've put into practice?

jayd16 6y ago

Hash maps hide lots of internal state though. I think the difference is hash maps have a clear, battle tested API and its obvious what should be promised by the interface and what should be internal implementation. Devs aren't clairvoyant so when we're making a new type we might sometimes get this wrong. But this is a fundamental issue with type systems in general and not OOP, is it not?

addicted44 6y ago
Hash maps also don't (usually) have external effects. There arent many hash map methods that will actually modify the data. Standard OOP, on the other hand, seems to encourage such behavior. So, for example, a Company object could contain a bunch of Department objects, each of which contained a bunch of Employee objects. These people objects could also be referenced in areas outside of the company object. If I called a company.giveFinanceDepartmentARaiseInDollars(10000) function on the Company object, it would have an unpredictable impact on the Department/Employee objects. It may also have cascading effects in other parts of the application that may not be clear. On the other hand, if you represented this as a company hashmap, with the keys the department structs, you would have to do something like the following instead: company["finance"].employees.forEach(x => x.salary = x.salary + 10000); company["finance"].base_salary = company["finance"].base_salary 10000 This contrived example shows some of the pros/cons. OOP allows us to hide a lot of behavior/changes, which may mean less repetitive code. OTOH, it hides a lot of behavior/changes.
- meheleventyone 6y ago
  I think the problem is that your example is too contrived and you can hide implementation details by just having a function giveFinanceDepartmentARaiseInDollars(company, dollarAmount) that exhibits the same issues as the “object oriented version”. More generally the issue of global mutable state and keeping your own sanity as a developer is a problem across paradigms.
  - addicted 6y ago
    The real problem with my example was that I modified the strict instead of returning a new one. My “functional” code wasn’t actually functional. If I had written that correctly, by returning a modified copy using a map instead of modifying the strict in a loop, your example would also be covered, because the function you’re describing would not modify any of its inputs, but instead would return a new copy. And the function wouldn’t have any side effects either, so it would once again be completely clear what’s happening.
    - meheleventyone 6y ago
      But now you have a stale data problem.
      - garethjrowlands 6y ago
        Creating a new value only gives you a stale data problem if you had pointers to the old value. You don't have to have pointers like that, it's a choice. To take an obvious example, you might load a value from a database (company or employees, say), create a new value (with the higher salary, say), then write the new value to the database.
        winstonewert 6y ago
        I think the point being made here was that alternative approach don't eliminate the difficulties of global state. Simply using immutable object doesn't make all your problems go away, it makes them different. I think it makes them better, but let's not pretend that all the challenges of dealing with state can be eliminated.
MasonOfSpoons 6y ago
It really isn't, as OOP languages don't traditionally provide robust mechanisms around immutability. And why would they? The core design of OOP is to wrap mutable state behind methods which control that mutation. OOP was in many ways a reaction to C; shared mutable structs are harmful, so let's invent privacy. Most of the languages which are suggested to be superior alternatives to OOP in this thread have immutable data records and algebraic data types as core building blocks. These are very different than C-style structs, as they can provide stronger safety guarantees without a massive ream of boilerplate. A class or method interface promises unfortunately little around essential topics like mutability, concurrency, or termination.
- pjmlp 6y ago
  You can already do that via modules or fake modules in C translation units. What OOP offers on top of modules is extendability and polymorphism. And these two capabilities are possible to achieve in various ways.
- jayd16 6y ago
  >The core design of OOP is to wrap mutable state behind methods which control that mutation. That is the mechanism for immutability that is traditionally provided. It is easy to opt out of that protection. Java and C# are getting records. They're a convenience but are in no way opposed or counter to OOP.
winstonewert 6y ago
Sure, hash maps hide lots of internal state which isn't relevant to outside code. Where things would get silly is if you tried to make all state internal. But that's what some purist OO approaches would do for business objects.

karpierz 6y ago

In what versions of OO does a hash map hide the data? The definition of a map requires that you can access the data.

tsimionescu 6y ago
'the data' is a vague concept. Usually, a hash map doesn't expose, for example, the bu met array, or the length of the bucket array. Sure, you can ask the hash map to give you the contents associated with a hash key, but you can't access the entire data structure that the hash map represents. By contrast, in an 'extreme procedural' style, you would have a struct that is an array of buckets and an integer, and functions that can take such a struct and return information from some particular place inside it. In normal use you would just use the function, but if you're passing your hash map to someone else, there is no longer a guarantee that the length field still matches the actual buckets, or that objects are still arranged into buckets based on their hashes.
winstonewert 6y ago
A hashmap wouldn't hide the data. But say, a Customer object might. A purist OO might insist that you shouldn't have a GetName() method because any code which needs the Customer's name should be method on Customer.
- UnFleshedOne 6y ago
  This particular example is probably a bad illustration, with all the recent rage about PII and privacy. In some cases (such as this) you want to make sure data doesn't leak all over the place and anything accessing it follows a strict path. Anybody modifying Customer object would hopefully be in the right mindset regarding personal information, but once it gets out as a string from GetName or GetEmail, all bets are off, it gets into all kind of logs. Anything security related is the same.
  - winstonewert 6y ago
    I'm having a hard time seeing how OOP style data hiding could be effective at controlling PII. Is this a method you've put into practice?