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
0 Comments:
Post a Comment
<< Home