0

I have a simple Controller object that that implements Observer (i.e. it is the observer) which listens for events from a Mouse object that extends Observable (i.e. it is the observee).

So there can be multiple events in a Mouse object e.g. left click, scroll up, etc.

Now the Controller class implements the required method which is called every time any of the above events happen:

@Override
public void update(Observable o, Object arg)
{
    // Handle mouse event
}

So it is the arg parameter that I am having trouble deciding how to approach (this case I am working on is simple enough such that the o parameter is not a concern). What is a good way to distinguish between different mouse events without using typeof?

I.e. what parameter should I feed in the notifyObservers(Object arg) method in the Mouse observee class?

  • You should read about already built event subsystems, like the ones found in AWT, Swing, GWT and/or SWT... – Usagi Miyamoto Aug 29 '17 at 14:41
  • @UsagiMiyamoto I am actually using SWT but wanted to handle the event through an observer for practice... I guess I am overcomplicating it? –  Aug 29 '17 at 14:47
  • AFAIK SWT uses observer pattern: `Widget.addListener(eventType, listener)` adds a listener (observer) to the given event type of the widget (observable). – Usagi Miyamoto Aug 29 '17 at 14:53
  • 1
    Why not have different methods called when different events occur? – Sweeper Aug 29 '17 at 14:58
  • @Sweeper but doesn't that defeat the purpose of the design pattern -- the update(Observable o, Object arg) method is not used in that case, then depending on the event you have to call different methods, you don't just call a single method (notifyObservers) when an event happened... You have to differentiate between the events in the observable -> not sure if that is a good thing... –  Aug 29 '17 at 15:07

1 Answers1

0

Reading the comments it seems that you are using SWT -- SWT already implements event handlers via observer/observable callbacks.

What you are trying to do here is implement another layer of observer pattern on top of the already implemented observer pattern by SWT, which doesn't make much sense. But if you really wanted to do it for practice you might want to make several inner private classes to handle different events, e.g:

/**
* Controller.java
*/
import java.util.Observable;
import java.util.Observer;

public class Controller
{
/**
 * The controller's inner classes are to be notified of mouse events.
 */
public Controller(Mouse mouse)
{
    mouse.addObserver(new LeftClickObserver());
    mouse.addObserver(new ScrollUpObserver());
}

private class LeftClickObserver implements Observer
{

    @Override
    public void update(Observable o, Object arg)
    {
        // TODO Handle left clicks

    }

    // Other left click logic here
    // ...
}

private class ScrollUpObserver implements Observer
{

    @Override
    public void update(Observable o, Object arg)
    {
        // TODO Handle scroll up

    }

    // Other scroll up logic here
    // ...
}
}

Then you can call the notifyObservers(Object arg) method in the appropriate event in the Mouse class to trigger a callback to the Controller.

However as mentioned, you should instead make use of the existing SWT libraries to handle events, then separate the implementation of the event handling in the controller, and away from the view (as you are trying to do already). Here's a simple example of how to do that (assuming you have a Controller initialized somewhere in the Mouse class, and the appropriate methods in the Controller class):

final Button button = new Button(shell, SWT.PUSH);

button.addSelectionListener(new SelectionListener() {

  public void widgetSelected(SelectionEvent event) {
    controller.handleWidgetSelectedEvent(event); // controller decides what to do...
  }

  public void widgetDefaultSelected(SelectionEvent event) {
    controller.handleWidgetDefaultSelectedEvent(event); // controller decides what to do...
  }
});

Note that there are some versions of the MVC pattern where the View does much of the handling of the events, and/or the model; so really, it depends on your project. Probably handling the event at the view straight away is the easiest strategy.

ifma
  • 3,673
  • 4
  • 26
  • 38