I have been working on a project, recently, containing a number of large logic controllers that must perform a lot of work very quickly. As a result, I do not have the luxury of instantiating them each time they are needed. Instead I have a singleton of each controller. The net result is that I cannot use any local variables unless the values are static.
In order to make code like this practical, you must pass whatever variables are necessary for your process to each method called in your logic. At first there were only two or three variables, and maybe a dozen methods. As the controllers matured the number of methods grew, along with the number of variables passed to each method.
At this point I fell back to one of the Object Oriented principles of loosely coupling methods in your code. Instead of passing a large number of parameters as logic moved from one method to the next I created a composite object containing all the parameters. Some of the parameters were composite objects themselves. By creating the composite object, I am able to add new functionality to the flow of the logic by simply adding or modifying the parameters in the composite object.
Now I don’t have to spend a lot of time fixing dozens of method parameters each time I need a new parameter. I can add it to my composite object, and it is available everywhere it is needed as the program executes.
This change has made it much easier to refactor verbose methods into smaller units of work, because the effort to pass data through parameters is greatly reduced.
Since I have been disparaging the use of XML parameters for stored procedures, so that they can provide a form of composition, let me point out some differences. SQL is not object oriented; it works with scalar values or sets, not objects. Composite objects do not require heavy lifting to translate them into usable objects.
Sure, this is OO 101. But is something that we often forget.
Share your composition experience in comments here or by email to btaylor@sswug.org.
Cheers,
Ben