commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <pj...@sfaf.org>
Subject RE: [collection] Predicate - a question
Date Mon, 17 Jun 2002 22:41:34 GMT
I'd add that documentation maintainence is much more difficult
if we implement things like

ListAdapter implements List
  ListAdapter.PredicatedList
  ListAdapter.LazyList

and so on.  The whole List API needs to be redocumented for
ListAdapter itself, and for every public member class of
ListAdapter.

With the static method approach, the method documentation only
needs to describe differences (eg, "Add and set operations may raise
an IllegalArgumentException if the new object doesn't pass the
predicate").

-Paul

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Monday, June 17, 2002 3:35 PM
> To: Jakarta Commons Developers List; Ola Berg
> Subject: Re: [collection] Predicate - a question
> 
> 
> Firstly, our new collections naming conventions call for 
> Utils classes with
> factory methods and private (well package scoped, but thats an
> implementation detail) static nested classes. The current 
> decorators in the
> package are expected to be deprecated (though this is not 
> decided). Thus
> there is not a choice/parallel impl for Users. They use the factory.
> 
> Secondly, inner classes as you suggest, are in the public API 
> and must be
> maintained (the whole class). With a factory method, what is 
> in the public
> API is much smaller.
> 
> Thirdly, I would prefer deprecated methods to deprecated 
> classes any day,
> but on that we may have to differ.
> 
> If you haven't got Joshua Bloch's Effective Java book, then I suggest
> getting a copy. It explains in chapter 1 why factories work. 
> On a personal
> note, I have designed two large systems, one used factories 
> for just about
> everything, the other didn't. Given a choice I would _always_ use
> factories - the flexibility and control you get to adapt 
> later is so much
> greater.
> 
> Stephen
> 
> ----- Original Message -----
> From: "Ola Berg" <ola.berg@arkitema.se>
> To: <commons-dev@jakarta.apache.org>
> Sent: Monday, June 17, 2002 11:17 PM
> Subject: Re: [reflect][collection] Predicate - a question
> 
> 
> > >> Personally I think that util classes with static factory methods
> > >> eventually will become a burden, and that you later on 
> will regret the
> > >> approach.
> >
> > >Why? I\'m interested in hearing your argument.
> >
> > Maybe the impact is less since Apache is open source and 
> free. People can
> modify their sources at will.
> >
> > But supplying decorators via static factory methods means 
> you have to
> support two things: the decorator and the static factory 
> method. And for
> each decorator that comes up, you have to consider inclusion 
> in the util
> class or not.
> >
> > Eventually you will divide all decorators into two 
> categories, those who
> has a decorator method and those who hasn\'t. Which means you 
> have to teach
> two methods of doing the same thing. Users of your API might feel
> uncomfortable with this, and maybe even feel unencouraged to 
> supply new
> decorators. Should they regard the util-supported decorators 
> as first-class
> and the others as \"unsupported\" or less worth?
> >
> > And consider a set of good decorators that resides in 
> another package, you
> don\'t want to support them in your util method, because you 
> don\'t want
> bi-directional dependencies to the other package, it is enough if they
> depend upon you. The AssertingPredicate mentioned before 
> might end up in an
> assert-package, not where PredicateUtils are.
> >
> > If the main motivation is reducing size of the root level 
> of the public
> API (less classes to import, easier to learn), there is the 
> method of inner
> classes. You don\'t have to include the implementation within 
> the interface
> as my example, you could categorize your Iterator-decorators 
> into groups,
> where Iterators in the same group are inner classes in the same class.
> >
> > Often the naming can be made very logical that way:
> >
> > Predicate.Or
> > IteratorAdapter.FromEnumeration
> > IteratorAdapter.FromArray
> > FilterIterator
> > FilterIterator.Asserting
> > etc
> >
> > Factories means another level of indirection. Factories could be
> motivated, fx when you need to hide implementation, but even 
> then the inner
> class concept works fine, as IteratorAdapter could be a 
> decorator to either
> FromEnumeration or FromArray, depending on the constructor used.
> >
> > Often where factories are needed, there is a need for 
> plugable factoriy
> instances where you instantiate and configure a certain factory
> implementation (fx in the Bridge pattern). Static factory 
> methods are less
> _needed_ in that sense.
> >
> > So I think static factory methods is a burden, in that you 
> have to support
> two parallell ways of doing the same thing. I think it is 
> better to stay
> with the most general way and teach the users just that.
> >
> > Ok, so when will you be sorry? Well, as computing advances, 
> new ways of
> doing things will come up, and old ways be seldom used. 
> Eventually your util
> class will contain methods people seldom uses, because of the 
> old decorators
> that you get there. Util class is still needed, but it grows 
> bigger and
> bigger, encumbered by less used methods. With old decorator 
> classes there is
> not the same deal, you can just let them be, deprecating them 
> and promote
> the new ones. Lot of deprecated static methods in a class is 
> harder to cope
> with.
> >
> > Another aspect is that the users might very well find 
> themselves needing
> control over the implementation. If the decorating method 
> simply returns
> Iterator or Predicate, this won\'t suffice for them.
> >
> > Maybe these arguments are weak in your point of view, I 
> however regard
> them as strong. But again, it is your API.
> >
> > /O
> >
> > --------------------
> > ola.berg@arkitema.se
> > 0733 - 99 99 17
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> >
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message