100% Abstract class vs Interface

Question

Is there a reason 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.

Alla

how to define '100% abstract class'? – Politicking

java or php? which one is it? – Markland

I think he means an abstract class with only abstract methods, no default implementations – Vladamir

Answer 1

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.

Copious

in a 100% abstract class, you can also define non constant variables that can be herited. It is not possible with interfaces. – Juline

@Benoit Courtine exactly. I was adding this while you commented :) thanks anyway. – Copious

another thing is constructors... this is also not possible in interfaces – Vladamir

static methods don't contribute quite a lot, they can be in any class. but yes, they count. :) – Copious

@Bozho, re: static methods. My point was that since you cannot place them into the interface, you have to make another class just to put them somewhere. This is why we have the Collections helper class in addition to the Collection interface. – Markland

Answer 2

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.

Conover

+1. This is a problem with JDK interfaces like java.sql.Connection, where they add methods all the time, so the old implementations do not compile anymore. – Markland

If collection interfaces were "pure" abstract classes, we wouldn't need defender methods. – Maxillary

Answer 3

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.

Vladamir

Answer 4

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.

Ferret

Males & Females share functionality, they're not different implementations of a common interface. Also, the concept of a human isn't defined by the functions humans implement. – Prog

It would be easier for me to understand it as a class instead of an interface. I can actually visualize it as a tree and see that the Male and Female are branching from Human. – Ferret

Yes, and usually there is no human that is neither male nor female, so the base class Human would be abstract. – Salinometer

Answer 5

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.

Prog

Answer 6

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.

Cognize

Answer 7

If every method is abstract, then using abstract class rather than interface concept is something like "Forcing an IPS officer to do sweeping job". : )

Oeuvre

An abstract class could extend another abstract class that wasn't all abstract I believe. However it might be worth giving the question asked some examples of how it can or cannot be used and how interface cover the cases that a 100% abstract class would also solve – Supererogatory

As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. – Literal