Car Dealer Design - w/o Strategy Pattern

Prev post

Continuing series of designing Car dealer example with patterns, my approach is to design without patterns, observe the problems, apply patterns and feel the advantages of patterns. As we have applied this approach to design w/o decorator, with decorator, now we are going to design another feature in car dealer example.

One of the requirements or use cases in car dealer web site design is to show interactive demo and virtual driving experience to user. This involves giving the user some kind of control to make car start, move, accellerate to show how fast it can go (may be something like..this car reaches 0 to 60mph in 5 seconds) and all. So, to support such kind of requirement, we start adding certain methods and properties to various classes in our design. The UML below shows a raw design to support move car feature.

Car speed varies based on its engine that manufacturor uses to build the car. In the design Corrolla, Accord have varying initial moving speeds because former uses V4 and later uses V6. Lets add MoveWithV4 method inside Car class so that any deriving car that uses V4 engine need not have the code duplicated. But the issue is there will be few cars which use V6 engine, and not to duplicate code in all cars that use V6 engine, we can add one more method MoveWithV6 in Car class. Though we achieve the goal of not duplicating code all across, but there is an inherent problem with this design. Some one can call CorollaSedan.MoveWithV6 and get the corrolla move faster. That means, any deriving class can also use the methods which it is not supposed to.

So to get around this problem, we could override MoveWithV6 in CorollaSedan class and throw MethodNotImplemented exception from it. This needs to be done in all deriving car classes which do not support certain methods that exist in their base classes...maintaince overhead. What if a new car comes into the market that uses a very smart engine that makes car fly. So you would either override the respective sub class or put the method in Car class to not to replicate code. we end up in same problem again. To solve this problem, we need to externalize the varying behaviour. The varying behaviour in this example is moving with engine.

In the next post, you will see how Strategy pattern comes to rescue from this kind of problem. stay tuned.

Next post