commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Egge (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COLLECTIONS-276) *Utils classes should not be extensible or able to be instantiated.
Date Mon, 12 Nov 2007 11:10:50 GMT

    [ https://issues.apache.org/jira/browse/COLLECTIONS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541740
] 

Brian Egge commented on COLLECTIONS-276:
----------------------------------------

I don't see any benefit to restricting a users choices.  Your preference might not be to use
inheritance, but that shouldn't restrict others.  I find having a MyCompanyUtils class extend
*Utils is quite useful.  I might add an additional overload to a method.  In Eclipse, it will
show me all of the possible overloads of a method.  If I then choose one in the super class,
I may go ahead and accept the auto-correct.  I might decide to add overloads which accept
an array instead of a collection, and want to be able to view them side by side with the other
static functions.

I have a StringUtils class which extends the commons.lang.StringUtils.  I generally create
this in every project, and it grows as I add String related static functions.  

Making a class final might have had a performance improvement in Java 1.0, but in modern JVMs
it has no affect.  I think the Open/Closed principle indicates that you should make your classes
open for extension if possible.

> *Utils classes should not be extensible or able to be instantiated.
> -------------------------------------------------------------------
>
>                 Key: COLLECTIONS-276
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-276
>             Project: Commons Collections
>          Issue Type: Improvement
>    Affects Versions: Generics
>            Reporter: Stephen Kestle
>            Priority: Minor
>             Fix For: Generics
>
>
> I don't see any good reason why this CollectionUtils (and others) isn't final with a
private constructor.  There are no non-static methods, and any extension of them is going
to have to call through to the super to avoid compiler warnings.
> e.g. MyCollectionUtils.select() will provoke the warning that "static methods should
be called directly" (on CollectionUtils).
> Which would mean
> MyCollectionUtils{
> public static Collection select(){
>     return CollectionUtils.select();
> }
> Which really defeats the purpose.  In Java5, we have static imports now -  these provide
more benefit than previous extension did anyhow.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message