What are side effects?

Question

I was reading that reply and it has a table where it says that functional programming has no side effects and that OOP has, it generated me two doubts, being them:

• What are these side effects?

• Can you avoid them in OOP?

Table:

Answer 1

The side effect is the phenomenon that interferes in a situation beyond the expected, that happens something as a consequence of the main event. That’s what computing is about, too, and we use it to say that a code affects something that’s beyond it. This occurs when something is not self-contained, which lacks encapsulation (in the broad sense of the word, not in what is normally misused in OOP). In many cases we speak of them as contractive of "hidden side effect" and usually it has a negative connotation, since it is something that affects the external environment without its intention.

In this context shown in the question it is clear that it means this, but with a greater specificity. Ali indicates that in functional a code does not alter external state to it. So he can have local states and even change them without problem, he can get external states, but he can’t change these received states.

If you change an external state to a function you are generating the side effect. And no matter how that sternal state comes, it can be by normal parameter, it can be by implicit parameter (usually the this), or it may be because this state is visible globally, including data that comes from outside the application. OOP virtually forces you to do this.

But receiving an external data without changing it is something normal and does not cause side effect. Changing a local copy of a data is quiet and "pure". Of course, there is always a local difficulty when changing this state, but this is not considered side effect because it is self-contained.

State change is one of the things that most create problems in computing, the ideal is to avoid it as much as possible, or at least limit it to a very specific scope. Functions that do not change external state are simpler to write, understand and debug, but of course this is not always possible, and as everything is trade-off, try to escape the side effect exaggeratedly arrives complicate even more in many cases, so languages that try to be pure (where gives) are very complicated for most people. On the other hand it strengthens the idea of changing external state, one of the reasons that the paradigm is most criticized. What could often be only external communication without change of state becomes side effect always.

Just remembering that zero side effect is impossible in any nontrivial code. And the functional programming of almost every language avoids this purity at any cost, only encourages it to be so.

It is possible to avoid them in object orientation, but in fact it ceases to be OO at least at that point :) Of course, it has methods that do not alter the state of the object that it belongs to or external object, so this method has no side effect, but it is not normal in OOP and in general this occurs only by coincidence.

Answer 2

The side effect on object orientation

In object orientation, side effects are an unwanted effect that occurs on objects when their state is modified. It can occur in different situations, usually the cause is a confusing maintenance of the object state, where the call of one method ends up influencing the behavior of another.