Side Effects - part 1

In my last post I mentioned the concept of side effects as one of my "pet peeves".

How othen have you implemented a method/function that does more than logically "task"?
It might have been an update of a persistent entity which also, in same method, added an audit log entry to the audit log. Or perhaps the "create" method of the Order service, also sends an email to the customer.

This is what I call side-effects, an effect of a task which has nothing really to do with the basic task at hand, in the above mentioned examples, update and creation of persistent entities.

Its often quite easy to implement the logic in the same method as the task to which it is closely coupled but I think it is a rather bad design.
In case of the Order service, how to differentiate creation of orders created by customers and e.g. system generated orders? Then you start to add booleans to method, signalling whether or not perform the side-effects and suddently you carry this information around from method to method.

Side-effects has no place in base logic, and its ALL in the context...

Part 2 : Side-effects and transactions

Classes er dead - long live interfaces

The above headline is a catchphrase used by Qi4j. While classes are nowhere near dead, even in Qi4j, the Composite Oriented Programming paradigm Qi4j presents seems really promising.

While I have only used Qi4j in my small "Hello World" kinda examples, I must say it just feels right - compositions of fragments, side-effects (a long time pet peeve of mine) and mixins IS the way of the future of programming and software design.

Now I've been thinking about why Qi4j isn't very hyped or even mentioned in main-stream programming media's, and I think the fact that you have to more or less go "all-in" scares most. I mean, you can't mix Qi4j with a normal DAO kinda project, you HAVE to use their persistence framework and Unit-Of-Work setup. I feel the Composite part should have been separated from the UoW part, which would have given us a choice...