It can be tempting to create "convenience back doors" in code to make short cuts. "Isn't it easier to skip all these layers and just call layer 1 from layer 3?". Yes, it is easier in the short run, but later on it will make refactoring very hard. I think the word "just" in any code-related conversation should set off alarms in your head. Layers are there for a reason.
I am currently involved in replacing a DAL for an existing legacy application. The existing DAL creates SQL statements and passes them to a handler that executes the statements with a connection from a connection pool. My job is to remove the SQL statements and replace them by service calls. Luckily the statements are very simple, because the application once used DBase, which isn't a relational database. So most of the SQL statements don't even use joins. This is of course very inefficient, but in this case my luck.
I started bottom-up, so I abstracted the SQL handler first to be able to monitor what is going through. Secondly i started looking for calls to the SQL handler class. It is a Vb6 application, but there is actually a layered architecture, so I figured that too wouldn't be too hard.
Until i found a function in the application layer. The function was there for "convenience". With the function anyone can throw any SQL statement at the SQL handler. And did i mention ... the function is part of the COM component's public interface.
The point of making classes and functions or, more generally, layers, is to abstract implementation details away from its users.
So much for abstraction.
No comments:
Post a Comment