Program development language features I wanted - the "object-oriented" - the "degradation"

Start with a start example, the following is the code (remove the comment section) jdk1.7 iterators interface:


public interface Iterator<E> {
    boolean hasNext();
    E next();
    void remove();
}


Oil Stick development program who do not like the remove method interface, may be due to:

  1. We realize for themselves when Iterator interface, do not need this basic method, but we have to @Override it, then we would usually write a single line throw new UnsupportedOperationException () method directly in the body; to get it.
  2. The performance of this method is usually not very good, ArrayList iterator frequently do this far better than the performance of the operation to create a new ArrayList object.

 

Perhaps, this does not remove the interface method would be better, but this interface has happened, to maintain upward compatibility, then it is not possible to modify jdk remove this method.

In case we do not change the original class, how to "degradation" out of the original class methods?

 

When our own iterator class needs, whether we can directly use their own interface instead of using jdk that comes with it interfaces:


public interface MyIterator<E> {
    boolean hasNext();
    E next();
}


This of course is possible, but that would not fit directly into the jdk that comes with a set of framework.

So we usually do:


class MyIteratorImp implements Iterator<Object> {
    private Iterator<Object> itr;
    public MyIteratorImp(Iterator<Object> itr){
        this.itr = itr;
    }
    public boolean hasNext() {
        return itr.hasNext();
    }
    public Object next() {
        return itr.next();
    }
    public void remove() {
       throw new UnsupportedOperationException();
    }
}


Here we do not need to remove method, but we have to realize it, because this is the Java syntax (this will make people realize how much a bit uncomfortable).

We very much hope that might achieve such an interface:


interface MyIterator <T> extends Iterator < T> {
    Do this method: void Remove ();
}


In this way, we do not need to override the time to realize their iterator remove method, but it is also achieved jdk standard interface Iterator, so basically met our requirements.

But unfortunately, we do not like this syntax.

 

Some people may think it is possible (using the abstract class):


abstract class MyIteratorImp<T> implements Iterator<T> {
    public void remove() {
        throw new UnsupportedOperationException();
    }
}


But abstract classes relative to the interface there is a drawback: after multiple inheritance is not supported in some languages ​​(such as Java), we inherited abstract class will not inherit the possibility of other classes.

 

Perhaps we can consider implementing in a language in a "degradation" of grammar, so that you can:

  1. The method may be removed from an interface or a portion of a class implementing the interface or class
  2. In certain removed portion of the object.

In some dynamically typed languages ​​have such a feature, such as Groovy and Python.

Point 1 above does not actually have to be in some cases (but up to now I have never seen a statically typed language has such a feature), but the second point is necessarily a dynamic language for the job (because of dynamic languages ​​in order to achieve less than running, we can not determine what the object is created when, or even create object code that we do not know where, we just use the object).

 

After the evolution of Java to Java8, with a good choice: the interface default implementation.

Actually implements the Iterator interface is already in Jdk1.8 this appearance:


public interface Iterator<E> {
    boolean hasNext();
    E next();
    default void remove() {
        throw new UnsupportedOperationException("remove");
    }
    default void forEachRemaining(Consumer<? super E> action) {
        Objects.requireNonNull(action);
        while (hasNext())
            action.accept(next());
    }
}


The default interface to achieve the "Interface" largely become "abstract class" --Java originally did not support multiple inheritance at the beginning Java8 has to some extent broken.

From a design point of view mode, degraded the ability of the class or interface seems to violate "Richter substitution principle", but since the beginning is a mistake, and degraded the ability to erase "the crime of fathers" to a certain extent, then sometimes not too principled a.

Reproduced in: https: //www.cnblogs.com/naturemickey/p/3855403.html

Guess you like

Origin blog.csdn.net/weixin_34120274/article/details/93461842