commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat
Date Thu, 19 Jun 2003 12:51:28 GMT

      It sounds like the pattern you're proposing is the Strategy design
pattern (see "Design Patterns" by the four authors).  Basically, an object
has multiple possible delegate objects, each of which implement a common
interface.  Then, as the state changes, the strategy can switch from one to
another.  This makes it transparent to the caller that multiple strategies
are being used, and that they are even changing, but allows for good
encapsulation, flexibility, and extensibility.

      As for invoking using either static methods or instance methods, the
Commons Bean-Utils does this.  There's a BeanUtils simpleton (all static
methods) that delegates to a BeanUtilsBean, which can be instantiated,
extended, etc.  So, the most common/shared version is accessible from
either way, but any specialized version must be instantiated yourself and
called directly.

      Design Patterns are a great way to make Java do what we want it to.

Eric Pabst

|         |           Al Chou         |
|         |           <hotfusionman@ya|
|         | >        |
|         |                           |
|         |           06/18/03 08:32  |
|         |           PM              |
|         |           Please respond  |
|         |           to "Jakarta     |
|         |           Commons         |
|         |           Developers List"|
|         |                           |
  |        To:      Jakarta Commons Developers List <>
  |        cc:                                                                           
  |        Subject: [math] design patterns (was Re: cvs commit:                          
  |        jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat

--- Phil Steitz <> wrote:
> --- Tim O'Brien <> wrote:
> > On Tue, 17 Jun 2003, Mark R. Diggory wrote:
> We all agree that the optimized double[]|-> double computations should be
> reused.  The problem with the above is that you can't "dynamically"
> reorganize
> class hierarchies.  UnivariateImpl either "is" an AbstractStoreUnivariate
> it
> "is not".  IMHO, it is not.  If we want to define an abstract base class
> everything, it needs to contain only the things that *all* Univariates
> *always*
> implement.  Throwing runtime exceptions when an instance is not a "full
> instance" is not acceptable.

Off topic here, but not having been a practicing OO programmer for very
(though having read books on C++, Java, and Objective-C over the past
years), and that mostly in Ruby, which is dynamically typed, I'm of two
here.  While I support a clear inheritance hierarchy and understand and
the desire to have an object be of either one class or another, it doesn't
bother me quite as much as it does Phil and Tim for an object to delegate
different classes under different circumstances.  I would prefer that
commons-math be easy for users to use than for it to stick closely to
Java designs just for the sake of staying Java-ish.  Maybe I'm unique, but
sometimes I find that Java (as well as other languages) gets in my way
than letting me solve the problem at hand in a natural way.  For example,
thing I would have liked to see is the ability to invoke methods by the
name either via static class methods or via instance methods of objects
appropriate and useful, of course).  I don't have enough experience with
to know if that's possible, though I suspect it would be difficult at

In any case, to keep our hierarchy design simple and clear, I do support
factoring out the StatUtils class.  As Einstein said, make it as simple as
possible (but no simpler).  I just want to see us keep an open mind about
designs in the future if they turn out to be worthwhile, even if not
the way "everybody else does it".


Albert Davidson Chou

    Get answers to Mac questions at .

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

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

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

View raw message