Unfortunately I have not enough time (refactoring this class took me about 25 hours) to refactor everything I want. When working on the query() method, I realize that a change in the metadata structure of the framework, would have allowed me to split the remaining query() method into even smaller pieces. As I later determine this change would have had a impact on the updating method as well. But because this refactoring will have quite dramatic consequences for the whole framework I only note the fact and continue. I think refactoring is also about when to stop doing it (see A.1, p.
).
The methods that follow are quite easily to refactor as I have already laid the foundation for it. I extract the code that creates the SQL statements used to interact with the database to own methods which are moved to DatabaseFormat after clearing them up. Of course I continue writing tests and running them until they succeeded.
When I ponder about refactoring the update() method I find a failure in the design of the approach of distinguishing between update and insert operations on the database. By now only data that has been read from the database is used to update, newly created data is just inserted. But rethinking the approach does not show up an easy solution for this problem. Either newly created data can be used to update existing data or read data could have been removed in the meantime requiring an insert operation to recreate it. Therefore the most convenient method to detect the correct mode of operations would be to check the database before deciding on the operation. But this will require far to much time and effort to be useful. ...
After finishing the update() method and doing some clean-up at the end of the class I am happy to see that the refactored class looks much better than its predecessor.