CODEWITHSUNDEEP
javadesign-patterns
Hanno Fietz
Hanno Fietz

Reputation: 31380

In Java, how should message producers identify themselves?

I have a queue of uniform message objects with multiple producers and a single consumer. The consumer is publishing the information and needs to be able to grant access based on the data's origin, so I want the producer send a suitable identifier along with the message. The producers themselves can't be responsible for the far side access restrictions.

The id should relate to the role of the producer in my application. I want to enforce that all producers have to define one and that a subclassed producer may choose to inherit or redefine it. The producer's class name would be a good approximation, but the property I want to identify is not really inherent in the class structure, it's rather something I define.

I could use reflection to find out the class name or maybe an interface name, but this smells of too much overhead. Also, I'm unsure what the appropriate property would be to look for.

As all producers subclass the same abstract parent class, I thought a good way would be to put a constant in there (or in an interface), but then I realised that in Java, a "constant" is really a "static final", which means I can't override it, so it doesn't work that way.

How would a more experienced Java programmer do this?

Upvotes: 3

Views: 258

Answers (4)

Eddie
Eddie

Reputation: 54421

Have your message object extend java.util.EventObject, and have the message producer set itself as the message source. Then, the message consumer can just call getSource() on the message and find out who sent it. Of course, this assumes that you trust the message producers to properly populate this field.

Upvotes: 0

Tom Hawtin - tackline
Tom Hawtin - tackline

Reputation: 147164

First I think you need to be clear about what you are trying to protect against. Are you protecting against malicious code? If not, then just use the queued object.

If you want to protect against malicious code, then the obvious route would be to distribute a enqueueing object for each producer. No other producer should be able to get hold of another enqueuer, so you can trust anything added to the queue.

Upvotes: 0

Paul Tomblin
Paul Tomblin

Reputation: 182782

Can the producer classes encapsulate the restrictions and "other things" in a method in themselves? That way each different producer could implement the appropriate method accordingly. Or just have that method return some sort of capability identifier, like an Enum of some sort.

If that won't work, like say if you want other consumers to do different things, then the obvious solution is to have a bunch of "if (object instanceof ....)" statements.

I've done it both ways, I can't say either is particularly "better" in all cases.

Upvotes: 1

Jason Cohen
Jason Cohen

Reputation: 83041

If there's a "type" that you need to identify, define an interface that forces a class to give you that type, then implement that interface everywhere.

Example:

public interface IHasType {
   public String getTypeId();
}

However, if the list of types is fixed, I would go one step further and make the type an Enum:

public enum MyType {
   TYPE_A, TYPE_B;
}

And then return this enum instead of a String.

Upvotes: 6

Related Questions