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.
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.