Separation of concerns

IMG_0925Dealing with passive templates, I sometimes hear separating template and logic splits up things and makes it harder to maintain. I somewhat confused about that. I don’t solve my maintenance problems very often by putting things together. Much more often I separate things to gain focus and open the door for reuse. For example break one method into two or even more. What are the effects?

- Additional code. Method declaration as well as method call are added.
- Loss of overview. When I look on the outer method I can’t see what happens in the inner and vice versa.
+ Gain focus. There’s only a small piece of logic to understand.
+ Create a new reusable artifact. Maybe this will not happen as fist step, but often it’s the most important argument.
+ Give a name to the new method. This means a minor piece of additional documentation.

Very similar things happen when separating template and logic:

- Additional code. (Only if the existing model is sufficient for the view technology.) Template code only has references, that have to be accessed by the logic code.
- Loss of overview. In the template one can’t see the logic anymore. However, in most cases this is not too interesting anyway.
+ Gain focus. When writing templates one don’t need to care for data types, the exact structure of a model, or have any huge APIs in mind. Especially for people, coding not too many templates this is a great help. On logic side the code get’s much more compact, simpler to navigate and better integrated.
+ Create a new reusable artifact. As methods any named section can be used independently. As the data is not bound internal by direct attribute access, another piece of logic can provide it from somewhere else, just like the parameters in a method call.
+ …and there’s a piece of code that gets a name. Just a little piece of instant documentation.

See you on

About these ads