Уникальный идентификатор для каждой реализации интерфейса

Question

У меня есть частный интерфейс пакета под названием AbstractServer, который предлагает три метода: start(), stop() и init().

Для каждого нового сервера я реализую интерфейс и переопределяю эти методы,После этого я регистрирую этот новый сервер в своем общедоступном ServerManager -классе, который собирает все серверы в HashMap и вызывает их открытые методы в определенном порядке.

Итак, откуда-то запускаются все зарегистрированные серверыостальное в коде просто выглядит так:

ServerManager.INSTANCE.startServers();

Проблема, с которой я сейчас сталкиваюсь, заключается в том, что я хочу иметь возможность удалить сервер с карты ServerManager.

Моя идея заключалась в том, чтобы ввести в интерфейс поле public static final String IDENTIFIER и использовать его в качестве ключей в HashMap.Таким образом, чтобы удалить сервер из ServerManager, я бы написал:

ServerManager.INSTANCE.removeServer(HttpServer.IDENTIFIER);

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

Я также не могу использовать обычный метод (нестатический), потому что конструктор реализаций сервера будет закрытым для пакета.

В качестве альтернативы, яподумал об использовании Class реализаций в качестве ключей в HashMap, чтобы я мог написать что-то вроде этого:

ServerManager.INSTANCE.removeServer(HttpServer.class);

Есть мысли по этому поводу?

Answer 1

Если вы знаете, что когда-либо будет не более одного экземпляра для каждого реализующего класса, то использование объекта Class в качестве ключа является довольно естественным решением.

Если нет, то ясно, чтоИдентификаторы должны быть привязаны к экземпляру, а не к классу.

Answer 2

Как насчет определения перечисления ServerIdentifier для всех возможных типов серверов и в интерфейсе:

ServerIdentifier getServerIdentifier();

Тогда ваша карта может быть Map<ServerIdentifier, List<AbstractServer>>, и вы даже сможете управлять несколькими экземплярами одного типа сервера ...

Преимущество по сравнению с использованием Class-Object в качестве ключа было бы более естественным способом работы с типами серверов, поскольку вы можете использовать enum и не нужно сравнивать Class-Objects ...