Side Effect Methods. Good, Bad and Ugly

Java methods are blocks of code that can be invoked to execute particular action/logic at a high level. A method can take parameters to be used for the logic in the method. Different invocations can pass different arguments to the method leading to different outcomes.

Assumption : Reader is aware of “passing mechanism in java”

A side effect method is a method which modifies some state variable value/arguments passed having a consequence beyond its scope, that is to say it has an observable effect besides returning a value (the main effect) to the invoker of the operation. In simpler terms, a method can take arguments and run some logic and return a value or not return anything.

Now if it does not return a value then it must be a side effect method, if not what would be the purpose of the method itself ? What are the possible side effects —

• Logging to the console/file
• Writing to the screen
• Writing to a file/network
• Triggering any external process — db calls
• Invoking any other functions with side-effects

All of these seems easily justifiable, but there is a major side effect to watch out for which the justification is not always available except lack of good understanding of OO design.

• Changing the state of the arguments passed to the method

So, Is modifying an incoming argument an anti pattern?

It’s not an antipattern, it’s a bad practice, vestigial or pre-OOP times, according to Robert C. Martin (aka Uncle Bob) ’s Clean Code —

Arguments are most naturally interpreted as inputs to a function.

Anything that forces you to check the function signature is equivalent to a double-take. It’s a cognitive break and should be avoided. In the days before object oriented programming it was sometimes necessary to have output arguments. However, much of the need for output arguments disappears in OO languages

#Good : Not changing the state of the parameters passed, returning a value from the method.

Possible reasons?

• Parameters being primitive data types which are passed by value. ie the value of the primitive data types are copied over to the method. So changing the values inside the method has no consequence outside the method. — Not to worry about side effect at all !
• Method was designed and coded not to modify the reference arguments (non primitive data types) passed, it would return a value at the end of processing. This is the #Good. Parameters passed to the method are treated as effectively final and a single value (primitive or non-primitive) returned from the method. These kind of methods uphold true _non_ side effect method principals and make maintenance and code reading an ease.

Cases where this might not be possible ? leading to the #Bad

#Bad : Changing the state of the parameters passed, however method does _not_ return a value.

Possible reasons?

• A large collection might be passed to the method and duplicating the collection, through another reference parameter, might be expensive on platforms where memory is critical.
• Constrains to not create large return object returning most parts of the passed reference parameter with fewer updates on the parameter itself.
• Game programming where too many parameters might need to be updated by the method

Here at least the method does not return a value, so with a proper comment/java doc the rationale to update the parameter passed can be justified on the method. However this comes at a cost of less maintainable and less readable code and at times is a an indication of poor OO design of the application. However in cases where it is completely unavoidable a justification can be made for this pattern. Avoid the #Bad until it is inevitable.

Lastly the dreaded and hated #Ugly

#The Ugly: Changing the state of the parameters passed and also returning a value from the method.

Cause for all the confusion!

Possible reasons?

• Cant think of any real good reason where a method manipulates the parameters and also at the same time returns a value, except poor design and poor understanding of OO principals.

This is truly the #Ugly which should be avoided at any cost. This pattern will make it highly impossible to understand what is the purpose of the API and maintaining it will be a nightmare for which a cost will be paid and most of the time reflects very poor understanding of OO paradigm.

Conclusion : Be the #Good, if it becomes inevitable turn to the #Bad but never turn your code to be the dreaded and hated #Ugly.

Avoid side effect methods as far as possible.

Subscribe: https://t.me/dailypattern