5 ms·

> 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,

> 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?
  - unclebucknasty 10y ago
    >do you have any references? My statement rested on the original intent of the OO paradigm, which I described in the subsequent paragraph, including the bus example. And, the reason you agree that the bus is best modeled as mutable is because it represents this original intent! You can (and did) make an argument for why you like immutability. There are valid reasons to want to be assured that the data doesn't change, but that doesn't make it good OO design vs just being overlaid to achieve some other purpose. On a side note, it also introduces the question of which copy of the object/state is referenced elsewhere and what the possible inconsistency means. That again points to the tension between OO and immutability. So, never say never, but the more immutability you have, the more difficult it is to pull off a good OO design overall. If you imagine that every object is immutable, then you really won't have an OO design at all. >Integer should also be mutable? I see no inherent reason number objects must be immutable. In fact, if you've ever done math with Java's related BigDecimal class, you quickly realize how much cleaner and less error-prone it would be if that class was mutable, especially when performing a series of operations. That thing has internal state, so why am I forced to continuously assign the results of each operation to a completely new object vs simply having those operations update state?
    - geophile 10y ago
      Because numbers are, by their nature, immutable. I think an object should reflect the externally visible properties of the thing being modeled. To me, that is the whole point of OO. If I have two variables pointing to the same mutable Number, then some very non-intuitive things can happen when the value of the Number is changed through one variable. > That thing has internal state, so why am I forced to continuously assign the results of each operation to a completely new object vs simply having those operations update state? The abstract idea of an integer is immutable. Changing 3 to 4 is nonsensical. (It is not analogous to modeling a bus by a Bus object with operations reflecting the coming and going of passengers.) That's why the Java object named Integer should be immutable, and similarly for all the other Number classes, including BigDecimal. Now if there were an IntegerBuffer class, then sure, there should be methods to change state. Your argument is that there is internal state, state can be mutable, therefore every object should be mutable. My argument is that the nature of some objects is immutable, and designing a class to reflect that nature is preferable, and not at all at odds with OO.

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?
- unclebucknasty 10y ago
  >do you have any references? My statement rested on the original intent of the OO paradigm, which I described in the subsequent paragraph, including the bus example. And, the reason you agree that the bus is best modeled as mutable is because it represents this original intent! You can (and did) make an argument for why you like immutability. There are valid reasons to want to be assured that the data doesn't change, but that doesn't make it good OO design vs just being overlaid to achieve some other purpose. On a side note, it also introduces the question of which copy of the object/state is referenced elsewhere and what the possible inconsistency means. That again points to the tension between OO and immutability. So, never say never, but the more immutability you have, the more difficult it is to pull off a good OO design overall. If you imagine that every object is immutable, then you really won't have an OO design at all. >Integer should also be mutable? I see no inherent reason number objects must be immutable. In fact, if you've ever done math with Java's related BigDecimal class, you quickly realize how much cleaner and less error-prone it would be if that class was mutable, especially when performing a series of operations. That thing has internal state, so why am I forced to continuously assign the results of each operation to a completely new object vs simply having those operations update state?
  - geophile 10y ago
    Because numbers are, by their nature, immutable. I think an object should reflect the externally visible properties of the thing being modeled. To me, that is the whole point of OO. If I have two variables pointing to the same mutable Number, then some very non-intuitive things can happen when the value of the Number is changed through one variable. > That thing has internal state, so why am I forced to continuously assign the results of each operation to a completely new object vs simply having those operations update state? The abstract idea of an integer is immutable. Changing 3 to 4 is nonsensical. (It is not analogous to modeling a bus by a Bus object with operations reflecting the coming and going of passengers.) That's why the Java object named Integer should be immutable, and similarly for all the other Number classes, including BigDecimal. Now if there were an IntegerBuffer class, then sure, there should be methods to change state. Your argument is that there is internal state, state can be mutable, therefore every object should be mutable. My argument is that the nature of some objects is immutable, and designing a class to reflect that nature is preferable, and not at all at odds with OO.