Which do you think is better?
this:
-
public interface Scheduler {
-
// schedule job to deliver the domain object represented by the domainId at scheduleDate
-
public void scheduleDeliver
(Long domainId,
Date scheduleDate
);
-
public void scheduleReprocess
(Long domainId,
Date scheduleDate
);
-
…
-
public void scheduleCleanUp
(Long domainId,
Date scheduleDate
);
-
}
or this:
-
public interface Scheduler {
-
// schedule a job
-
public void schedule
(Date runAt, Job job
);
-
}
I would say “It depends, what is in the Job class?”
-
public interface Job {
-
public void run();
-
}
Heh, ok so its an interface. What is the implementation?
-
public class DeliveryJob implements Job {
-
public DeliveryJob(/* context */) { … }
-
public void run() {
-
// delivery code here.
-
}
-
}
Which gives you this client code:
-
public void someMethod() {
-
…
-
SchedulerImpl.schedule(runAt, new DeliveryJob(/* context can be passed in here */));
-
…
-
}
But also allows for the implementation of closures:
-
public void someMethod() {
-
…
-
SchedulerImpl.schedule(runAt, new Job() {
-
// code goes here.
-
// context in final variables in outer "someMethod"
-
});
-
…
-
}
Ok, so there are two different interfaces, both ostensibly providing a mechanism to schedule something to run at a later date/time. Which is better? Lets look at each in turn.
The first one is using primatives to represent the data needed for the scheduling contract, in this case a Long for a “domainId” and a Date for the “scheduledDate” to run at. Each method specifies what type of job needs to be scheduled (”scheduleDelivery”, “scheduleReplay”, etc). On the immediate surface, there is nothing that stands out as a major issue. Now, lets think about how this will need to be maintained:
- Lets say you need to change the domainId from a Long to a “DomainKey” object. This is a huge change, of which the Scheduler interface is going to see only minor changes from, but will cause rippling effects throughout both the client and the implementation code.
- What if you want to allow a different type of job to be scheduled? You would need to add a new interface method and a new implementation.
- The interface leaves you (or at least me) with the impression that I would need to keep the interface pretty consistent to maintain clarity. That means that anytime I wanted to schedule some new thing, I would feel compelled to propagate the interface as it is currently implemented. If I needed to do anything that seemed inconsistent I would hesitate, and probably end up with an implementation different than I initially wanted.
The second one uses an Interface to provide the job implementation. This helps to abstract the Scheduler from the implementation details of the job. By not tying into the implementation details, it keeps it’s Single Responsibility clear: to run the given job at the given time.
The only “problems” that this implementation has is that it creates extra classes, and has the ability to be “abused” by using anonymous inner classes. Notice the use of quotations in the prior sentence to indicate the facetiousness of this argument. Surprisingly, I’ve heard this argument so many times, both directly and indirectly. In this case the argument is groundless, as there is very little in the way of extra classes; just an interface and a class per implementation. This is no big deal, and is completely outweighed by the simplicity of the design.
Another argument that I have heard with this type of discussion is that the only data needed is the primitives, so why not just send that? Well, there are a number of reasons not to do that. The first is that the primitives do not represent your domain… they are an abstraction of your domain, which is an abstraction itself. I generally prefer to keep my sanity.
The one argument I could see holding water against the second interface is if it is desirable to have a domain centered interface for scheduling these jobs. But, in this case, the solution is not to get rid of the current Scheduler interface, but to add a Domain Specific Scheduler interface:
-
public interface DomainScheduler {
-
public void scheduleDelivery
(Date runAt, DomainObject
do);
-
…
-
}
Notice that even this new interface stays away from the primitive Long domainId field from the first interface. This reduces the problems from the first interface:
- Now, a change to the key would not require an interface change, and depending on the implementation, it may not need to change either. The client code is obviously not affected.
- It is clearer what you are doing with the data. Even if the underlying implementation does the exact same thing, now you are not wondering why only the id field is needed.
The final two interfaces are examples of porous interface design. They allow for wider ranges of data to go through, but without the worry of incorrect data, or providing too much data (Why would you allow Object?). They also make the system more extensible without changing any of the existing code. By keeping things centered around the domain, and the Single Responsibility Principle in mind, you end up with a much simpler, more maintainable design.
