Re: generics puzzle
On 10/18/11 2:45 AM, Steven Simpson wrote:
On 17/10/11 16:58, Daniel Pitts wrote:
On 10/17/11 5:14 AM, Steven Simpson wrote:
On 17/10/11 11:41, blmblm@myrealbox.com wrote:
One fix is to just introduce a method setFromModified() in GThing,
but that doesn't appeal to me.
Instead of adding it to GThing, create a static method:
private static<T> void setModified(GThing<T> t) {
t.set(t.modified());
}
What about the simpler solution:
in the GThing class:
public void setModified() {
set(modified());
}
It "doesn't appeal" to the OP? Nor to me. Not sure I can put my finger
on it, but if I were the maintainer of GThing, I'd consider its
specification to be complete without this method. It doesn't increase
the value of the class as an abstraction. Adding it would certainly just
be a convenience for the caller. It solves a problem generated by the
design of the call site, not the design of the class's contract. The
caller can write his own routine as necessary.
Possibly, but if it is something that happens frequently, then it seems
more likely to belong to GThing than externally. Otherwise your
call-site is suffering from the code smell "feature envy"
One other approach is a "visitor" pattern:
public interface GThingVisitor {
<T> void visit(GThing<T> gThing);
};
public class SetModifiedGThingVisitor {
<T> void visit(GThing<T> gThing) {
gThing.set(gThing.modified());
}
}
public class GThing<T> {
public void accept(GThingVisitor visitor) {
visitor.accept(this);
}
}
public class CallSite {
public void setAllModified(Iterable<? extends GThing<?>> things) {
GThingVisitor visitor = new SetModifiedGThingVisitor();
for (GThing<?> thing: things) {
thing.accept(visitor);
}
}
}