pure abstract class and interface [duplicate]_问答_开发者

This question already has answers here: When to use an interface instead of an abstract class and vice versa? (26 answers) 开发者_如何学C Closed 8 years ago.

Can anyone tell me what exactly the difference between an completely abstract class and an interface?

An Abstract class can also have all its methods as abstract. An interface has all its methods as abstract. What is the main difference between the two in this scenario?

If there is difference between a pure abstract Class and interface? What is the use of interface? Where interface is being used we can make use of pure abstract class?

To complete the former answers :

An interface is a "contract". If a class implements an interface it have to propose all the services listed in the interface.

An abstract class is a skeleton. It defines a certain way its extended classes will work while letting them some free space (the abstract methods) to be unique.

A pure abstract class doing the same thing as a interface but have the problem of unique extending so, for me, it have no interest

Every interface is implicitly abstract: Every method declaration in the body of interface is implicitly abstract and public.

An abstract class has methods that can contain implementation. Abstract methods can be either public, protected or default access (package visible). Unlike interfaces abstract classes can contain fields that are not static and final.

Also see:
Interfaces vs Abstract classes and the Java tutorial

In Java and C#, one can use multiple interfaces to derive from and only a single class to inherit from,

One reason to choose pure abstract over interface is to force sub classes to implement particular methods that are implemented by a super class.

For example (in Java),

Say you want all extending classes to implement toString(), equals(), and hashCode().

You could create an interface called ForceSomeMethods for that contract, but those methods are implicitly implemented by Object.

Making ForceSomeMethods a pure abstract class with toString(), etc as abstract methods, all subclasses will be forced to implement those methods.

It's not a very theorotical explaination but, programatically it's all correct

                                    Interface                   Abstract Class
Extend Class                            No                          Yes
Extend Abstract Class                   No                          Yes
Implement Interface                     Yes(Extend Interface)       Yes
Variables                               Public Static Final         Public/Protected/Private/static/final/transient/volatile
Contain Non-Public Method               No                          Public/Protected/*Private
Contain Abstract Method                 Yes                         Yes
Contain No-Body, Non-Abstract Method    Yes                         No
Contain Defined Method                  No                          Yes
Contain Main Method                     No                          Yes

*Abstract classes can have private methods, but not abstract private methods.

An abstract class can provide an implementation, i.e. (public, protected, private) method bodies. An interface can just declare public method signatures. These methods have to be realized (in the form of method bodies) by classes implementing the interface.

There are three differences:

Interfaces can only declare public methods (i.e. no protected or package-private visible methods) and can not declare any fields
Subclasses can only extend at most one abstract class, but can implement any number of interfaces
The abstract class can also have implementations for some or all of the methods

I'm just going to address one point (mainly because the other questions have been addressed already):

"Where interface is being used we can make use of pure abstract class?"

In theory, you could. However, you will lose flexibility and loose coupling to some extent. It's far more preferable to code to interfaces and pass those around, especially in Inversion of Control (IoC) scenarios and from an integration point of view, as this allows far greater extensibility.

Since the question is about pure abstract classes then I'd say the answer is going to be related to inheritance and scope. It's something I've wondered myself many times and this is what I've come up with.

Obviously the features related to multiple inheritance have been answered previously so I won't go in to any of that. Scope is a big one though.

In an interface you can't define a member's access modifiers since they are implicitly public,...you are defining the public interface for it's eventual implementation. There's an important difference there since you can define a protected abstract member in a pure abstract class.

Inheriting from such a class definition would force the inheritor to implement the abstract member but scope it privately to consumers of the class (though it would have to be defined as protected so unless the class was marked as sealed further inheritors would have access).

In essence you can define a private interface using pure abstract classes. Whether that's a good idea is a different question altogether but one good use I've seen it used for is to enforce design patterns and standardize class designs.

HTH

You can use Interface for multiple inheritance, but you can't use abstract class for multiple inheritance.

All the methods in Interface is public by default, by in abstract class, only the methods which you've set as an abstract need to be declared public.

A class can implement multiple interfaces, but only extend from one class (abstract or otherwise). If you need to specify an interface, then you should use an interface, so that classes may implement multiple of your interfaces.