Very clever jars on from mentioning instanceof alone. And they put, and they put minuses, not bothering to explain themselves, to set Nubasa on the right path.
You can solve your problem in the style of work-OOP using the template "visitor" (or "visitor" in Latin).
We need a hierarchy of objects with a special method that accepts a visitor (also specially sharpened for this hierarchy).
But since we are going to send something like int (or Integer, right?), Which is not expandable, let's agree to transfer our data in a special Message object (this is usually what everyone-carrier objects are called - messages, messages).
For each class of data to be sent will be its own Message class.
// глава херархии сообщений public abstract class Message<T> implements Serializable { // данные, которые передаются сообщением protected T data; public Message(T data) { this.data = data; } public T getData() { return data; } // Каждый конкретный класс должен переопределить этот метод по-своему public abstract void accept(MessageVisitor visitor); } public class IntegerMessage extends Message<Integer> { public IntegerMessage(Integer data) { super(data); } @Override public void accept(MessageVisitor visitor) { visitor.visit(this); } } public class StringMessage extends Message<String> { public StringMessage(String data) { super(data); } @Override public void accept(MessageVisitor visitor) { visitor.visit(this); } } ...
Now it may seem that they all override accept equally. But in fact it will be like that. We will define who is a visitor to MessageVisitor and, I hope, everything will become clear.
public interface MessageVisitor { void visit(IntegerMessage msg); void visit(StringMessage msg); ... }
It turns out that for each class of the Message hierarchy, the visitor has his own overloaded method visit .
So they are not so identical, these are our accept s. This is very important.
Some basis is procured. Let's see how sending and receiving data may look like.
Sending:
Integer integer = ... String string = ... ... send(new IntegerMessage(integer)); send(new StringMessage(string));
It's all clear. Wrap everything in a message of the appropriate class.
The recipient must send the received messages to the visitor, who will extract and process the data according to the class of the message and data.
Message msg = receive(); msg.accept(new MessageVisitor() { @Override void visit(IntegerMessage msg) { Integer data = msg.getData(); System.out.println("Integer: " + data); } @Override void visit(StringMessage msg) { String data = msg.getData(); System.out.println("String: " + data); } ... });
The example uses an anonymous class for brevity, but nothing prevents you from using any class that implements MessageVisitor .
msg.accept will call the overloaded visit for a valid msg class.
In this simple way, the data gets into the necessary handler without any instanceof . And even casting is not needed = O
There is now no reason for indiscretions to hate, now they are satisfied)
Many bukav however. It would be better just clicked a minus.
For the development of horizons can google about dispatching in the PLO.
