39 ms·
The same applies to C# though, correct? Plus, I was thinking more of the lines of something like: class Foo { private int x = 0; public void b
by azth 12y ago
The same applies to C# though, correct? Plus, I was thinking more of the lines of something like:
class Foo {
private int x = 0;
public void bar() {
this.x += 1; // Whoops!
}
}
Foo x = new Foo();
x.bar(); // Mutating call.
Which Java does not prevent.
- noblethrasher 12y agoYes, the same applies to my beloved C#, but that language was much less hostile to immutability. Indeed, the prettier mutator syntax was even positioned as a feature once upon a time. To be clear, I'm the guy that insists on defining classes as either abstract or sealed, and almost always marks fields as readonly. But, I'm okay with the kind bounded mutability that you mentioned; clients of a `Foo` instance have to treat it as immutable. Here is how I do OOP: * I make classes to hide state, and hidden state is the same as being stateless. * As I learn more about the problem, I start subdividing classes into smaller classes (not necessarily via inheritance). * So, as my understanding of the problem increases, the number of class division increases, and by the pigeonhole principle, the amount of state approaches zero.