Let\'s use an analogy to describe the relationship between classes and interface

Question

Let's use an analogy to describe the relationship between classes and interfaces: Imagine that a programmer must design several classes for a video game. The game is a car racing game in which the user can choose from a variety of cars. When the game first begins, the user is presented with a list of cars, and each car has different specifications, such as make, model, year, engine size, color, etc. As the user progresses through each level of the game, he is awarded money which he can use to upgrade his car. The user may purchase parts, nitro boosters, custom paint jobs, decals, etc. How should the programmer handle these variations? The first solution that comes to mind is to design a class called Car, which contains a number of instance variables to keep track of improvements made to a car. However, not all cars are the same. A 2010 Chevy Corvette Convertible shares very little similarity with a 1984 Dodge Station Wagon -- other than the fact that they both have four tires and a motor! Different types of cars maneuver, accelerate, and appear very differently. Some cars have more than two brake lights, some cars have hatchbacks, some cars have sun roofs, and some cars are convertibles. Obviously, a single class couldn't do it all -- at least not without being designed in a very confusing and incredibly dense manner. A better method of handling all of these variations would be to design an interface called Car, which declares only the methods that apply to all cars, such as getMake(), getModel(), getYear(), getEngineSize(), getColor(), etc. Afterward, specific classes such as Corvette and Wagon could be designed to implement the Car interface, and each separate class could be designed with very specific features in mind. For example, the Corvette class could be designed with convertibles in mind, whereas the Wagon class does not need to be concerned with this particular feature. After the programmer has declared the Car interface, along with a few specific types of cars, he may begin work on creating the list of cars presented to the user at the start of the game. Rather than depend on a single class that may need to be completely overhauled to incorporate new features as new cars are added to the game, the programmer is free to design much of the game without having to worry about his interface changing. Thus, the programmer has avoided painting himself into a corner. Once the game is finished, he may even decide to create an improved version of the game, and, if he designed his interface well, he will still be able to use it in the newer version.

Explanation / Answer

The idea is to create an interface that acts as a base for all other cars. The interface acts kind of like a model car. It contains all the characteristics that all cars have in common (An engine, wheels, color, year, make, model, etc). When someone wants to create a car class, they create a new class using this interface. They then overide exisiting car functions or create news specifically for the new car.

Related Questions

Navigate

• Browse (All)
• Browse L
• Subjects

---

---

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.