Anything which involves an interface with 120 methods doesn’t count as ultra-simple in my book. Not to say that a massive visitor like that is never the best solution - compilers string to mind as an example.
What about having an interface with an integer, representing the packet upcode, and then choosing the way to handle it with a switch, depending on the upcode?
I doubt I’ll actually need 120 upcodes 
Seems reasonable. However if all your classes need to provide an upcode then a method in the base class is probably cleaner than an interface.
Why would it be cleaner than an interface? :o
The only reason I see, is to provide a default upcode, and method.
Forget about this craziness and just send some custom text or JSON. Like Riven says, I’d keep it simple at first.
An enum could be used, but you would be sending an extra int over the network for no real reason. Note this is an extra overhead of 1 or 2 bytes, so not a big deal. However, this is easily avoided with the solutions in my post above.
The “problem” remains. Instead of 120 ‘if (object instanceof Xxx)’ you would have 120 ‘if (string.equals(“Xxx”))’.
Anyway, I doubt Mads actually has 120 objects and is just annoyed at how the code looks with a bunch of instanceofs. There is no bottleneck.
I bet you missed how I talked about reflection and methods.
While I agree learning about how networking works is a good idea, I don’t think sending strings and doing reflection simpler. “if instanceof” is already about as simple as it gets.
The cost of 5000 method calls or 5000 hash lookups per frame is highly unlikely to be an issue. Maybe if they were JNI calls, it’d matter.
True, though of course if you were, say, trying to get it running on Android, you’d be seriously thinking about 5000 hashmap lookups being very slow. There’s method to my madness. Turns out not everything is a 2.6Ghz i7 these days…!
Cas
Correct, but there will eventually come a time where I have too many objects, to just put if-statements.
I also have made networking before using a text-based protocol, and blocking I/O, but that is just a cheap solution (…or so I think).
Hence my technique Which is still the simplest to understand, neatest, easiest to not get wrong, and fastest so far…
Cas
Again, I disagree with part of this. Your method would be faster, but it requires altering both the objects being worked on and the event handling class. With my solution (and it’s similar alternatives) you only code the event handling bit.
With mine you only need to understand two parts: adding handlers and invoking them on an object. With yours you need to understand adding the interface stub to your objects, the double-dispatch mechanism and building your event handling class.
Needing to write less code and having less concepts to learn makes mine (in my opinion) simpler (but yes, also slower).
It does rather depend on a whole load of other factors we’re not privy to tho’ eh? I mean, if I could alter the classes, I would, in a shot; if I couldn’t, the Map method’s best. Etc.
Cas
I’d say the only factor it depends on is performance (and I’d argue only if you really need the performance).
Something that just hit me is that with the map method it’s implementation is entirely separate to the code using it. It could even be provided from an external jar of utility classes. Where as with the visitor pattern you have to bake this yourself directly into your code and your design. That’s a big difference in terms of simplicity.