100% Abstract class vs Interface

Is there a r开发者_Go百科eason to use a 100% abstract class and not an interface ? Can you give me a good example when to use both so I can grasp the concept a little?

Update: 100% Abstract class -> abstract class with only abstract methods. I'm curios if there are differences between php and java regarding this aspect.

Update2: Even if I understand most of the reasons I'm more interested in the conceptual more than technical reasons.

---

If by "100% abstract class" you mean "abstract class with no concrete methods", then I can think of a reason: visibility.

You can define an abstract method to be protected, and hence not part of the public API of the class. However, that seems like an odd design.

Another thing that came to my mind is when you expect to add common functionality to the base class - i.e. if it is likely to have some utility methods shared by all implementors, but these methods are not implemented.

Another thing - instance variables. You can have inheritable instance variables in the abstract class.

---

The one case where an "100% abstract class" may be advantageous over an interface is in places where API stability is a key concern.

If you write an API where other people are expected to implement your interface you have to stick to the interface. You can't add any methods to the interface later on because that would break all clients (you would have to work around this by implement a second interface and let your code check againt the usage with instanceof checks and provide an fallback).

If you realize the same with an class you can add (non abstract) methods later on without breaking the client.

---

Next to visibility, another reason could be to be able to specify a certain Constructor you want all implementations to implement, or define a certain property. But in general, I agree with Alexander that a 100% abstract class isn't a good idea. I would prefer an interface in most cases unless there's a very good reason not to use an interface.

---

I personally think the difference as conceptual more than technical. For instance it would be bad idea to have an interface called "Human" and implement them on Male and Female. It would make more sense to make the Human as class.

You can implement multiple interfaces and you should see interfaces as add-ons.

---

I'm not quite sure how to answer this conceptually anymore, but in practice I use interfaces for the following reasons:

• To indicate different classes have a shared interface: that you can manipulate them / use them in the same way
• You can implement multiple interfaces, but only extend one class

Reasons for using abstract classes:

• To share functionality between similar objects. For example Porshe911 could extend Car, overwrite a few methods and keep the rest.
• To write frameworks that people can adapt. For example by leaving a few crucial methods unimplemented and writing the rest of the class to be internally consistent provided you implement those few methods. An example would be a menu class with a single abstract method getMenuItems()

Your example of the 100% abstract class seems senseless to me. As far as I can see that would just make it an interface, with the added restriction that you can have only one.

---

100% Abstract class isn't good idea. For common structure of child classes uses Interface. For similiar classes with same some methods and not same others more better to use Abstract Class.