commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject RE: [general][lang] How much to focus on minimising dependencies
Date Fri, 04 Jun 2004 22:11:31 GMT


> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Thursday, June 03, 2004 2:08 PM
> To: Jakarta Commons Developers List
> Subject: Re: [general][lang] How much to focus on minimising
> dependencies
>
>
> 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.

I would argue the opposite - that these are crucial reasons to introduce
coupling. When code lives in one place and is shared, every client gets the
benefit of the developer base for that code. As a developer, I don't have to
keep track of classes, or other code, that I've copied for convenience, so
that I can pick up any bug fixes - I just get those fixes automatically.

--
Martin Cooper


> 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
>
>



---------------------------------------------------------------------
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