commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <>
Subject RE: [lang] RE: Why is org.apache.commons.lang.math.IntRange final?
Date Wed, 03 Aug 2005 21:04:09 GMT
I agree with Stephen's classic 'is a' argument. I was just looking for
flexibility, which in this case does not seem to be needed since
composition is the better approach.


> -----Original Message-----
> From: Stephen Colebourne []
> Sent: Wednesday, August 03, 2005 1:08 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] RE: Why is org.apache.commons.lang.math.IntRange
> final?
> >>From: Amit Kulkarni []
> >>I am trying to extend the functionality of IntRange based on Martin
> >>Fowler's Analysis Pattern of "Range" to model a street Address
> >>
> >>I wanted to extend IntRange and add the functions mentioned in the
> >>"Range" pattern and add some more: for e.g. to check if its valid
> >> range (ideally in a constructor or a isValid() method). Right now I
>  >> am forced into cut pasting IntRange in my AddressRange class which
> extends org.apache.commons.lang.math.Range. I would ideally like to
> >> extend
> >>IntRange.
> Your problem is not that the IntRange class is immutable, but that you
> are designing your class in the wrong way. A subclass should not be
> just to share code. Instead it should represent a genuine 'is a'
> relationship.
> In this case, the AddressRange 'has a' range of valid integers. This
> should be represented by Composition, ie. by holding an IntRange field
> in your AddressRange class.
> BTW, if you have a copy, checkout chapters 13 and 14 of Effective Java
> by Joshua Bloch. If you don't have a copy, get one.
> Stephen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message