Tuesday, August 19, 2014

Separating the user interface form the rest of the code

Before I go back to my exploration of alternate programming languages a short one on design (or is it management ?). Every programmer knows that when you write code that might eventually get used in a GUI application a basic good practice is to always clearly separate the GUI code from the code implementing the actual functions. No big news here. There are a lot of tricks and design principles to help towards the goal of keeping things separate and of course any decent programmer should know about design patterns like MVC. Unfortunately, good design principles can be ignored or neglected if someone else is writing the actual code and additional control mechanism are needed (even you might benefit from additional safeguards). Code reviews can help. Automated unit test will also often help by encouraging developers to encapsulate and write more focused classes. Today's design or management trick is:
- Ask the programmer to write the functions in a separate module (module A)
- Ask him to provide a command line utility (module B) to call the functions in module A
Of course this does not provide an absolute protection against bad programming but it adds another level of control. This can be similar to what automated unit tests provide but not exactly the same since:
- It is fairly easy to check that module B uses A but not the reverse (no circular dependencies). You might not have the same level of isolation for the unit test code and the tested code.
- It is more focused on separating the two parts of the code. The part that implements the user interface (command line for this part of the project) from the part that implements the functions.
= The end product will often be a useful deliverable (this is the best application of this trick)
Of course writing a command line utility should not remove the requirements for automated unit tests.
If the result is not perfect, you or the other programmer doing the work will get another shot at cleaning up the API of module A when the time comes to use the module with the GUI. What do you think about this. Do you have any tricks to help you use good design principle ?

No comments:

Post a Comment