Make sure that bad data does not cause the program to crash. As part of this, prevent the economics package having any ability to disturb the rest of the program:
Remove any hard-coded references to the data. in particular the existence and function of the Production technology should be data driven, not hard-coded.
Remove any hard-coded references to the test package.
Make sure that the preliminary turns are necessary. They should not be necessary - setup should be done as setup, not two phantom turns which may well have impacts outside the economics package (and currently do just that).
Make the treasury an object.
Move resources from MapSquare to MapSquareEconomy.
Make Economy an interface.
As an associated task, refactor MapSquare so it is just a container for the different aspects of the map square. The only methods should be accessors for the different components. Even the x, y coordinates should be a location.
Anything with a name ending in "info" is not an object. Change them into the equivalent object.
If possible, sharply reduce the number of classes. Certainly remove any that are not functional. Arrange a designed sub-package hierarchy.
Replace all static strings with polymorphic classes.
At present the economics package attempts to create all the necessary objects at initialization. In many cases the required data is not available at that time, and various hacks have been used to compensate. This has also put severe constraints on code outside of the economics package, and always has the potential (frequently realized) for crashing the program. Each part of the economics system should be initialized only when the data becomes available. Many of the required objects are now instantiated from data files and there is always a signal to say that the data is available.
Map squares are now created whenever they are mentioned, not when the map itself is created. As a result, the economics related matters are also created when there is no map, no terrain, and no population. The design of the MapSquareEconomy should reflect this.
The purely economics parts of MapSquare should be moved to MapSquareEconomy
An expression like: econ.getLabor()+ 0.1f
which occurs in the spontaneous colonization code is lazy code. If it is
necessary, it implies that the underlying model is defective and should
be replaced or fixed.
Split thre four purchase types up, so they can be dealt with separately:
Make the unit building system ask for the price at build time, not at registration.
DO NOT spray classes around. Class creation should be done in a fanatically parsimonious frame of mind. However, make sure each class actually does one thing and one thing well.
Do not force other things into a class. For example, a unit is not infrastructure. If they share some characteristics (and I do not believe they do), have unit and infrastructure extend an abstract class which has the shared characteristics (and nothing else). Better still, use interfaces.