Unit class hierarchy inconsistency

[bevans2000]

Describe the bug A part of #647 the Unit hierarchy has been shown to not be accurate and the Unit class is populated with methods that are only applicable to some of the subtypes. Hence it creates an inconsistent design/model. Unit contains methods that are only relevant to entities that can move around; e.g., setBuilding, setSettlement and more complex logic that needed to identify location state. The reverse is also true in that classes in the Structure sub-hierarchy have to implement methods that will never be called. This means that the Unit class has more logic than needed.

Expected and unexpected behavior The solution is to create a new class MovableUnit that is a sibling on the existing Structure class that represents Unit that can move. The latter represents Unit that cannot be moved. This give a clean logic structure. It will allow some properties/methods to be move from the Unit to the new class as well as some default implementation removed in the Structure hierarchy. In addition, it can strengthen the use of the transfer method as this would become abstract on the MoveableUnit class

[mokun]

Yes it's good idea to create Moveable vs. Nonmoveable Unit.

[bevans2000]

I think the new Unit hierarchy should be as below. Key changes:

• Settlement parented off ``Unit```
• MovableUnit new class for those Units that can move around a Settlement

[mokun]

MovableUnitnew class for those Units that can move around aSettlement```

Sure. I like the concept of separating movable and non-movable units.

[bevans2000]

It will help up the Unit class as it has methods not applicable to all subclasses