OOP and immutability are almost completely orthogonal to each other. However, imperative programming and immutability are not.

OOP can be summarized by two core features:

• Encapsulation: I will not access the contents of objects directly, but rather communicate via a specific interface (“methods”) with this object. This interface can hide internal data from me. Technically, this specific to modular programming rather than OOP. Accessing data via a defined interface is roughly equivalent to an abstract data type.

• Dynamic Dispatch: When I call a method on an object, the executed method will be resolved at run time. (E.g. in class-based OOP, I might call a size method on a IList instance, but the call might be resolved to an implementation in a LinkedList class). Dynamic dispatch is one way to allow polymorphic behavior.

Encapsulation makes less sense without mutability (there is no internal state that could be corrupted by external meddling), but it still tends to make abstractions easier even when everything is immutable.

An imperative program consists of statements which are executed sequentially. A statement has side effects like changing the state of the program. With immutability, state cannot be changed (of course, a new state could be created). Therefore, imperative programming is fundamentally incompatible with immutability.

It now happens that OOP has historically always been connected with imperative programming (Simula is based on Algol), and all mainstream OOP languages have imperative roots (C++, Java, C#, … are all rooted in C). This does not imply that OOP itself would be imperative or mutable, this just means that the implementation of OOP by these languages allows mutability.

Note, there’s a culture among object oriented programmers where people assume if you’re doing OOP that most of your objects will be mutable, but that’s a separate issue from whether OOP requires mutability. Also, that culture seems to be slowly changing toward more immutability, due to people’s exposure to functional programming.

Scala is a really good illustration that mutability isn’t required for object-orientation. While Scala supports mutability, its use is discouraged. Idiomatic Scala is very much object oriented and also almost entirely immutable. It mostly allows mutability for compatibility with Java, and because in certain circumstances immutable objects are inefficient or convoluted to work with.

Compare a Scala list and a Java list, for example. Scala’s immutable list contains all the same object methods as Java’s mutable list. More, in fact, because Java uses static functions for operations like sort, and Scala adds functional-style methods like map. All the hallmarks of OOP—encapsulation, inheritance, and polymorphism—are available in a form familiar to object-oriented programmers and used appropriately.

The only difference you’ll see is when you change the list you get a new object as a result. That often requires you to use different design patterns than you would with mutable objects, but it doesn’t require you to abandon OOP altogether.

Immutability can be simulated in an OOP language, by only exposing object access points as methods or read-only properties that do not mutate the data. Immutability works the same in OOP languages as it does in any functional language, except that you may be missing some functional language features.

Your presumption seems to be that mutability is a core feature of object-orientation. But mutability is simply a property of objects or values. Object-orientation encompasses a number of intrinsic concepts (encapsulation, polymorphism, inheritance, etc.) that have little or nothing to do with mutation, and you would still derive the benefits of those features, even if you made everything immutable.

Not all functional languages require immutability, either. Clojure has a specific annotation that allows types to be mutable, and most of the “practical” functional languages have a way to specify mutable types.

A better question to ask might be “Does complete immutability make sense in imperative programming?” I’d say the obvious answer to that question is no. To achieve complete immutability in imperative programming, you would have to forego things like for loops (since you would have to mutate a loop variable) in favor of recursion, and now you’re essentially programming in a functional manner anyway.

It’s often useful to categorize objects as encapsulating values or entities, with the distinction being that if something is a value, code which holds a reference to it should never see its state change in any fashion which the code itself did not initiate. By contrast, code which holds a reference to an entity may expect it to change in ways beyond the reference-holder’s control.

While it’s possible to use encapsulate value using objects of mutable or immutable types, an object can only behave as a value if at least one of the following conditions applies:

1. No reference to the object will ever be exposed to anything that might change the state encapsulated therein.

2. The holder of at least one of the references to the object knows all the uses to which any extant reference might get put.

Since all instances of immutable types automatically satisfy the first requirement, using them as values is easy. Ensuring that either requirement is met when using mutable types is, by contrast, much more difficult. Whereas references to immutable types can be freely passed around as a means of encapsulating the state encapsulated therein, passing around state stored in mutable types requires either constructing immutable wrapper objects, or else copying the state encapsulated by privately-held objects into other objects which are either supplied by or constructed for the recipient of the data.

Immutable types work very well for passing values, and are often at least somewhat usable for manipulating them. They are not so good, however, at handling entities. The closest thing one can have to an entity in a system with purely-immutable types is a function which, given the state of the system, will report that attributes of some part thereof, or produce a new system-state instance which is like a supplied one except for some particular part thereof which will be different in some selectable fashion. Further, if the purpose of an entity is to interface some code to something that exists in the real world, it may be impossible for the entity to avoid exposing mutable state.

For example, if one receives some data over a TCP connection, one could produce a new “state of the world” object which includes that data in its buffer without affecting any references to the old “state of the world”, but old copies of the world state which doesn’t include the last batch of data will be defective and shouldn’t be used since they will no longer match the state of the real-world TCP socket.

In c# some types are immutable like string.

This seems to furthermore suggest that the choice has been strongly considered.

For sure it’s really performance demanding to use immutable types if you have to modify that type hundred of thousand of times. That’s the reason why it’s suggested to use the StringBuilder class instead of the string class in this cases.

I’ve made an experiment with a profiler and using the immutable type is really more CPU and RAM demanding.

It’s also intuitive if you consider that for modifying just one letter in a string of 4000 characters you have to copy every char in another area of the RAM.

Complete immutability of everything doesn’t make much sense in OOP, or most other paradigms for that matter, for one very big reason:

Every useful program has side effects.

A program that does not cause anything to change, is worthless. You may as well not have even run it, as the effect will be identical.

Even if you think you’re not changing anything, and are simply summing up a list of numbers you somehow received, consider that you need to do something with the result — whether you print it to standard output, write it to a file, or wherever. And that involves mutating a buffer and changing the state of the system.

It can make a lot of sense to restrict mutability to the parts that need to be able to change. But if absolutely nothing needs to change, then you’re not doing anything worth doing.

I think it depends on whether your definition of OOP is that it uses a message-passing style.

Pure functions don’t have to mutate anything because they return values which you can store in new variables.

var brandNewVariable = pureFunction(foo);

With message passing style, you tell an object to store new data instead of asking it what new data you should store in a new variable.

sameOldObject.changeMe(foo);

It’s possible to have objects and not mutate them, by making its methods pure functions that happen to live on the inside of the object instead of outside.

var brandNewVariable = nonMutatingObject.askMe(foo);

But it’s not possible to mix message passing style and immutable objects.