You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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 existingStructure
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 theMoveableUnit
classThe text was updated successfully, but these errors were encountered: