界面可以随时间演变吗？

从灵活性的角度来看,接口非常棒.但万一,大量客户端使用接口.在保持旧的mehtod完整性的同时向接口添加新方法将破坏所有客户端的代码,因为客户端中不会出现新方法.如下所示:

public interface CustomInterface {

    public void method1();

}

public class CustomImplementation implements CustomInterface {

    @Override
    public void method1() {
        System.out.println("This is method1");
    }
}

如果在某个时间点,我们在此接口中添加另一个方法,所有客户端的代码都会中断.

public interface CustomInterface {

    public void method1();

    public void method2();

}

为避免这种情况,我们必须在所有客户端代码中明确实现新方法.

所以我认为接口和这个场景如下:

曾经写过的界面就像雕刻在石头上.他们很少被认为,并且有望改变.如果他们这样做,他们会花费巨大的成本(重写整个代码),程序员应该为此做好准备.

继续上述观点,是否有可能编写经得起时间考验的接口？

如何在未来期望其他功能的接口中处理这种情况？这预示着所有客户都被绑定的合同变更.

编辑:Default方法确实是Java接口的一个很好的补充,很多人在他们的答案中提到过.但我的问题更多的是在代码设计的背景下.如何在客户端上强制实现方法是接口的固有特性.但是,接口和客户端之间的这种合同似乎很脆弱,因为功能最终会发展.

1> Eran..：

---

Java 8中以接口中的默认方法的形式引入了该问题的一种解决方案.它允许在不破坏现有代码的情况下向现有Java SE接口添加新方法,因为它为所有新方法提供了默认实现.

例如,Iterable广泛使用的接口(它是接口的超级Collection接口)添加了两个新的默认方法 - default void forEach(Consumer action)和default Spliterator spliterator().

2> Shadab Faiz..：

---

public interface CustomInterface {
    public void method1();
}

public interface CustomInterface2 extends CustomInterface {
    public void meathod2();
}

除了默认方法之外,您可以使用继承属性,如上所示,新接口将具有所有先前方法以及新方法,并在您所需的情况下使用此接口.

---

好吧在你的方法中,假设我们有25个实现interface1的类AZ,并且由于某种原因你必须添加只能由5个类AE使用的新方法,但不能使用类的其余部分.所以你的方法你有在所有类AZ中实现meathod2,没有选项.但是通过使用继承,你只能在必需的类中进行更改,而不是在其他类中进行更改.这样你最终会节省大量的时间.

3> Petre Popesc..：

---

Java 8引入了方法的默认实现.这些实现驻留在接口中.如果在已经由许多类实现的接口中创建具有默认实现的新方法,则不需要修改所有类,而只需要修改我们希望为新定义的方法具有不同实现的类.默认一个.

现在,旧的Java版本呢？在这里,我们可以有另一个扩展第一个的接口.之后,我们想要实现新声明的方法的类将被更改为实现新接口.如下所示.

public interface IFirst {
    void method1();
}

public class ClassOne implements IFirst() {
    public void method1();
}

public class ClassTwo implements IFirst() {
    public void method1();
}

现在,我们想要method2()声明,但它应该只能通过实现ClassOne.

public interface ISecond extends iFirst {
    void method2();
}

public class ClassOne implements ISecond() {
    public void method1();
    public void method2();
}

public class ClassTwo implements IFirst() {
    public void method1();
}

在大多数情况下,这种方法都可以,但它也有缺点.例如,我们想要method3()(并且只有那个)ClassTwo.我们需要一个新的界面IThird.如果稍后我们想要添加method4()应该由ClassOne和ClassTwo实现,我们将需要修改(但不是ClassThree那样implemented IFirst)我们将需要更改两者ISecond和IThird.

在编程方面,很少有"神奇的子弹".在接口的情况下,最好不要更改.在现实生活中并非总是如此.这就是为什么建议接口只提供"合同"(必须具有的功能),并在可能的情况下使用抽象类.

4> keshlam..：

---

未来的接口更改不应该破坏任何已经工作的东西 - 如果有的话,它是一个不同的接口.(它可能会弃用某些东西,并且在弃用之后需要一个完整的循环,可以接受的是,抛出未实现的异常是可以接受的.)

要向界面添加内容,最简洁的答案是从中派生新界面.这将允许使用实现新行为的对象和期望旧代码的代码,同时允许用户适当地声明和/或类型转换以访问新功能.它有点烦人,因为它可能需要instanceof测试,但它是最强大的方法,它是许多行业标准中你会看到的方法.