OO Side Effect Free Programming
programmersparadox.com
OO Side Effect Free Programming
1–8 of 8 posts
Re: OO Side Effect Free Programming
#2I disagree. Obsessiveness with small methods means less opportunity to keep your transient state in local variables, meaning you are going to make it object state (use object fields), which would actually increase your side effects.
Edit: It occurred to me that there is a case when you need to move state out of the stack to global or instance variables: programming async IO. It is notoriously inconvenient for exactly this reason.
Re: OO Side Effect Free Programming
#3Perhaps I've become an FP zealot, but I just can't agree at all with this author's suggestion. Small methods, "agile", unit testing, and all that are fine and lovely, but none of them approach the kind of safety and composability you get from true FP.
Re: OO Side Effect Free Programming
#4I disagree. Obsessiveness with small methods means less opportunity to keep your transient state in local variables, meaning you are going to make it object state (use object fields), which would actually increase your side effects. Edit: It occurred to me that there is a case when you need to move state out of the stack to global or instance variables: programming async IO. It is notoriously inconvenient for exactly…
Method arguments are a decent place to keep transient data as well. Local variables and object fields are not the only options for scoping your data.
Re: OO Side Effect Free Programming
#5I disagree. Obsessiveness with small methods means less opportunity to keep your transient state in local variables, meaning you are going to make it object state (use object fields), which would actually increase your side effects. Edit: It occurred to me that there is a case when you need to move state out of the stack to global or instance variables: programming async IO. It is notoriously inconvenient for exactly…
Method arguments are a decent place to keep transient data as well. Local variables and object fields are not the only options for scoping your data.
Exactly.. lol. I guess some people's field of vision is about this big ||
Re: OO Side Effect Free Programming
#6I disagree. Obsessiveness with small methods means less opportunity to keep your transient state in local variables, meaning you are going to make it object state (use object fields), which would actually increase your side effects. Edit: It occurred to me that there is a case when you need to move state out of the stack to global or instance variables: programming async IO. It is notoriously inconvenient for exactly…
Method arguments are a decent place to keep transient data as well. Local variables and object fields are not the only options for scoping your data.
You are correct, as long as you don't get too many arguments.
Re: OO Side Effect Free Programming
#7Re: OO Side Effect Free Programming
#8"It’s the closest to side effect free programming you can get in OO."
No, you can still have side effect free programming in OO. All of the techniques for programming without using mutable state are language agnostic and should carry over to whatever OO language you are using. You might have problems in languages that lack tail-call optimization, but even that can usually be worked around by using folds.
Now, I'm not claiming that it's feasible to make an entire app in (for instance) Java purely functional, but you can definitely build the majority of your app/library/whatever without using mutable state.