| Again we disagree :) "if you're doing OOP your code will have methods and "setters" that mutate or set internal state" I don't think there is nothing in OOP that "forces" you to explicitly mutate state. People just happen to do it that way, even if there was no need for that. I.e. instead of mutating an instance of class Foo void Foo.set(Some bar) There are several patterns that make instance of Foo immutable. As an example: 1. Use just 'Factory' pattern to build state and disregard mutation altogether
FooFactory fact; fact.AddBar(Bar bar); Foo foo = fact.build(); This may appear as mutating (the factory) but the point is the mutations are located at the factory, which is expceted to have a limited scope, and the entity with larger scope (Foo) is immutable wihtout setters. 2. If there is need to modify existing state, instead of mutating the instance, return a new instance with the value modified. So instead of void foo.Set(Bar bar) Use method that creates a copy of foo, modifies state, and then returns a new instance of Foo Foo foo.Modify(Bar bar) Just removing mutability actually goes long way in making programs more legible akin to functional programs. I agree functional style is often the best. Unfortunately we just don't have a functional language that could replace C++. |
I never said it forces you to do this. Please read my post carefully.
Let me repeat what I wrote. I'm saying that FP and OOP have blurry definitions that people have an intuition about but have not formally defined. Immutable OOP is can be called FP and vice versa. What is the point of having two names for the same style of programming? There is no point that's why you need to focus in on the actual differences. What can you do in OOP that absolutely makes it pure OOP that you cannot call it FP?
That differentiator is setters and mutators. If you use setters and mutators you are doing OOP exclusively and you are NOT doing FP. My response to your post is mostly talking about this semantic issue and why you need to include mutation in your definition of OOP. Otherwise if you don't than I can say all your descriptions of patterns to me are basically FP. You're following the principles of FP and disguising it as OOP and confusion goes in circles.
Please reread my post, I am aware of OOP and it's patterns so there's no need to explain the Factory pattern to me. I'm also in agreement with you like I said.
I am talking about something different: semantics and proper definitions, you likely just glossed over what I wrote, that's why your response is so off topic.