Maybe a higher level abstraction is also in order.
With TargetObject (I will stick to this name just to
move ahead with the discussion) and isDirty, we have
a mechanism to see if a target object is outdated or
not.
However, the consumer of this still needs to do
the dirty work of having to iterate through all
the Source Objects and see if the corresponding
target Object needs to be updated.
Instead, if we have something like an UpdateManager
that has a setter for the Source Objects and a getter
for the Target Objects, it would be very useful also.
interface UpdateManager {
void setSrcList(List src);
List getDestList();
}
An implementation of UpdateManager's getDestList
method would iterate through each src element and
invoke TargetObject's isDirty using it and build
the dest list with just those src elements that
need to be updated.
Cheers,
Magesh
----- Original Message -----
From: "Stefan Bodewig" <[EMAIL PROTECTED]>
> Thanks for your comments, Magesh and Dominique.
>
> On Mon, 2 Dec 2002, Dominique Devienne <[EMAIL PROTECTED]> wrote:
>
> > From: Magesh Umasankar [mailto:[EMAIL PROTECTED]
>
> >> public boolean isDirtyWhenComparedWith(Object src);
> >> or if the "WhenComparedWith" seems to be pedantic,
> >> public boolean isDirty(Object src);
> >>
> >> Other implementations of TargetObject may choose
> >> different mechanisms to perform the comparison before
> >> saying that the target object is dirty or not.
> >
> > I like this abstraction. But would it work with a mapper that
> > returned several files to check dirty status given the proposed
> > single object signtature?
>
> As it is right now, TargetObject would be what the mapper has mapped
> to, so it would work (you have a single source file and multiple
> TargetObjects).
>
> >> As far as naming goes, the Object part in TargetObject seems
> >> pedantic to me.
>
> What do you expect, it's me 8-)
>
> > I don't like that name personally. TargetObject seems designed
> > exclusively for SourceFileScanner, and thus should relate to it by
> > name. Something like SourceFileItem?
>
> Which could be applied at both sides (taking the abstraction to the
> source side as well), yes. But if I wanted to move it to the source
> side as well, I'll soon get into trouble with isDirty as FileItem
> would need to know how to compare itself to a ZipItem or something.
>
> Stefan
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
