Re: Design decision for a game

On Thu, 22 May 2008 17:44:58 -0700, Tom Anderson <twic@xxxxxxxxxxxxxxx> wrote:

On Thu, 22 May 2008, Peter Duniho wrote:

I think ultimately I'd go with _some_ variation on this last approach (that is, the one where the Rule supports listeners for events separated into appropriate categories, whether in the same interface or in two or more), but any of the above would probably work (including what you posted, if you really want to do it that way).

I'm thinking having a list of listeners on each Rule is overkill - are there ever cases where you'd want to listen to one Rule but not others?

Hard to say. I'm not the OP and so it's difficult for me to comment what must or must not be characteristic of his ultimate implementation. But I'm not sure I see much of a downside. Especially if the Rule implementations all share a common implementation, where the actual listener list is maintained (inasmuch as duplicated implementations is at least part of the potential redundancy here, that would be addressed in that way).

Alternatively, if there are to be different listener interfaces for each Rule (in addition to some base interface, presumably from which each of the specific Rule interfaces inherit), then obviously each Rule instance would have different listener interfaces subscribed (even if they are all implemented by the same object). Depending on what notifications are required and whether there's a good way to generalize them so that a single RuleListener interface can apply to all Rule implementations, this may also argue in favor of per-Rule listener lists.

We don't really know enough about the larger problem to know whether this latter design requirement applies. (Or, at least, I don't...maybe you know more about this particular card game).

How about putting the listeners on the House, and having the rule call a method on the House which gets it to dispatch the event? You might even want the listeners to be on the Game object.

I don't see anything wrong with that per se. It's just that we don't have enough real information about the game and the intended implementation to know for sure if that's appropriate. I also think that even if it's overkill, conceptually it makes more sense to me for a Rule to implement the RuleListener list.

If there was some concern that multiple objects would wind up all subscribing to the same large set of Rule instances, one could implement a delegation scheme, in which the House or Engine (to use the OP's name for what I called "Game") also maintains a list of RuleListeners to which all of the end-client objects subscribe, but then subscribes to each Rule's list and simply forwards to its own list. This would maintain the "the Rule implements the RuleListener list" idea, but allowing for the optimization of delegation to avoid an overly repetitive subscription scheme. (It'd be basically the same as the House/Engine class exposing an API for Rules to call in order to dispatch an event as you suggest, but the API would itself just be the RuleListener interface, delegated through the House/Engine class).

In that way, the individual Rule implementations would all still provide for the possibility of having multiple listeners, and ultimately the RuleListener dispatching would originate with those classes, but the issue of redundancy that you are talking about would be addresed.

Pete
.

Relevant Pages

  • Re: PHP5 Bug?? extended abstract type enforcement
    ... >> Abstract classes can never be instantiated, only implementations can. ... >> wrong interface, ... from which lists are derived. ...
    (comp.lang.php)
  • Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
    ... Listener binds to genetlink using its real pid. ... one needs to get this exit data and calls a genetlink_unicast to each one that does need it. ... its pid to be stored in various per-cpu lists of listeners. ...
    (Linux-Kernel)
  • Re: variable parameter into Inner class
    ... have nowhere to put a second similar listener. ... It pollutes the public interface of a significant class. ... provide a simulated listener implementation only because it *used* to be ...
    (comp.lang.java.programmer)
  • Re: Best MP3 Player for Musical and Opera Buffs
    ... > listener, we have special needs, because many of us like to have an ... > have entire operas on my mp3 player - think the entire Ring Cycle) ... disc with a mock up of the on-device interface as well, ... Mine's tiny (just large enough to hold a AA battery - and battery life seems ...
    (rec.arts.theatre.musicals)
  • Re: Reasons to use Adapters, not Listeners
    ... makes things messy if the listener is a separate class. ... The typical solution to this is to use an inner class ... adapter or not, as you wish. ... interface seems to be risky, not only if Sun does it, but also if it ...
    (comp.lang.java.programmer)