Refactoring to separate FileIO and Serialization - BBK-PiJ-2014-66/cw4 GitHub Wiki

11 March 2015

• Have got a "finished" and functional version tagged as release 1.0.0.
• But on reflection I am not happy with the current FileSaveRetrieve* stuff
  • FileSaveRetrieveImpl mixes together file input/output with the two types of serialization support.
  • The enum FileSaveRetrieveMethod is badly named it is an SerialEncoderType

plan for refactoring

• Create a new package serialencoder to contain the encoder/decoder stuff - this can be in src rather than development to be same in Master and Development branches.

• Create a separate Interface SerialEncoder that provides methods to encode an Object to a String or file and back again. This will have two implementations: SerialEncoderImplXStreamXML and SerialEncoderImplJOSBase64 (Java Object Stream Base64 encoded)

• On second thoughts SerialEncoder should be an abstract class rather than an interface

• It can provide methods to write the encoded string to file and to read (in common).

• It will be extended to concrete classes SerialEncoderXStreamXML and SerialEncoderJOSBase64 with the code for the particular encoding.

• On 3rd thoughts SerialEncoder should be an interface that is implemented by abstract class SerialEncoderImpl (with the file I/O methods) that is extended by SerialEncoderImplXSTREAMXML and by SerialEncoderImplJOSBASE64. It is cleaner to have an interface for users.

• Move Enum FileSaveRetrieveMethod to package serialencoder and call itSerialEncoderType with two values XSTREAMXML and JOSBASE64 Turns out that that the Enum is not needed at, delete it!

• FileSaveRetrieve will only have methods to save and retrieve from files. The string methods will go.

• FileSaveRetrieveImpl will:

  • have a SerialEncoder class variable that will be initialized to a new SerialEncoderImplJOSBase64 and can be overridden by setSerialEncoderType() to a new object. This will be used to do the encoding.
  • Just dealing with storing the name for the file and encoding type / object. It will use a single SerialEncoder to do the saving. For development branch this will be the SerialEncoderImplXSTREAMXML producing nice XML. But for the to-be-marked Master encoding will be done by SerialEncoderImplJOSBASE64.

• Providing a means to switch modes was unnecessary and complicated things such as testing and the user interface! So apply KISS and strip it out

• This way I can avoid the static methods and if else selections in current FileSaveRetrieveImpl

• I think this is much cleaner and more Object Oriented - different functionality is in different classes, shared functionality is in the abstract class rather than having everything lumped into one class.

• One advantage of having a development branch is that if the work does not go to plan release 1.0.0 can be marked as is.

---

Final thoughts. It all worked out in the end. The above was rather a lot of work but it was useful.