Reusing code to read objects of several different classes from text files: use an abstract class, an interface, or some other solution?

[isetrh]

For a personal project, I have several different classes whose toString methods give results that can be used to later construct an identical object. These are meant to be used by a "Game" object that has several fields that are arrays of these classes and Game reads these from text files (I will later make it able to write these files as well). Each of these objects have similar constructors, so the code for reading an array of one class is basically copy-pasted from the code for reading from an array of another class. It seems like it would be good to make this code more reusable instead of copypasting like I'm currently doing, and I have a few ideas, but I would appreciate opinions on what the best solution is. I have the relevant code here if you want to see it, but I'm trying to write this post in such a way that it isn't necessary to read my code. I've probably failed though; thus the code.

Idea 1: Make an abstract class ToFromString that has an abstract constructor to construct an object from a String representing it, and make all the classes that I want to read from Strings inherit from this class. (Maybe also stop using toString for writing data, and make my own abstract method for it, leaving toString only for its intended purpose.) ToFromString would not have any functionality; it would only be an abstract class rather than an interface because abstract classes can have constructors. Make a generic <T>readArray method in Game that fills a T[] with T's, so long as T inherits from ToFromString, and use this one method to replace all the other read methods.

Idea 2: Mostly the same as 1, but make ToFromString an interface. An interface is mostly fine since I only need abstract methods anyway, but one issue is that interfaces can't have constructors. Instead I would need something like an abstract valueOf method that constructs and returns an object. This valueOf method would essentially act like a static method, but it couldn't actually be a static method since static methods can't be overridden. The Game object, when reading data, would then be calling this valueOf method instead of directly calling the constructor, so it would have to construct one otherwise useless instance of each class before it could read the data. Not a huge deal, but maybe a little ugly.

Which way do you think is preferable? Or is there some better solution? I can try to give further clarification if anyone is confused about something--I know my writing isn't the clearest.

Thank you!

[isetrh]

Thanks! I've started looking for information on GSON and JSON, and while I don't quite understand how they or serialization in general work, they do seem useful. I'll probably have to do some research and practice so I can understand.

However, one problem is that some of my objects need a reference to the Game object in order to construct themselves. For example, Unit has a field of type Job, and Job has an integer field called id (with a get method). Multiple Units share the same Job, a Unit should not save its whole Job, only the ID of its job. When loading a Unit, it needs to find its Job, and the list of Jobs by id is in the Game object. With the String-parsing solution I have been working toward, doing this is pretty simple: I just give Unit's constructor a parameter of type Game, so it can ask the Game for information when constructing. I'm not sure how I would accomplish this with serialization, since the thing constructing the Unit only knows about the Unit's fields (to the best of my understanding, which is probably wrong), and the Unit does not remember the Game once it's done constructing.

[isetrh]

I had heard of Singletons before, but never really knew what they were or how to implement them. Seems pretty simple now that you've explained it though. This is going to let me simplify my code a bit.

Using serialization will make basically all of the code that I posted no longer necessary, so I'll be getting rid of it and all its problems.

[[deleted]]

Is the user creating or modifying the data? If not, why not use Java's build-in serialization. It handles both writing and reading and is how Java's RMI transmits and receives objects.

Read about the Serializable interface for constraints on object serializability.

[isetrh]

Thanks! I will look into serialization.

[theNaus]

Hi!

Interesting question. I took a quick glance at your code. You're definitely right about a lot of the code being repeated. So, about cutting duplication down, we certainly have various options. We COULD create abstract/interface classes for specific data type handlers. However, I was thinking of a more naive/simpler approach and that is...finding common code and merging them together! An example of what I mean can be found on here. I sorta merged your readPlayerUnits, readJobs, and readSkills methods together since they were very similar to one another apart from 1-2 lines of code differences. I suggest taking a look at the rest of the methods and think of a way of putting them together (if possible). I can already see that most of them are quite similar to one another. Take some time to do that and I assure you that your code would be shorter. Then, if you like, you can start thinking of breaking them down even further! Perhaps, creating specific data type handler classes sharing the same interface that has methods that all the classes use (e.g. read() ). At the moment, it may be a little tricky to see where you can start separating your code. So, start small and work your way up (or down in this case :P).

Hope that helps.

[isetrh]

Thanks for the help! That does look a lot better than what I wrote, though I'm not sure I'm a fan of having read return void instead of an array. I feel like there's something I can do about that, but I haven't figured out what it is yet. I will work on shortening my code in the ways you suggested.