Law of Demeter causing subclassing indecision and conflict with Single Responsibility

Question

This is my situation:

I have a class called CueList, which is basically a wrapper around ArrayList. I have another class called TimeTicker that alerts all the Tickable (interface) in its list that a certain amount of time has passed. Since I need to tick all of the items in CueList, but I don't want to violate DRY by keeping a copy of all of the CueList items in the TimeTickable class as well (which would make a nightmare when I want to delete a Cue), my immediate instinct was to make CueList a Tickable and have it pass on the "tick" message to all of its items.

This seems to violate the Single Responsibility principle, which says that CueList should not worry about both keeping track of all the cues AND Ticking them.

So what I did was create a CueManager class that is itself Tickable and links everything up (and ticks all of the CueList elements).

But now, because of the law of demeter, I have a bunch of duplicate methods in the CueManager that just mirror the TimeTicker and CueList class.

Doesn't that mean that the CueManager class has multiple reasons to change? Doesn't that mean it violates the Single Responsibility principle.

Also, since most of the methods in CueManager mirror TimeTicker and CueList, doesn't that really mean that it IS a TimeTicker and CueList. Therefor shouldn't it INHERIT from CueList and TimeTicker! (Obviously you can't do multiple inheritance in Java, but I feel like it sort of makes sense to Inherit from CueList, but then that would violate Single Responsibility)

So in summary:

Law of Demeter makes me make a bunch of methods that merror two other classes, but that makes me think that it really should just inherit from both of those classes, but that would mean that one class handles multiple responsibilities (even if it is through its superclass).

Answer 1

CueList is an ArrayList (or at the very least can expose some similar interface such as Collection, List or Iterable). All items in that ArrayList are, ostensibly, Tickables. TimeTicker doesn't, and shouldn't, care that its items are in a CueList specifically, nor should it care that the items in the list it acts on are anything but Tickables. By the same token, CueList should have no knowledge of TimeTicker; it is of no bearing to CueList's basic functionality AFAICT. This is the essence of the Least Knowledge Principle.

So, make TimeTicker act on an injected ArrayList<Tickable> (or a Collection<Tickable> or a List<Tickable> or an Iterable<Tickable>, whatever interface exposes the methods you use to spin through this list) and pass in CueList as this dependency, via some class that already has to know about both the list and the ticker.

Answer 2

Sounds like the Observer pattern where it is normal that the subject (TimeTicker) keeps a list of its observers (Tickables) so it can update them on an event. Your Tickable interface can define an UnRegister() method which you can call when it is removed from any list.

class TickableItem
{
    TimeTicker Subject;

    void UnRegister()
    {
        this.Subject.UnRegister(this);
    }

    void Register(TimeTicker subject) { ... }

    void OnTick() { ... }
}

The benefit of this approach is that your CueList doesn't need to know who the TimeTicker is. It's tickable items know who their TimeTicker's are (they can be registered with different ones).

Answer 3

What you are describing is the Observer pattern and Java has already two nice things for that in store. There is the interface Observer and the abstract class Observable. If you use these two, then your TimeTicker does not handle the observer. TimeTicker extends from Observable and does only the stuff it needs to do. When a certain amount of time has passed, it calls the method setChanged and notifyObservers.

Your TimeTicker does know 0 Tickables (Observer). The Observable abstract class does only know them via the interface Observer. Every Tickable can now register itself as an observer to the TimeTicker without a problem.

That being said you don't even need CueList anymore as the list of observers is handled by the abstract class Observable.

Answer 4

I would use the Domain Events pattern (google it) to afford TimeTicker and CueList to collaborate.

When the time is right, TimeTicker could 'raise' to a register of handlers an event called Tick. The register of handlers then passes Tick event onto all registered implementations of

Handle<Tick>  { void Handle(Tick t); }

Now you have options:

• CueList could implement Handle and tick its members.

• each Cue could implement Handle for itself

• or a general TickHandler class can get the CueList and update the cues