Refactoring Scripts

  • Oct 04, 2012
  • 0 Comments

This week, I came up with a plan for refactoring the action scripts into a more flexible and easy to understand format.  The plan is to replace PrecompiledScript, CompiledScript, UserFunctionalityScript, and ScriptFileUtilities with three classes that each have a well defined purpose.

The first class is named ActionScript and is a combination of CompiledScript and UserFunctionalityScript.  ActionScript contains all of the data structures needed to insert the script into another world along with getter and setter methods and a few other methods directly related to remixing the script.  Combining CompiledScript and UserFunctionalityScript and grouping all of the data structures together at the top of the class gives a clearer picture of the data model.  I completed the ActionScript class this week barring any changes that become apparent as I implement the rest of the plan.

The second class is named ActionScriptFactory and takes the input currently passed to the PrecompiledScript constructor and creates an ActionScript from it.  Currently the workflow of transforming the input to the PrecompiledScript constructor into a CompiledScript is spread out over multiple classes and points in time.  The PrecompiledScript constructor runs the ReferencesCrawler over the input, ScriptFileUtilities runs the ASTToScriptCopier right before writing the script to a file, and UserFunctionalityScript creates an instance of CompiledScript when the script is read back from a file.

I plan to consolidate this workflow to occur all at once in the ActionScriptFactory.  ActionScriptFactory will have a static method that takes the same input as the PrecompiledScript constructor runs the ReferencesCrawler and the ASTToScriptCopier and creates an ActionScript (equivalent to CompiledScript) from the result.  While I could put the workflow in the ActionScript constructor, the ActionScript class is already a large class.  Separating the process of creating an ActionScript from the ActionScript itself will make the code more modular and easier to read.

The third class is named ActionScriptFileUtilities and will play a similar role to the current ScriptFileUtilities.  The primary difference is that ScriptFileUtilities only encodes the script but leaves the decoding process to a method of UserFunctionalityScript.  This lack of symmetry is confusing.  ActionSciptFileUtilities will handle both the encoding and decoding of the script.  Once again, I could put the encode and decode methods in ActionScript but ActionScript is a large class so the code will be easier to read if separated into separate files.  If having a separate ActionScriptFileUtilities will require me to break encapsulation, I will move the methods into ActionScript.

Comments

  • No comments yet

Log In or Sign Up to leave a comment.