5 ms·

Part of the problem with OO is the other stuff we heaped on it, while still calling it OO. So, we're not always assessing "pure" OO when we talk about it. For i

Part of the problem with OO is the other stuff we heaped on it, while still calling it OO. So, we're not always assessing "pure" OO when we talk about it. For instance, immutability and OO are diametrically opposed concepts. Objects were supposed to encapsulate data (state) and expose operations that would mutate that state in a controlled fashion. But, we then imposed this immutability requirement, whereby we create these objects very explicitly with long-winded builder patterns, then make copies of the data when necessary,etc. At this point, we have effectively externalized the logic around the object's state and the object itself is nothing more than a C-style struct. Sure, immutability has its advantages, but we should acknowledge that it's not a OO-friendly concept.

jghn 10y ago
Inheritance is arguably one of those things. It certainly goes against Kay's original scheme, which was more like actors. To me OOP winds up looking a lot better without the inheritance
- unclebucknasty 10y ago
  Yeah, there are probably degrees of purity. With inheritance, I can at least see how it tries to respect the OO paradigm, by giving you ways to extend without breaking some of the core concepts like encapsulation. While, on the other end, immutability fundamentally undermines the very premise of OO, which is to model the domain as state and behavior vs treating objects as data wrappers to be manipulated externally.
  - jghn 10y ago
    Fair point. In a true, classic Kay OO model the object is providing a well known interface to guard the mutation of the state. While I am definitely in the "prefer immutability" camp in the FP sense I'd argue that this push in the OO world is to cover up people's bad habits.
deleted 10y ago
[deleted]
hasbot 10y ago
Your comment reminds me of the class responsibility discussions we used to have. Should we have gasStation->fillUp(vehicle) or vehicle->fillUp(gasStation)? There is no right answer and depends on the situation.
- unclebucknasty 10y ago
  Definitely remember those discussions. Enter the rise of the manager class!
- jimmaswell 10y ago
  What seems most natural to me is that the gas station would have a fillUp(IFillableWithGas) method that takes an object with the IFillableWithGas interface, which has a method that returns the amount it was able to take and a method to put that much in. The gas station is the one "doing" the action "to" things that are able to take gas, and it's the gas station's responsibility to know how to pump up the gas from the tank and calculate the price. gasStation->fillUp could look like (leaving it at a gas station with only one pump for simplicity) float price = 0; while (!vehicle.gasIsFull()){ Gas gas = this.undergroundGasTank.getGas(); vehicle.depositGas(gas); price += gas.getAmount() * this.gasPricePerGallon; this.display(price); } It would be out of place for a car or gas canister class to know how to use the undergroundGasTank object and to calculate the price themselves.
  - hasbot 10y ago
    LOL. Who said anything about an underground gas tank, pricing, or a display? If you're adding pricing, you have to add a payment system. It'd be out of place for a Vehicle to know anything about paying a bill. Objects just model reality; they don't have to mirror reality.
    - jimmaswell 10y ago
      It's just a demonstration of how the hierarchy works in the abstract. And it's just displaying the price on the meter, not saying the "car" has to deal with that. The driver would, or the player, if you look at this like game code, which would make sense.
geophile 10y ago
> immutability and OO are diametrically opposed concepts. Why do you say that? It is completely reasonable to define objects whose state is fixed at creation, hide a representation, and have methods that implement some abstraction. E.g., strings, complex numbers, points in a space, and possibly even more complex things like sets. All the advantages of OO apply, even for objects whose interface does not provide a way to mutate the object.
- unclebucknasty 10y ago
  It may be reasonable, but it's not OO. There are those who believe that all objects should be immutable, particularly at the domain level. In my view, that defeats the purpose of OO. There really is no state in this case in any meaningful sense because to get a new state, you must create a new object. So, the object is simply a collection of data. And, even in limited use it's not strictly OO, which is a separate question from whether it can be useful. The entire purpose of OO was to model the real world. In the real world, you have a bus with passengers. When one passenger gets off, you have the same bus with one fewer passengers, not a completely new bus with all but one passenger The turn signal goes on and off vs. having a new bus with a different turn signal state. So, at the domain level, it completely breaks the OO concept. And, even at the utility level with language constructs like Strings, immutability tends to oppose OO in the strictest sense. In fact, in many languages (like Java) the String is immutable for technical reasons (security, etc.), not because it's particularly good OO design. To wit, you now need a completely parallel "real" class (StringBuilder) to do the real "object work" of the String (append, delete, etc.) without creating object copies everywhere. Where OO is concerned, immutability is generally an encumberance.
  - geophile 10y ago
    > It may be reasonable, but it's not OO. Says who? I.e., do you have any references? It is easy to give examples arguing either side. I agree that your bus example is best modeled as a mutable object. The same bus can have different passengers over time. But a complex number is an example that I think is better thought of as immutable. You really lost me with your discussion of Strings. Why does "immutability tend to oppose OO in the strictest sense"? I like the distinction between String and StringBuilder, because I want to be able to share a String without worrying about the possibility of an update through some other reference. (This is not an argument about whether String/StringBuilder is OO or not, just a comment on the design of the classes.) Just because it is possible to define mutable objects, it does not follow that all objects should be mutable. By your logic, Integer should also be mutable?

jghn 10y ago

Inheritance is arguably one of those things. It certainly goes against Kay's original scheme, which was more like actors. To me OOP winds up looking a lot better without the inheritance

unclebucknasty 10y ago
Yeah, there are probably degrees of purity. With inheritance, I can at least see how it tries to respect the OO paradigm, by giving you ways to extend without breaking some of the core concepts like encapsulation. While, on the other end, immutability fundamentally undermines the very premise of OO, which is to model the domain as state and behavior vs treating objects as data wrappers to be manipulated externally.
- jghn 10y ago
  Fair point. In a true, classic Kay OO model the object is providing a well known interface to guard the mutation of the state. While I am definitely in the "prefer immutability" camp in the FP sense I'd argue that this push in the OO world is to cover up people's bad habits.

deleted 10y ago

[deleted]

hasbot 10y ago

Your comment reminds me of the class responsibility discussions we used to have. Should we have gasStation->fillUp(vehicle) or vehicle->fillUp(gasStation)? There is no right answer and depends on the situation.

unclebucknasty 10y ago
Definitely remember those discussions. Enter the rise of the manager class!
jimmaswell 10y ago
What seems most natural to me is that the gas station would have a fillUp(IFillableWithGas) method that takes an object with the IFillableWithGas interface, which has a method that returns the amount it was able to take and a method to put that much in. The gas station is the one "doing" the action "to" things that are able to take gas, and it's the gas station's responsibility to know how to pump up the gas from the tank and calculate the price. gasStation->fillUp could look like (leaving it at a gas station with only one pump for simplicity) float price = 0; while (!vehicle.gasIsFull()){ Gas gas = this.undergroundGasTank.getGas(); vehicle.depositGas(gas); price += gas.getAmount() * this.gasPricePerGallon; this.display(price); } It would be out of place for a car or gas canister class to know how to use the undergroundGasTank object and to calculate the price themselves.
- hasbot 10y ago
  LOL. Who said anything about an underground gas tank, pricing, or a display? If you're adding pricing, you have to add a payment system. It'd be out of place for a Vehicle to know anything about paying a bill. Objects just model reality; they don't have to mirror reality.
  - jimmaswell 10y ago
    It's just a demonstration of how the hierarchy works in the abstract. And it's just displaying the price on the meter, not saying the "car" has to deal with that. The driver would, or the player, if you look at this like game code, which would make sense.

geophile 10y ago

> immutability and OO are diametrically opposed concepts. Why do you say that? It is completely reasonable to define objects whose state is fixed at creation, hide a representation, and have methods that implement some abstraction. E.g., strings, complex numbers, points in a space, and possibly even more complex things like sets. All the advantages of OO apply, even for objects whose interface does not provide a way to mutate the object.

unclebucknasty 10y ago
It may be reasonable, but it's not OO. There are those who believe that all objects should be immutable, particularly at the domain level. In my view, that defeats the purpose of OO. There really is no state in this case in any meaningful sense because to get a new state, you must create a new object. So, the object is simply a collection of data. And, even in limited use it's not strictly OO, which is a separate question from whether it can be useful. The entire purpose of OO was to model the real world. In the real world, you have a bus with passengers. When one passenger gets off, you have the same bus with one fewer passengers, not a completely new bus with all but one passenger The turn signal goes on and off vs. having a new bus with a different turn signal state. So, at the domain level, it completely breaks the OO concept. And, even at the utility level with language constructs like Strings, immutability tends to oppose OO in the strictest sense. In fact, in many languages (like Java) the String is immutable for technical reasons (security, etc.), not because it's particularly good OO design. To wit, you now need a completely parallel "real" class (StringBuilder) to do the real "object work" of the String (append, delete, etc.) without creating object copies everywhere. Where OO is concerned, immutability is generally an encumberance.
- geophile 10y ago
  > It may be reasonable, but it's not OO. Says who? I.e., do you have any references? It is easy to give examples arguing either side. I agree that your bus example is best modeled as a mutable object. The same bus can have different passengers over time. But a complex number is an example that I think is better thought of as immutable. You really lost me with your discussion of Strings. Why does "immutability tend to oppose OO in the strictest sense"? I like the distinction between String and StringBuilder, because I want to be able to share a String without worrying about the possibility of an update through some other reference. (This is not an argument about whether String/StringBuilder is OO or not, just a comment on the design of the classes.) Just because it is possible to define mutable objects, it does not follow that all objects should be mutable. By your logic, Integer should also be mutable?