2: Putting Plans into Action with the Strategy Pattern in Java

Creation Code128 in Java 2: Putting Plans into Action with the Strategy Pattern

And you get:

Not bad, say the CEO and the board Who needs design patterns they ask, shooting you dirty looks But then they get a contract to produce helicopters Helicopters, they reason, are just another type of vehicle So they create helicopters using a Helicopter class, extending the Vehicle class like this:

public class Helicopter extends Vehicle { public Helicopter() { } }

But now there s a problem if you run the helicopter in addition to the cars like this:

public static void main(String[] args) { StreetRacer streetRacer = new StreetRacer(); FormulaOne formulaOne = new FormulaOne(); Helicopter helicopter = new Helicopter(); streetRacergo(); formulaOnego(); helicoptergo(); }

Then you get this when you run all three vehicles: one street racer, one Formula One race car, and one helicopter:

That doesn t look right, says the CEO doubtfully Why should the helicopter be driving Shouldn t it be flying And the problem only gets worse when MegaGigaCo gets a contract to produce jets, which they also extend from the Vehicle class:

public class Jet extends Vehicle { public Jet() { } }

Running all four vehicles street racer, Formula One race car, helicopter, and jet, now gives you this:

That s definitely not right, says the CEO Jets don t drive when they re in the air They fly and fast No problem, say the company programmers We can just override the go method in the Helicopter and Jet classes to give the right behavior They create something like this, which makes the Helicopter class fly, not drive:

public class Helicopter extends Vehicle { public Helicopter() { } public void go() { Systemoutprintln( Now I m flying ); } }

Okay, says the CEO, but the board of directors has already voted to change that from Now I m flying to Now I m flying at 200 mph next week And more changes will be coming later, if I know them There s a problem here, you explain, and it s that the company programmers are spreading the way a single task is accomplished driving a car or flying a helicopter across several generations of classes That s not necessarily a big problem, but if how you want to handle that task is going to change fairly often, as here, having to edit all those classes becomes a maintenance issue You say: maybe inheritance isn t the answer in a case like this, where you have to spread out the handling of a changeable task over several generations of classes You re going to be maintaining a lot of customized code across generations of classes when that task changes And as the derived classes get to be long and involved, it s going to be tough to maintain them through all those changes You re going to have to update the go method forever The problem you re trying to solve is how to avoid spreading out the handling of a particular, changeable task over several generations of classes If you don t avoid that, you ll be editing a lot of files to update your code

Perhaps there s a better way of handling the task of making vehicles move than using inheritance in this case Hey, says a company programmer how about using interfaces instead of using inheritance You could set up an IFly interface and give that interface a method named go that the Helicopter class has to implement as shown in the following:

public class Helicopter implements IFly { public Helicopter() { } public void go() { Systemoutprintln( Now I m flying ); } }

No good, you say You haven t solved the problem at all each class and subclass still has to implement its own version of the go method, which is just as bad as when you used inheritance And because interfaces don t include code, you still have to write custom code in each class, which means code reuse goes out the window