/customers/iconara.net/iconara.net/httpd.www/blog/wp-content/plugins/wp-super-cache/wp-cache-phase1.php Iconara » Architectural Atrocities, part 3: Side effects

Architectural Atrocities, part 3: Side effects

In programming, “side effects” refers to things that happen when you call a function or method, besides the returned value. For example, a method might change the UI, log a message or write to a database, and yet return a value at the same time.

Some say that side effects are strictly evil (mostly functional programming zealots), but it’s quite common in object oriented programming. My opinion is that they should be avoided, and if you apply the OO maxim high cohesion (a method should do one, and only one thing) thoroughly, you will not have many.

However, in OO, side effects in the strictest sense are almost impossible to avoid. Updating a UI, for example, or any form of drawing is a side effect, since it is not a part of the return value of a method. So, in OO, if you speak of side effects, it has a looser meaning, I would say.

Anyway, to my point: I don’t like the Tween class. To tween something, you create a tween object, and then you… no you don’t. You just create it. As a side effect, the constructor of the class also starts the tween. I actually spent an hour or two once just trying to find out why my tweens had started even though I didn’t call start() on them… only to find out that I have called start() for no reason all this time.

More on side effects from the Portland Pattern Repository: SideEffect

Leave a Reply