Зачем нужен второй интерфейс в определении класса, если первый интерфейс — наследник второго?

Question

[TiTreivan]

Ситуация следующая:
Класс

public final class NodeRef implements EntityRef, Serializable {...}

Интерфейс1
public interface EntityRef extends Serializable{}

Второй интерфейс я надеюсь в представлении не нуждается

Вопрос: Зачем прописывать Serializable если он и так наследуется EntityRef?

У меня только одно предположение - для удобства разработки, чтобы было сразу видно что объект можно сериализовать и наоборот. Но мне кажется что я что-то упускаю, как-то странна на мой взгляд такая конструкция.

Код из открытой ~CRM/framework. Ссылки на классы:
https://github.com/Alfresco/alfresco-community-rep...
https://github.com/Alfresco/alfresco-community-rep...

Comments

[Модератор]

Фрагменты кода надо размещать в виде текста и оборачивать тэгом code для корректного отображения. Удобно делать кнопкой </>
Это обязательно, см.п.3.8 Регламента.
Сюда же относится traceback, ввод и вывод в консоли и другая структурированная текстовая инфа.

[TiTreivan]

Зря я конечно тэг ООП поставил...

Answer 1

[Jacen11]

для удобства программиста, чтобы он сразу видел что NodeRef является Serializable и не нужно было куда то проваливаться. В плане исполнения кода ни на что не влияет. Можно и убрать спокойно, чисто личные предпочтения

Comments

[TiTreivan]

Отмечу данный ответ решением, так как он сходится с моими мыслями. Еще как правдоподобный вариант что это просто такое наследство и в процессе разработки этот момент пропустили, так как он ни на что не влияет. Спасибо вам, а также Александр Талалаев и Дмитрий Кинаш

Answer 2

[Дмитрий Кинаш]

Очень многие вещи в ИТ и не только можно описать фразой "так исторически сложилось".
Возможно сначала накинули интерфейсы, а потом сделали наследование интерфейсов. Или завтыкали...

Answer 3

[Александр Талалаев]

Serializable много может быть разных ещё, и чтобы не плодить классы для некоторых проверок используют маркер интерфейсы, которые с одной стороны не навредят, а другой стороны сократят код и позволят сделать проверки типов где нужно для различных операций при всяких там наследованиях. Погуглите Marker Interfaces

Там прямо в комментах написано:

/**
 * A marker interface for entity reference classes.
 * <p>
 * This is used primarily as a means of ensuring type safety in collections
 * of mixed type references.
 * 
 * @see org.alfresco.service.cmr.repository.NodeService#removeChild(NodeRef, NodeRef)
 * 
 * @author Derek Hulley
 */

Comments

[TiTreivan]

Вы кажется не совсем поняли, у меня был вопрос не в том зачем нужен "EntityRef", а в том зачем там (в классе NodeRef) "Serializable" если он и так есть в "EntityRef"

[Александр Талалаев]

TiTreivan, может автор исходил из "тру безопасного" подхода. Ему в коде нужно было проверять маркер Serializable, а EntityRef мог бы поменяться и потерять внутри себя его. Там в целом к сожалению историю кода не получилось посмотреть.
Мое предположение что изначально было просто implements EntityRef, а потом для лучшей читабельности и прозрачности чего за класс отдельно добавили Serializable. А из EntityRef не убрали потому что не мешает(может забыли), а может оставили чтобы не появились новые баги, вдруг где-то что-то его цепляет. Хотя там легко по коду найти что и где. Впрочем, может есть модули и прочие зависимости.

Answer 4

[Hemul GM]

Потому что объект не будет считаться поддерживаемым родительский интерфейс одного из интерфейсов.

Т.е. если объекту не указать Serializable и спросить, поддерживает ли он Serializable, то он скажет, что нет. Потому что он поддерживает только EntityRef, а не Serializable.

Не знаю точно как в PHP, но так работает в некоторых языках. Т.е. наследование интерфейсов - это просто упрощение перечисления определений интерфейса.

Comments

[TiTreivan]

Как минимум на принадлежность такой класс реагирует нормально:

NodeRef node = new NodeRef("uuid")
If (node instanceof Serializable ) { // = true
}

[Hemul GM]

TiTreivan, в некоторых языках это так не работает)