1

I am using a class (let us call it ClientImpl) which listens to a socket for messages and then updates a listener to let ClientImpl know that a message have arrived to the socket. The listener is not implemented inside ClientImpl, but is passed from the classes using ClientImpl. Let us call my class ClientUser to make the problem easier to discuss. An important thing to note is that the ClientUser has the ownership of the listener.

So to the problem: when a message arrives I want to process it and store it to be able to read later. Since I work with a framework I cannot simply store it in a file. It has to be stored in the heap to be read later.

So the question, "Is it considered bad practice to have a container (array, Collection, ...) inside a listener?". The listener is very specific and will not be used for any other purpose. Else, are there any good options to avoid this?

I have tried to think of some options, but all these would be complicated to implement (read this as: add complexity to the code.). These ways can for example be to start a thread which continously checks for updates in a listener buffer or to make the ClientUser an Observer. None of these ways are very appealing. Another way would be to inject a dependency to an external Collection. I do not like either because it would create shared responsibility to handle the Collection. This is will likely cause concurrency issues.

  • Then what about when you receive a new message to forward to the standard event bus of your framework, if he has one of course. Then you can have two listeners : one that log it, and the other that execute the related process. I have trouble imagine how you cannot store it in a File to be honest without knowing the technology impled. – Walfrat Apr 27 '17 at 11:40
  • Could you add some ideas why you believe that having a container inside the listener would be bad? Do you have concurrency issues? Would making the container thread-safe cause performance issues? From the design-patterns' point of view, listener is just an object as any other objects - the point is that it is decoupled from the object which generates the events. – Honza Zidek Apr 28 '17 at 7:50
  • @HonzaZidek The feeling I get about a listener would be that it should be lightweight and a container inside a listener would not make it so. As you say it might not be a big issue though. It is more about style and the other ways are not so stylish either. Anyway I am not 100% sure how much data that will be transferred, but there is a risk of performance degradation in case the container is thread-safe. I have to make some functions thread-safe, but I want to minimize the interface to the container. Anyway having a container in a listener will work. I was just looking for other ideas.Thanks! – patrik Apr 28 '17 at 8:42
  • Patrik, could you please state any arguments (yours or quoted) for that "a listener should be lightweight"? – Honza Zidek Apr 28 '17 at 8:46
  • @HonzaZidek Nope, as I said it is more of a feeling, like that a listener should be easy to setup and tear down. If a connection is started and a listener to the interface is set up (and the listener is torn down when a connection closes), then this will take more time in case the listener contains reference to a lot of data. This is Java though so the problem should not be as complicated as in for example c++. I do however not object to your opinions above. Actually I am more inclined to just add a container inside the listener for simplicity (and since I not see any practical issues). – patrik Apr 28 '17 at 8:52
3

The main point of the Listener (or Observer) design pattern is to decouple the object generating events from the object reacting to the events (the listener / observer). I have not heard anything about that the listener should be lightweight.

I recommend just using the common sense. Prefer simplicity over premature optimization.

If you have concurrency issues, simply make the container thread-safe.

If you have performance issues, start thinking about optimization. But optimize what really is the bottleneck. Just keeping the container most probably will not be the bottleneck. Most probably it would be the message processing which will take the most time. Then introduce a variant of the producer-consumer pattern - one thread just feeds a queue (this might be your listener), another thread (or thread pool) takes the messages out of the queue and processes them.

I cannot see just having the container in the listener as a big issue in general, unless there is a specific reason in a specific case.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.