introduction

When implementing the enumerated types the problem of how to output their string representation when adding them to menus in the application arose Three different methods are possible for this:

• Integrating with the objects themselves
• adding the representation when and where it is needed
• Having a localization class that handles all the string representations in the whole file

Integrating

The advantage of this approach is it ensures encapsulation. For example if a new enumerated type is added, only that file needs to be changed, the rest of the program is unaffected. This is the simplest approach.

The disadvantage of this is that it is generally not a good idea to do this for reasons stated in this stack overflow thread.

In applications, it's good practice to separate data from presentation. It allows the data to be used in different user interfaces, it makes the data objects more lightweight, and it allows for the future possibility of internationalization.

Adding the representation when and where it is needed

This approach is generally a bad one as it massively increases the Class Coupling, meaning a lot of work is needed to add new types.

Localization

Similar to the approach used by the developers of the game Hearts of Iron 4, a separate class would allow easy translation into other languages. Basically any text given to the user is not directly coded in but obtained from this class. By swapping out the class with another, translation into multiple languages is simple.

Conclusion

Overall the first option of Integrating textual representation with the objects stands out as the best, as it is keeps the program simple. The second option does not really have many advantages and the third option is unnecessary. As the majority of pipers are the the English speaking world, and given the small scale of this project, it is unlikely translation to other langues would be useful. It is it, this method can be switched to at a later date.