state pattern

The logic to change state is only inside one method (initVesselView(…)) inside GrVessel.java. 

if (viewType == VIEW_STOWAGE) {
            vslView_ = new VesselStowageView(leftPoint, bow2Left, leftCenter,
                                             rightCenter, shipWidth_);
        }
        else if (viewType == VIEW_SIDE) {
            vslView_ = new VesselSideView(leftPoint, bow2Left, leftCenter,
                                          rightCenter, shipWidth_);
        }
        else if (viewType == VIEW_PLAN) {
            vslView_ = new VesselPlanView(leftPoint, bow2Left, leftCenter,
                                          rightCenter, shipWidth_);
        }
        else {
            throw new IllegalArgumentException(
                "GrVessel::initVesselView-->Invalid view type!");
        }


We do not need to repeat this logic of changing view in many other method.
This is the benefit of State design pattern.
The 3 state classes here are VesselPlanView.java, VesselSideView.java and VesselStowageView.java

Please note that in the state classes, if a method is supported by stateA and not supported by stateB. 
Then, in stateB, the method body will throw an exception (IllegalArgumentException) to indicate that coder call the wrong method in the wrong state.

Example, in VesselPlanView.java, public boolean addStowage(...).  This method is only meaningful to stowageView.

public boolean addStowage(IlvManager manager, List transformList, IlvGraphic stowage, String stadBayN,
                              boolean isSelect) {
        throw new IllegalArgumentException(
                "GrVessel::addStowage-->be sure the vessel at stowage view!");
    }


Hence, in PlanView, the method body will throw exception.

Just to share with you a better way to code.