|
I see old-fashioned procedural programming concepts being used in object-oriented languages. I also see dead people, they're everywhere.
As a freelance programmer specializing in Java I often find myself working with legacy code that is not only poorly documented but often contains three to four times as many lines of code as is necessary to accomplish the task.
It also amazes me how often I see old-fashioned procedural programming concepts being used in spite of the fact that the programmer is writing in a true object-oriented language.
The legacy code I worked on (written in Java) from a recent contract is a good example.
An HTTP interface was used to handle requests and responses.
Within the requests were multiple attached data files.
The data files were destined for a specific folder (aka mailbox1) on the server.
A Servlet (Upload1.java) was written to handle the requests to store files to mailbox1 and give a response back to the client in an XML formatted document indicating success or failure.
Later as other clients needed to have this same capability (keeping their files separated by folders) other mailboxes were added as in mailbox2, mailbox3, mailbox4 and so on.
The code to handle each one of these mailboxes was achieved by taking the original Servlet for mailbox1 (Upload1.java) and making copies for each of the other mailboxes as in Upload2.java, Upload3.java, Upload4.java and so on.
The original Upload1.java file was approximately 800 lines of code. For the most part the only difference between it and the ones to handle the other mailboxes was the information representing the path on the server for the mailbox.
I am sure that at the time these were written that seemed like quite a logical solution.
When the decision was made to add some new functionality to the program there were a total of 27 files which needed attention.
After taking an inordinate amount of time to examine all the files and determined that the functionality of each Servlet was identical (outside of which mailbox it went to) a decision to make the code more maintainable was made.
Before any changes could be made the following facts had to be taken into consideration.
The incoming requests from an outside client were not generated through human interaction. These requests had been hard coded into programs residing on the outside client machines. All changes to be made required that the incoming HTTP request would not need to be changed in any way as this would prove problematic for the outside clients.
Here are some basic concepts presented merely as examples.
- Rewrite Servlets for each of the individual mailboxes such as Upload1.java for mailbox1, Upload2.java for mailbox2, Upload3.java for mailbox3, Upload4.java for mailbox4 and so on.
These Servlets however are very small and very simple.
Their purpose is to set a new parameter into the incoming HTTP request object.
The variable name for the parameter is simply “mailbox”.
The value to set would be “mailbox1” or “mailbox2” or “mailbox3” or “mailbox4” based on which Servlet we are dealing with.
Once this parameter is set the request is then forwarded to a single servlet which will handle the actual file processing for all mailboxes.
To handle the processing for all mailboxes we rename one of the original servlets which had all the code for processing files for a given mailbox and call it "UploadProcessor.java". We then had a request.getParameter(“mailbox”); line of code to find out which mailbox we are dealing with and then do the storing of files to their respective mailboxes and return a success or failure response in the XML document just as before.
- Assuming we are running on a Tomcat server, another concept is to simply write the single Servlet “UploadProcessor .java” and then edit the web.xml file and map calls for the Servlets of “Upload1”, “Upload2”, “Upload3”, “Upload4” and so on to all be handled by the “UploadProcessor” Servlet.
In the UploadProcessor Servlet we simply check the requested URL for the name of the Servlet that was requested and use it to look up a value out of a properties file (which uses name value pairs).
This concept is actually much easier to maintain if a new mailbox needs to be added. This is because there are only two places where any editing needs to be done. One edit would be in the web.xml file to add the name of the new “pseudo Servlet” which simply maps to our UploadProcessor Servlet and the other would be in the properties file where we would add the name of the servlet and a value for that name which represents the mailbox it should go to.
The goal in using one of these concepts was for maintainability of the code. It also demonstrates a very small step away from a deeply entrenched habit of programmers who think in procedural methodologies to write a complete new application to accommodate one simple variable.
There are other concepts which could have been used to decrease the amount of code which would need to be maintained when and if changes were needed
|
