Final defenders

[Talden]

The tenets I assume you're referring to are Minimise Coupling,
Maximise Cohesion.

The key words being Minimise and Maximise.  They are advisable goals
but not absolutes.

I think that, in the presence of interface static methods, it is
perfectly reasonable for an interface to refer to implementations that
are part of the same delivery - there is a cost-benefit threshold (a
possibly subjective or at least highly contextual ratio) at which
point some coupling is warranted.

Note that Daniel has, quite rightly, hidden the implementation in
declaring the interface as the result. He has not coupled the
interface and implementation in reverse since the implementation has
not become part of the interface contract.  A future java iteration
could deprecate and remove ArrayList without breaking the contract of
the method.

Now, I'm not agreeing that the interface should declare these methods
(I'm rather on the fence on the issue at the moment having not
convinced myself of the cost-benefit being in the right direction),
only that I don't see a fundamental violation of OO principles at
work.  I think that factory methods like these, returning an
effectively anonymous implementation with a declared set of
time/space/feature trade-offs, are an attractive application of
interface static methods.

Daniels point, at least what seems implied, is right - people don't
usually choose ArrayList because they specifically want an ArrayList,
they want an implementation with fairly constant-time random-access.
The method contract might need to specify more characteristics than
just that to be useful but it's a fair point.

The question for me is, at what point is having too many of these
kinds of methods no longer beneficial - when do we reach API
complexity overload? Do we code search the open-source java ecology to
discover which would be most used, do we try to guess based on the
implementations we have to hand or do we add a couple of the ones
likely to be good for early adopters and use feedback to add more in
later java iterations?

--
Aaron Scott-Boddendijk

On Wed, Aug 8, 2012 at 7:35 PM, "Zdeněk Troníček" <tronicek at fit.cvut.cz> wrote:
> Hi Daniel,
>
> unfortunately, these arguments are going against a basic principal in OO
> programming. You asked so that List knows about the classes that
> implements it.
>
> Z.
> --
> Zdenek Tronicek
> FIT CTU in Prague
>
>
> Daniel Latrémolière napsal(a):
>>
>>> Hi,
>>>
>>> these methods should be in a class if they are useful. E.g. in
>>> java.util.Collections.
>>>
>>> Z.
>> By being in List interface, they are easier to find. In an external
>> class, they have a very small value comparing to current constructors.
>> Static methods from classes like Collections, Arrays are not useful for
>> beginners because they are impossible to find in a very big API like
>> Java).
>>
>> But, if you know that all lifecycle (factory for creation, change of
>> content, etc.) of a List is managed by List interface, you know exactly
>> where to find the solution of your problem. You can even publish a
>> subset of javadocs of Java without implementing classes like ArrayList,
>> LinkedList, etc. which will be much more clear for learning Java and
>> attracting new users.
>>
>> A defender method in interface can too be a method in Collections class
>> (even allowing specialized implementation with a service to be
>> implemented), but this is always more difficult to find and it give
>> globally a very complex API.
>>
>> Daniel.
>>
>
>