I'm trying to write a generic turn-based strategy game, with a few unit types, building types, etc. Since this is something I've never done before, and its not a very easily searchable subject, I'm asking here.
[See title question] I thought of two ways to implement unit/building types.
The first is the most obvious, with each unit being a complete object in-and-of itself. This means that it would have all stats, abilities, etc. contained in the object. A factory method would create these objects when units are trained. The main drawback is that each unit of the same type would also have duplicate information, like movement points, that are constant among all units of that type. Of course, in the event of stat upgrades, these could be changed directly, so they would no longer be duplicate.
The second method of doing this, is storing basic unit info, such as base health, movement points, etc. in a Unit_Types class. The unit object could then be done away with completely in favor of a list of unit types (whose important stats are kept in Unit_Types). Alternatively, the unit object could hold unique info, such as stat upgrades. This seems better because its less data being used, as well as making unit type upgrades simpler. The unit would just change its type field to its previous type plus 1. But this might be much harder once I actually begin writing it and encountering issues I haven't thought of yet.
Is there a standard practice? It seems like one of those things where one approach is way better than the other in 90% of situations.