Способы добавления новых методов в интерфейс, не влияющие на существующие подклассы этого интерфейса в java6?

Question

Способы добавления новых методов в интерфейс, не влияющие на существующие подклассы этого интерфейса в java6?

1

Некоторое время назад я столкнулся с ситуацией, чтобы добавить метод в один интерфейс, который уже использовался классами 15+. Во время реализации старые классы не нужны для этого нового метода, но этот новый метод требуется для других новых классов. Здесь нужно учитывать, что этот новый метод является необязательным для старых классов и является обязательным для вновь развивающихся классов. Каковы способы решения этой проблемы?

Я решил так: я создал новый интерфейс и объявил метод в этом интерфейсе и реализовал его со старым интерфейсом в новых классах и сделаю то же самое для других старых классов, если им нужен этот новый метод.

Java8, у нас есть "по умолчанию для обработки подобных ситуаций", но каковы другие способы решения этого типа ситуации в более старых версиях Java?

karthick Sundaram 28 сен. 2014, в 17:52

Источник

Теги:

java

1 ответ

Ещё вопросы

JB Nizet · Accepted Answer · 2014-09-28T12-59-00.000Z

Старые версии Java не имели возможности решить эту проблему. Вот почему методы по умолчанию были введены в Java 8.

Обратите внимание, что JVM с радостью загрузит класс, реализующий интерфейс, даже если он фактически не реализует все его методы (то есть, если он был скомпилирован до добавления новых методов): во время выполнения вы будете иметь только исключение при вызове одного из эти нереализованные методы.

Вот почему старые драйверы JDBC по-прежнему работают в новых JRE, хотя они не реализуют все новые методы JDBC... если, конечно, вы не называете один из этих новых методов.

Да. Я согласен. Более старые версии не имеют решения напрямую, и если мы запустим класс с уже скомпилированным классом, он будет работать без ошибок даже после добавления нового метода в этот интерфейс, но мы не можем идти дальше с этой реализацией. Это может произойти сбой во время регрессионного или интеграционного тестирования, или из-за того, что подклассы расширяют этот класс, и они должны быть скомпилированы в виде ситуации и т. Д. Есть ли обходной путь, подобный тому, что я упоминал?