Clever Geek Handbook

Does Java plan on default (java8) Substitute method for abstract class?

Does Java have what default method

to replace with Abstract Class

? I couldn't find a real case of using the default method instead of the abstract one?

+2


source to share


4 answers


Default methods cannot replace abstract classes, as abstract classes can (and often) have fields. Interfaces can only contain behavior, not state, which is unlikely to change in the future, since multiple state inheritance in Java is viewed (rightly or wrongly) as evil.

They can also have methods final

, which is completely different, which you cannot simulate with methods default

.



If anything, interfaces with default methods resemble traits , not abstract classes, but the match is not perfect. Using interfaces as features is something that needs to be done very carefully and with knowledge of the constraints they face. (For example, any implementing class can override a method default

, potentially destroying it.)

More on this here .

+5


source


There are no plans that you can learn from comparing the intentions already documented that differ from the consequences of such a plan:

Stuart Marks writes :

The main goal is to allow the development of the interface, that is, the addition of new methods. If a new method is added to the interface, the existing classes that implement the interface will lack implementation, which would be incompatible. To be compatible, the implementation must come from somewhere, so it is provided by default.

...

The main purpose of a Java interface is to specify a contract that any class can implement without changing its position in the class hierarchy.It is true that before Java 8, interfaces were purely abstract. However, this is not an essential property of interfaces. Even when default methods are enabled, the interface at its heart still indicates the contract for the implementation class. An implementation class can override default methods, so the class still has complete control over its implementation. (Note that default methods cannot be final .)



and Brian Goetz writes :

A close reason for adding default methods to interfaces was to support interface evolution, ...

Here are some use cases that fit well with the design goals:

  • Development of the interface. Here we are adding a new method to an existing interface that has a reasonable default implementation in terms of the existing methods of that interface. An example would be adding a method forEach

    to Collection

    , where the default implementation is written in terms of the method iterator()

    .

  • "Optional" methods. Here, the interface designer says, "Developers shouldn't implement this method if they want to live with the functionality limitations that it entails." For example, Iterator.remove

    got the default value, which produces UnsupportedOperationException

    ; since the vast majority of implementations Iterator

    have this behavior anyway, the default makes this method essentially optional. (If the behavior AbstractCollection

    was expressed as the default on Collection

    , we could do the same for mutative methods.)

  • Convenient methods. These are methods that, strictly for convenience, are again usually implemented in terms of non-standard methods for the class. The method logger()

    in your first example is a reasonable illustration of this.

  • Combinators. These are compositional methods that create new instances of the interface based on the current instance. For example, methods Predicate.and()

    or Comparator.thenComparing()

    are examples of combinators.

Note that they are not intended for the main domain of abstract classes, for example to provide a skeleton implementation. Apart from the technical differences, abstract classes are semantically different as they carry design decisions on how to implement functionality whose interface, even with methods, default

shouldn't. For example. a well-known example is an interface List

for which there are two fundamentally different abstract classes AbstractList

and AbstractSequentialList

, and the choice of subclasses or implementation of a List

completely different one should not be excluded by the interface. Thus, an interface List

defines a contract and cannot be a replacement for an abstract class that provides a concrete base implementation.

+8


source


Other answers and links to additional materials already adequately reflect the technical differences between interfaces and abstract classes. What has not been well described is that one has to be used over the other.

Consider two different ways to use a class or interface in Java, both as a caller and as a subclass. The caller has a reference to the object and can call methods public

and access public

from that reference. The subclassifier can also access, invoke, and override the members of the protected

superclass. Classes can have members protected

, but interfaces cannot.

As a rule, a general question arises: now we have default methods, why do we need abstract classes? The default method is part of what the interface exposes to subscribers. The method protected

for the class is not available to callers; it is only available for subclasses. Thus, if you want to share an implementation with subclasses, use a class (or abstract class) and define members and fields protected

.

The mechanism protected

allows a class to interact with subclasses other than how it interacts with callers.

But the OP is asking the opposite question: why use default methods, preferring abstract classes? In a situation where you do have a choice (i.e. your abstraction does not require state or protected methods or any things that abstract classes don't have for those interfaces), interfaces with standard methods are much less constraining than abstract classes, you can inherit only one class; you can inherit many interfaces. Thus, interfaces with default methods can behave like stateless or mixinless attributes, allowing behavior to be inherited from multiple interfaces.

Given that interfaces and abstract classes are used for different purposes, there is no plan for removing or replacing anything.

+6


source


One of the reasons default methods were introduced in interfaces was to add new methods to JDK interfaces.

Without this functionality, after a class has been compiled with a specific version of an interface, no new methods can be added to that interface. Using the default methods in interfaces, interfaces can be changed.

+5


source






More articles:


All Articles