commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [general][lang] How much to focus on minimising dependencies
Date Thu, 03 Jun 2004 21:07:56 GMT
The phrase 'cut and pasted' is liable to immediate negative reaction. Try
the phrase 'should be coupled'.

The argument I put forward is that we should not couple two classes together
unecessarily just as we should not couple two jar files together. Every
connection made has implications. The positive side effect of reduced
coupling is ease of copy elsewhere.

The particular case, Validate, struck me as a class that has no need to be
coupled to any other. However others have argued that it should to save on
maintainance or code duplication. I argue that these are poor reasons to
introduce the coupling.

What has not been argued is the case for the coupling
_based_on_what_the_methods_do_. Validate.isNotEmpty(String) validates that a
string is not empty. StringUtils.isNotEmpty() tests whether a string is not
empty. There is actually a legitimate case for coupling here if the aim is
to define validate as being a wrapper around StringUtils adding error
message functionality. (Note I only realised this last night ;-)

As a counter-example, consider Enum in the enums package which uses
StringUtils to check for non null and non empty string names. Here, Enum
wants non-null and non-empty names. This happens to be the same code as in
StringUtils, but thats a poor reason to couple.

I know.... its a fine line (and maybe I've failed to explain my point even
now). But where possible, I would like to see each package in [lang]
independent, and ideally also the lowest level utilities (ArrayUtils,
StringUtils, WordUtils,...)

Stephen

----- Original Message -----
From: "Henri Yandell" <bayard@generationjava.com>
> Changing the subject to kick it more open.
>
> My view is:
>
> (From earlier)
> "As a basic rule, I think it's pretty fair to state that package hierarchy
>  should be obeyed as far as dependencies goes. This means that a package's
>  classes may not depend on a sibling package, or a child package, but it
>  may depend on a super-package or classes within the same package. "
>
> Siblings sometimes have to depend on each other, but it's the same type of
> dependency as inter-project dependencies.
>
> Allowing for a single class to be copy and pasted is too much though.
>
>
> I'd be interested in hearing counter-arguments to this viewpoint.
>
> Hen
>
> On Wed, 2 Jun 2004, Tim O'Brien wrote:
>
> > > -----Original Message-----
> > > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > > Sent: Tuesday, June 01, 2004 5:24 PM
> > > To: Jakarta Commons Developers List
> > > Subject: Re: [lang] Re: cvs commit:
> > > jakarta-commons/lang/src/java/org/apache/commons/lang Validate.java
> > >
> > > > I'm confused -- why shouldn't a class in [lang] have
> > > dependencies to
> > > > other classes in [lang]?  Isn't this taking things too far??
> > >
> > > Its part of [lang] being broad and shallow. In effect, [lang]
> > > is a loose grouping of APIs in a similar vein. As such it
> > > should be easily broken into many parts.
> > >
> > > ie. a user should be able to come along and take one class (wherever
> > > possible) and paste it into their own CVS/project.
> > >
> > > Think of it as a single class jar file. [lang] just provides
> > > a home for it without needing the additional jar packaging.
> > >
> > > Stephen
> >
> > I can't say I agree with this POV, but I do think that it needs a more
> > formal fleshing out than a Re: thread for a CVS commit.
> >
> > I can see the benefit of reducing dependencies among different projects,
but
> > I don't see a good rationale for not having Validate use StringUtils
and/or
> > ArrayUtils.  I'm not of the opinion that we should increase the effort
of
> > maintaining common components because there are people who cut/paste
code
> > into separate projects.
> >
> > Respectfully,
> >
> > Tim
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message