When there is a class Car, should a car that is convertible subclass Car or not? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

Say, if in our object design, there is already a Car class, and now there are some cars objects that convertibles.

We can define another class Convertible and subclass Car, but then let's say, we later on create a class that's FourWheelDrive that also subclasses Car, and later on, if we have a FourWheelDrive that is also a Convertible, then how can we handle it?

How is the design above compared with the other design, which is a isConvertible boolean in the Car class, and a isFourWheelDrive boolean also in the Car class, just as flags or properties of the Car class. So we won't define extra classes in this case.

Update: in a real life example, in our project, there was a Credential class that stores a user's info: user_id, encrypted_password, email_address, etc. When we allow logging in through Facebook, Gmail, Yahoo, MySpace (using JanRain), a coworker proposed adding FacebookCredential, GmailCredential, YahooCredential, all these classes that subclass Credential. I was a bit overwhelmed that there are so many classes, and when you see a method, you have to look at whether the subclass overrides it or is it the base class's method. I would have done it just using a code to tell which provider of the credential it is (Facebook, Gmail, etc), and use this provider code to do the appropriate things. (for example, some providers have verified email address, some don't). So I just don't know if my coworker's method is more appropriate or complicated.

Answer 1

You might want to take a different approach by using the http://en.wikipedia.org/wiki/Strategy_pattern You can define different behaviours for diffrent types of cars, so you don't have lots of subclasses.

Answer 2

You imply that you're using a language which doesn't support multiple inheritance. Does the language support interfaces? You could have a base abstract class Car. (Abstract because one never builds a "car" but instead builds a specific implementation of a car.) Then instances of classes which inherit the abstract base class can implement common interfaces:

• IConvertible
• IFourWheelDrive
• IHybrid
• and so on...

The idea is that the abstract base class defines what something is at its simplest. The interfaces define what type of that thing it is, and there can certainly be overlap. Those interfaces would contain the operations and properties which are specific to that type. (An IConvertible would have properties and methods that non-convertibles wouldn't have, same with an IHybrid, etc.) Then the specific implementations could add their own unique flair to the whole thing.

It's a bit of a contrived example, as you know. So it's all conjecture. But for this particular theoretical implementation I'd go with interfaces.

Answer 3

In addition to your concern about four wheel drive cars which are also convertibles, consider the following:

• Are all Convertables cars?
• Are all vehicles with four wheel drive cars?

To me, these sorts of questions point at these being attributes of car which do not define a type. In a sense, they're no different than color or the number of doors, etc.

Answer 4

It basically comes down to a question whether you need/want to change the functionality of the class based on whether it's a convertible and or four wheel-drive. For example, if you need/want to have a raise_top and lower_top for a convertible, and lock_hubs and unlock_hubs for a four wheel-drive, then you pretty much need to use inheritance to add classes that have those. In such a case, then yes, there's a pretty fair chance that an open-top 4WD vehicle will inherit from both the convertible and 4 wheel-drive classes. As such, if you're doing that in C++, those classes should probably inherit virtually from automobile (or whatever you name your base class), and in something like Java, they'll pretty much need to be interfaces rather than classes.

On the other hand, if you just need to be able to find out whether a particular vehicle is or isn't convertible and/or 4 wheel-drive, then a simple Boolean (or enumerated) field in the class should be perfectly adequate.