3 ms·

> The best thing I can say about OOP is that it allows for private state that only certain logic is allowed to know about. Local variables in methods are priva

by mrkeen 6y ago

> The best thing I can say about OOP is that it allows for private state that only certain logic is allowed to know about. Local variables in methods are private and encapsulated. Languages had this before and after OO. Plus modules/namespaces/headers/etc. OO languages added classes with fields, which are variables shared among methods (whether they are declared with the private keyword or not.) The opposite of private/encapsulated. If the 'private' keyword made a class's state sufficiently private I wouldn't need to worry about the difference between StringBuilder and StringBuffer, and I could pass java.util.Date without fear.

brundolf 6y ago
> OO languages added classes with fields, which are variables shared among methods That's not true. Structs and other mutable, structured data objects existed long before OOP. The differentiating factor was that no functions/methods were able to have varying levels of access to those fields; everything was public all the time. > The opposite of private/encapsulated. I don't think that's fair. OOP added "private variables that survive past the end of a function", if you want to get pedantic, but I think there's plenty of added value to having this functionality in your toolbox. And yes, technically closures can accomplish the same thing, but most mainstream languages did not have them yet when OOP was on the rise and even then, using them to achieve "lasting, private, mutable state" is, IMO, one of the few cases where the OOP way of doing things is actually more ergonomic and expressive of intent than the functional way. OOP is fundamentally about state, so when you really have to manage some state, it is often the right way to do things. The problem comes when you assume preemptively that you need state in the first place.
- mrkeen 6y ago
  I'm saying you can have private mutable state if you stick to method variables. If you take a method variable and promote it to a field (private or not), or return it via a public method, you have made it more public - that's what I meant by "The opposite of private/encapsulated".

by mrkeen 6y ago

brundolf 6y ago

> OO languages added classes with fields, which are variables shared among methods That's not true. Structs and other mutable, structured data objects existed long before OOP. The differentiating factor was that no functions/methods were able to have varying levels of access to those fields; everything was public all the time. > The opposite of private/encapsulated. I don't think that's fair. OOP added "private variables that survive past the end of a function", if you want to get pedantic, but I think there's plenty of added value to having this functionality in your toolbox. And yes, technically closures can accomplish the same thing, but most mainstream languages did not have them yet when OOP was on the rise and even then, using them to achieve "lasting, private, mutable state" is, IMO, one of the few cases where the OOP way of doing things is actually more ergonomic and expressive of intent than the functional way. OOP is fundamentally about state, so when you really have to manage some state, it is often the right way to do things. The problem comes when you assume preemptively that you need state in the first place.

mrkeen 6y ago
I'm saying you can have private mutable state if you stick to method variables. If you take a method variable and promote it to a field (private or not), or return it via a public method, you have made it more public - that's what I meant by "The opposite of private/encapsulated".