开发者

Java interface and abstract class issue

开发者 https://www.devze.com 2022-12-30 04:18 出处:网络
I am reading the book -- Hadoop: The Definitive Guide In chapter 2 (Page 25), it is mentioned \"The new API favors abstract class over interfaces, since these are easier to evolve. For example, you c

I am reading the book -- Hadoop: The Definitive Guide

In chapter 2 (Page 25), it is mentioned "The new API favors abstract class over interfaces, since these are easier to evolve. For example, you can add a m开发者_如何学Cethod (with a default implementation) to an abstract class without breaking old implementations of the class". What does it mean (especially what means "breaking old implementations of the class")? Appreciate if anyone could show me a sample why from this perspective abstract class is better than interface?

thanks in advance, George


In the case of an interface, all methods that are defined in an interface must be implemented by a class that implements it.

Given the interface A

interface A {
    public void foo();
}

and a class B:

class B implements A {
}

it has to provide an implementation for the method defined in the interface:

class B implements A {
    @Override
    public void foo() {
        System.out.println("foo");
    }
}

Otherwise it's a compile-time error. Now take an abstract class with a default implementation of a method:

abstract class C {
    public void bar() {
        System.out.println("bar");
    }
}

where a class inheriting from this abstract class can look like this:

class D extends C { }

without an error. But it can also override the default method implementation if it's inclined to do so.

What the author was saying there: If your API isn't stable yet and you need to adapt interfaces (yes, abstract classes are also interfaces (in OOP-speak)), then an abstract class allows you to add things without breaking classes that are already there. However, this only holds true for non-abstract methods. If you add abstract methods, then they still need to be implemented in every derived class. But still, it can make your life easier if you have an API that is still evolving and already lots of stuff building on it.


If you add a method with a default implementation to an abstract class, nothing needs to change in any derived classes.

Alternatively, if you add a method to an interface, any classes implementing that interface need to implement the method - otherwise they will not compile.


Please also refer to the following guidelines from Eclipse Wiki

Evolving Java-based APIs

Adding an API method

Example 4 - Adding an API method

Can adding an API method to a class or interface break compatibility with existing Clients?

If the method is added to an interface which Clients may implement, then it is definitely a breaking change.

If the method is added to a class (interface) which Clients are not allowed to subclass (to implement), then it is not a breaking change.

However, if the method is added to a class which Clients may subclass, then the change should ordinarily be viewed as a breaking change. The reason for this harsh conclusion is because of the possibility that a Client's subclass already has its own implementation of a method by that name. Adding the API method to the superclass undercuts the Client's code since it would be sheer coincidence if the Client's existing method met the API contract of the newly added method. In practice, if the likelihood of this kind of name coincidence is sufficiently low, this kind of change is often treated as if it were non-breaking.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号