Al,
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 |
| | <[EMAIL PROTECTED]|
| | hoo.com> |
| | |
| | 06/18/03 08:32 |
| | PM |
| | Please respond |
| | to "Jakarta |
| | Commons |
| | Developers List"|
| | |
|---------+--------------------------->
>---------------------------------------------------------------------------------------------------------------|
|
|
| To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
|
| cc:
|
| Subject: [math] design patterns (was Re: cvs commit:
|
| jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat
UnivariateImpl.java) |
>---------------------------------------------------------------------------------------------------------------|
--- Phil Steitz <[EMAIL PROTECTED]> wrote:
> --- Tim O'Brien <[EMAIL PROTECTED]> 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
or
> it
> "is not". IMHO, it is not. If we want to define an abstract base class
for
> 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
long
(though having read books on C++, Java, and Objective-C over the past
several
years), and that mostly in Ruby, which is dynamically typed, I'm of two
minds
here. While I support a clear inheritance hierarchy and understand and
value
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
to
different classes under different circumstances. I would prefer that
commons-math be easy for users to use than for it to stick closely to
typical
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
rather
than letting me solve the problem at hand in a natural way. For example,
one
thing I would have liked to see is the ability to invoke methods by the
same
name either via static class methods or via instance methods of objects
(where
appropriate and useful, of course). I don't have enough experience with
Java
to know if that's possible, though I suspect it would be difficult at
least.
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
other
designs in the future if they turn out to be worthwhile, even if not
exactly
the way "everybody else does it".
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
