You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <gg...@seagullsoftware.com> on 2005/08/02 19:24:02 UTC
[lang] RE: Why is org.apache.commons.lang.math.IntRange final?
Personally, I do not see why these classes should be non-subclassable,
if that's a word. In the Range class I see:
"Specific subclasses hold the range values as different types. Each
* subclass should be immutable and {@link java.io.Serializable
Serializable}
* if possible."
I do not know why a range should be immutable, maybe Stephen can
elaborate.
Seems like Range should really be an interface and not a class, then we
could have a MutableRange subinterface (subclass?) Should we have an
ImmutableRange interface with a MutableRange sub so that we can keep
Range as a class for b/w compat?
But I'm not sure that makes any sense.
Gary
> -----Original Message-----
> From: Amit Kulkarni [mailto:amitkulz@yahoo.com]
> Sent: Tuesday, August 02, 2005 9:08 AM
> To: commons-dev@jakarta.apache.org
> Subject: Why is org.apache.commons.lang.math.IntRange final?
>
> I am trying to extend the functionality of IntRange based on Martin
> Fowler's Analysis Pattern of "Range" to model a street Address Range.
>
> http://www.martinfowler.com/ap2/range.html
>
> So for example, a street "Joe Blow St" will have an associated
> AddressRange of 2000-2999 etc...
>
> 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 just
extend
> IntRange. Why are these classes finalized? Is it just because of
> security as David Wheeler says in #8
>
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/java.html
>
> Btw, Commons is cool! I am also using MultiKey and MultiKeyMap to
> figure out errors in street attributes.
>
> Thanks in advance!
>
>
>
> ____________________________________________________
> Start your day with Yahoo! - make it your home page
> http://www.yahoo.com/r/hs
>
>
> ---------------------------------------------------------------------
> 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
Re: [lang] RE: Why is org.apache.commons.lang.math.IntRange final?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
>>From: Amit Kulkarni [mailto:amitkulz@yahoo.com]
>>I am trying to extend the functionality of IntRange based on Martin
>>Fowler's Analysis Pattern of "Range" to model a street Address Range.
>>
>>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 just
>> 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 used
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] RE: Why is org.apache.commons.lang.math.IntRange final?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Gary Gregory wrote:
> "Specific subclasses hold the range values as different types. Each
> * subclass should be immutable and {@link java.io.Serializable
> Serializable}
> * if possible."
>
> I do not know why a range should be immutable, maybe Stephen can
> elaborate.
As a general principle, all classes that represent basic fundamental
concepts should be immutable. Examples include String, Integer, Date
(note Date in Java is not immutable, a design flaw in Java often
commented on).
Immutable classes have many benefits, including being able to be used
safely across multiple threads without synchronization, being able to be
shared freely, and being simpler to code and use (as the object only
ever has one state).
To be immutable does not require the class to be final, however this is
the recognised Java standard.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org