Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Instead of each <code>Listener</code> having specific methods for every event type you can send it, change the interface to accept a generic <code>Event</code> class. You can then subclass <code>Event</code> to specific subtypes if you need, or have it contain state such as <code>double intensity</code>.</p> <p>TigerListener and ElephentListener then become</p> <pre><code>interface TigerListener { void listen(Event event); } </code></pre> <p>In fact, you can then further refactor this interface into a plain <code>Listener</code>:</p> <pre><code>interface Listener { void listen(Event event); } </code></pre> <p>Your <code>Listener</code> implementations can then contain the logic that they need for the specific events they care about</p> <pre><code>class TigerListener implements Listener { @Overrides void listen(Event event) { if (event instanceof GrowlEvent) { //handle growl... } else if (event instance of MeowEvent) { //handle meow } //we don't care about any other types of Events } } class ElephentListener { @Overrides void listen(Event event) { if (event instanceof StompEvent) { StompEvent stomp = (StompEvent) event; if ("north".equals(stomp.getLocation()) &amp;&amp; stomp.getDistance() &gt; 10) { ... } } } } </code></pre> <p>The key relationship between the subscriber and the publisher is that the publisher can send events to the subscribers, it isn't necessarily that it can send it certain types of events - this type of refactoring pushes that logic from the interface down into the specific implementations.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload