...
The Big Problem : The ScriptLauncher hardwires XML Configuration to Business Logic
bWhat What we see is that the Script Launcher hardwires all Business Logic to XML COnfigurationconfiguration, and while this is while a great prototype, certainly not very extensible. What For instance, what if we may want to initialize other details into the command or step, what ? What if we are calling something that uses a different method than a static main to execute, ? and what if we want to set certain properties on its state beforehand. TO To do this these tasks we would either need to rewrite the class with a main method, or we would either need to extend the launcher to do this, or add those details from the dspace.cfg. So what we will show you in refactoring this code is that you can get a great deal more flexibility oout out of Spring with a great deal less work on your part. Spring applies the concept of "inversion of control". The Inversion of Control (IoC) and Dependency Injection (DI) patterns are all about removing dependencies from your code. I our case, we will be removing a dependency on the hardcoded xml file for configuration and liberating the Command/Step domain model from the ScriptLauncher, allowing for possible reuse in other areas of the application.
Spring Based DSpace Script Launcher
Firstly we recognize that we have few domain objects here that we can work with, Command, Step and Arguments are all ripe to be defined as interfaces or implementation classes that capture the domain of the Launcher that we will execute. Perhaps by creating these we can disentangle the Business logic of the Launcher from its configuration in xml. Doing so without Spring, we might still ahve to bother with parsing the xml file. So with Spring we get a luxury that we no longer need to think about that.
...