With regards to my -1: rather than rename getInstance methods, I would
prefer to remove them and solely rely upon utility methods such as
PredicateUtils#truePredicate.
I'm potentially fine with that, except I don't want it to be in
PredicateUtils - call it Predicates instead. PredicateUtils should be
for providing predicate utilities, not instantiating objects. On the
other side, perhaps PredicateUtils.and(Predicate, Predicate) is a
utility that happens to instantiate an object. (Can we rename these
methods to make them more concise and read better? For goodness sake:
PredicateUtils.andPredicate? We know it's a predicate already - even
with a static import, we know they're two predicates and it returns a
predicate. I like code sentences - my brain immediately knows what's
going on without translation).
TruePredicate really has no place in a Utils class, and I don't think
anything else should really instantiate it. It's a better pattern to
have it have it's own static constructor method. While not standard, I
believe this is better general programming practice than using
constructors, as they provide better flexibility long term.
If you were to create your own Predicates and have static constructor
factories, where would you put the static method? At the moment, I
figure the class is the best place.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
