Xavier Hanin wrote:
I'm sorry I must be tired but I don't see how using a factory method
instead
of a constructor introduces a dependency. Are we really talking about the
same thing?
It's me not being clear enough.
I meant the fact that IvySettings is introduced within the factory
method leads to this.
I admit that in case of DeliverOptions I don't see any reason why we'd
want
to subclass it, since it doesn't define any behavior, it's only used to
group attributes. So I'm fine with using a constructor instead of a
factory
method, but I still don't see the advantage.
Overall in this specific case dependencies and constraints about the
model are introduced while you get no benefit in return.
Indeed a DeliverOptions is actually created when you deliver...which
means you do it only once in Ivy class.
Once again I'm not sure we're really talking about the same thing, but
the
benefit I see when using a class to store a set of parameters is to
have a
cleaner and more readable API (methods with less arguments) and more
manageable (it's easy to add a new parameter without breaking the
API). But
I'm pretty sure you agree that methods should have too many arguments, as
you suggest it's a bad thing for constructors (below). But maybe you have
another solution than introducing a class like DeliverOptions?
Ah, I see probably where we don't understand each other.
No I'm not saying that DeliverOptions is a bad idea, just the
DeliverOptions.newInstance(IvySettings) because of this IvySettings that
suddenly pops up as a dependency while it could very well not be there.
Yes, this is a real problem. Another problem is that from the
beginning it's
possible to specify the directory to use as root for the cache in
almost all
method calls, instead of always using the default cache configured in the
settings. So this directory everywhere, instead of using only the
settings
which are usually available everywhere. A real pain, for something that I
doubt is even used :-(
Anyway, cache management should really be reviewed and improved, but I
don't
think it's directly related to the topic of method arguments refactoring.
Oh I think it's just a manifestation of it, because cache or something
else when you are deep in the chain and suddenly find yourself in a
position of 'oh s*, I need this information, how can I get it',
generally we, humans tend to solve that problem as 'I'll give it as an
argument to...'. Damn humans. :)
Oh and don't misunderstand me I really think what you've done is great
because that will make it much easier to understand (I'm actually quite
amazed at the speed you've been doing it), but I'm just no fan in
introducing lots of methods that can be distracting in an API.
Not sure I'm much more clear, but I too have very tired eyes and cloudy
brain. Sorry about that.
-- stephane
