In the textbook, the character “Joe” was facing a problem with scalability. The SimUDuck application has reached a point in which Joe & the other developers must decide between functionality or manageability. If they wish to add new behaviors (such as ways of flying, or types of quacks) they must sacrifice manageability as they’ll have to go through each sub class and modify custom methods. If they were certain that the SimUDuck would not be developed further, then employing the Strategy Pattern could possibly be overkill. For it wouldn’t be all that bad to override the fly() method on one sub class (RubberDuck). But because the application still had life and was likely to become bigger with different types of ducks it would be much simpler to use the Strategy Pattern. In other words, when using the Strategy Pattern at the early stages of an application it might seem like overkill. However the true payoff of the pattern is how scalable it makes a program. Expanding in the future becomes a breeze….
You have understood the strategy pattern but I noticed in the project your turned in you did not implement it correctly. Animates will need to implement movable and add the function goTo() and then anything that extends animates can have its own goTo() that overrides it. I don’t know whether that logically suits your implementation but that how I got the error fixed, look into that and see if you fix it and look at using abstract keyword.