ColdSpring OO design refactoring

Today, i begin a minor - major rework of a piece of software that i created about a year ago. The primary areas where i intend to do this work is in the model layer of the application. I plan to re-factor code by moving bus. logic further down stream into the bus object bean. I actually need to use that too, i am not really using the bean to do the CRUD work.

I plan to use ColdSpring to create the bus object, the service and its dependencies and to tweak the controller to use the service where necessary. I will tweak the service to utilize the CRUD methods in a more pure OO implementation. This means passing around the reference to the bus object and using it when performing the CRUD operations. The refactoring in the service, DAO and Gateway will include removing init methods, since ColdSpring will be handling the creation, initialization and dependencies. As a result, the knowledge of the collaborating entities will be lifted from the collaborators and placed in an abstract container, ColdSpring. This again promotes reuse of the tighly cohesive objects with little coupling. The coupling is abstracted away.

The results of this refactoring will not be evident on the user side, there will not be any changes to the GUI, probably a bit to the API, but the actual changes to the application front end will come later.

I will check back in with progress later.

Hi level steps:

1 - create a new services configuration file in the sub app for the objects to be created and managed in the assessments subapp.

2 - plug coldspring into the machii controller

3 - point the plugin at the services file

4 - add the objects to the services file

5 - modify the objects added to the services file, removing the knowledge of each other, remove the init methods. Create setter methods in services, so dependency injection references will work! Remember to name the setter method the same as the injecting method, like setBeanName. For objects that have init() methods left, DAOs, Gateways, Utils, if instantiating from CS, pass in required parameters using CS provided tool, $varname. For now, i decided to not require the parameter and gave it a default value, this way, i can simply add the parameter in the CS container at any point and it will just work!

b - other things i needed to clean up in prepping objects for CS and OO purity included; removing extends from two of the objects, these are old from years ago, i copied into my application space and noticed they were extending listeners, opps - i noticed a bunch of extra methods after i had created and dumped the bean, when i looked more closely, i noticed that the objects (assessmentDAO, assessmentGateway) where extending the listners - that was a mistake and highlights the fact that these two objects have sat out in space and not be used. One of the objects was not returning itself either.

6 - I currently have the bootstrapping code in the index.cfm file in the root of the sub-application. I wanted to follow the best practice from CF objective machii training where we would use Application.cfc and load all the bootstrapper code in it, and leave a empty index.cfm file. I tried that and had problems, and was not willing to look further into it.

7 - I also spend time in the listeners, removing object creation code from the configure method. Im still not totally clear what the best practices are for referencing bootstrapper variables created pointing to the coldspring created objects from within the machii listeners. I am currently using variables.amanager = application.CSBeanFactory.getBean("beanName");.