В Java, как производители сообщений должны идентифицировать себя?

Question

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

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

Я мог бы использовать отражение, чтобы узнать имя класса или, может быть, имя интерфейса, но это пахнет слишком много накладных расходов. Кроме того, я не уверен, что будет искать подходящее свойство.

Поскольку все производители наследуют один и тот же абстрактный родительский класс, я подумал, что хорошим способом было бы поместить туда константу (или в интерфейс), но затем я понял, что в Java «константа» действительно является «статической» final ", что означает, что я не могу переопределить его, поэтому он не работает таким образом.

Как бы это сделал более опытный программист на Java?

Answer 1

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

Пример:

public interface IHasType {
   public String getTypeId();
}

Однако, если список типов фиксирован, я бы пошел еще дальше и сделал бы тип Enum:

public enum MyType {
   TYPE_A, TYPE_B;
}

А затем верните это enum вместо String.

Answer 2

Могут ли классы производителя заключать в себе ограничения и "другие вещи" в методе? Таким образом, каждый отдельный производитель может реализовать соответствующий метод соответствующим образом. Или просто попросите этот метод вернуть какой-то идентификатор возможности, например, Enum какого-то рода.

Если это не сработает, как, например, если вы хотите, чтобы другие потребители делали разные вещи, тогда очевидное решение состоит в том, чтобы иметь кучу операторов if (object instanceof ....).

Я сделал это обоими способами, я не могу сказать, что во всех случаях "особенно" лучше.

Answer 3

Сделайте так, чтобы ваш объект сообщения расширял java.util.EventObject, и чтобы источник сообщения сам устанавливал себя в качестве источника сообщения. Затем потребитель сообщения может просто вызвать getSource () для сообщения и выяснить, кто его отправил. Конечно, это предполагает, что вы доверяете производителям сообщений правильно заполнить это поле.

Answer 4

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

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