Developers who hate on OOP don’t know how to use it.
I perceive objects as configurable tools for processing data throughput - ie processors that can be configured by the constructor and are further immutable. No obstruction, no getters or setters, no data. Data pass through the object only. I know it's very similar to functional programming.
You must break your real world problem down to some totally artificial, unintuitive "objects" communicating with each other first before you can apply this method. And the funny part is that most of the real world problems do not really fit well into such a representation. Not that FP allows any better tools, of course, both ways are almost always wrong.
That sounds like a very reasonable way of using OOP. However, there is a noticeable difference when you use a functional language.
In OOP languages, whether or not an object is immutable is really up to the discipline of the programmer, and neither the language, the type system, nor the compiler will help you maintain that discipline. Anytime you write code that interacts with a data structure, you must mentally evaluate whether the data was really left alone or not. And that adds mental overhead. You might even end up looking at the internals of the object/class to assure yourself that it's safe.
In contrast, with a functional language, where immutability is the default, you can rest assured that all the data is immutable. You'll never have to check the internals. The compiler will let you know. This alone eliminates 80% of the mental load of working with any particular part of your code. You no longer have to consider the entire application context while solving local problems. You really can't get that without the guarantees provided by a functional language design.
On the flip side, this does force you to solve problems differently, though. If you're used to mutation and side effects as the primary way you solve problems, then switching to a functional paradigm will require you to dramatically rethink seemingly simple algorithms. FP has an answer for all the problems OOP can solve, but the methodology is usually different enough to put people off from switching.
My data are also immutable in my applications, I pass parameters of methods only by value. Mutable are collections only. It really requires discipline, but the result is pure SOLID-compliant code.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Developers who hate on OOP don’t know how to use it.
I perceive objects as configurable tools for processing data throughput - ie processors that can be configured by the constructor and are further immutable. No obstruction, no getters or setters, no data. Data pass through the object only. I know it's very similar to functional programming.
You must break your real world problem down to some totally artificial, unintuitive "objects" communicating with each other first before you can apply this method. And the funny part is that most of the real world problems do not really fit well into such a representation. Not that FP allows any better tools, of course, both ways are almost always wrong.
That sounds like a very reasonable way of using OOP. However, there is a noticeable difference when you use a functional language.
In OOP languages, whether or not an object is immutable is really up to the discipline of the programmer, and neither the language, the type system, nor the compiler will help you maintain that discipline. Anytime you write code that interacts with a data structure, you must mentally evaluate whether the data was really left alone or not. And that adds mental overhead. You might even end up looking at the internals of the object/class to assure yourself that it's safe.
In contrast, with a functional language, where immutability is the default, you can rest assured that all the data is immutable. You'll never have to check the internals. The compiler will let you know. This alone eliminates 80% of the mental load of working with any particular part of your code. You no longer have to consider the entire application context while solving local problems. You really can't get that without the guarantees provided by a functional language design.
On the flip side, this does force you to solve problems differently, though. If you're used to mutation and side effects as the primary way you solve problems, then switching to a functional paradigm will require you to dramatically rethink seemingly simple algorithms. FP has an answer for all the problems OOP can solve, but the methodology is usually different enough to put people off from switching.
My data are also immutable in my applications, I pass parameters of methods only by value. Mutable are collections only. It really requires discipline, but the result is pure SOLID-compliant code.