Pattern examples - Car Dealer Sample

Prev post

As said in my previous posts, the best way to understand a pattern is to understand the problem without the pattern and then apply pattern to see what issues it solves. In this series of examples to understand how to apply patterns and change the way we think to apply patterns, the first example is DOOP car dealer example. DOOP stands for design patterns and OO (just coined a new acronym to name the example :).

Scenario :

DOOP car dealer sells cars from various manufactorers (such as lexus, toyota, BMW...) to various customers. The dealer wants to set up a website where he can show what cars are in store, display cars, get orders from the customers, order tracking and more. Here are some of use cases that dealer wants to allow customers to do be able to use the web site for.

1. Display list of all cars, along with manufactorer's information.
2. Select a car to view complete information about that car.
3. Display car interactive demo to show customer virtual driving experience with keyboard navigation.
4. Display default features available to the car, and additional features that are available.
5. Display quote (prices) to the customer based on what features he selects for the car.

For now, lets assume the dealer wants to have these use cases implemented in initial iterations (know about iterative development?? lets talk about that later). In this series, we are not going to develop the complete website, but we are only going to design the domain layer of the application by applying design patterns. These domain layer classes then will be used to develop the web site. Considering above requirements, we are ready to start our design. Lets first put design patterns aside and design.

Note : we are not going to design a full fledged project. so classes, their properties, methods are going to limited to purpose of explaining the patterns.

1. Identifying the main classes in our design, the most prominent one is a Car class. We can make this as base class for other derivatives and place some of abstract methods for Car behaviour.
2. As there are going to be different types of cars, such as Coupe ( a 2 door car), Sedan (4 door ), SUV, etc. Each one is based on the body of the car. We can create few deriving classes from Car class as shown in the picture below.

3. There is going to be a separate deriving class for each type of the car. Now, to include support for various additional features for each car such as Leather seats, power windows, moon roof etc.. we start deriving each from the type of the car. To have support for LeatherSeatsCoupeCar, LeatherSeatsSedanCar or AllPoweredCoupeCar or AllPoweredSedanCar, we are going to derive from the respective car type. Check the UML diagram below.

3. Great. We have derived the feature added car from the respective car type. What if i want a coupe with AllPowered, LeatherSeated? No issues. I can derive a class named AllPwdLeatherCoupe from Coupe. Similarly, i would like to do for sedan, SUV or any other car type. Ok fine that works. What if i want a coupe with combination of features such {FeatureA, FeatureB}, {FeatureA, FeatureC}, {FeatureB, FeatureC}, {FeatureA, FeatureB, FeatureC}??? oh..i can support such kind of requirements too. I am going to derive each combination as a separte class. ok. so lets take a look of the design when only 3 features and 3 car types added.

Fine. Did you see the problem with the design? For every car type and every car feature and combination of features, we are going to add classes and increase number of classes. There will be numerous problems with such a design. Maintaining huge number of classes is going to be a nightmare. Each new car type that comes into the market, we need to add a large number of classes to our design to support such new design. Similarly, a new feature to a the car, we gotto add that feature and its combination to all car types. hhaaaaa...lot of problems. How can we solve these problems? When we end up in such kind of mess during design, think of Decorator pattern. My next post is going to explain what Decorator pattern is, and how it solves the problem we have here.

Next post