Fedor Karpelevitch <[EMAIL PROTECTED]> writes:
> > Yes, using two interfaces is definitely the Right Thing.
>
> I agree here, but my concern is that if you get into multiple inheritance
> thing you can no longer inherit implementation... Something to think about
> here....
An abstract base class which implements most of the functionality of
one or more interfaces is a good way to deal w/ that.
> > So we need a Clause interface and a ColumnMap interface (interface
> > names negotiable, just tossing out suggestions).
>
> I am not sure what Clause interface would mean. I do not see what different
> clauses have in common....
> And I am not sure what you mean by ColumnMap interface, is that Eric's "set
> column"?
My definition of a Clause interface is currently handled by a
Critiera's add() method used to build the WHERE clause of a SELECT
statement.
> > I really don't like the toSQL() method for a class which implements a
> > SQLCode interface. I would prefer that the standard toString() method
> > be part of the SQLCode interface, and that toString() be used in place
> > of toSQL(). Yes, the returned value *is* plenty readable.
>
> the reason for toSQL is not readablity (I withdrew that one), but these two
> things:
>
> 1) if you use toString() you end up with LOTS of String concatenation. toSQL
> returns StringStackBuffer instead. look at the code.
> 2) toSQL takes DB as parameter ( sig is toSQL(DBdb)) so it has the ability to
> produce DB-specific SQL if needed.
I withdraw my objection to a toSQL() method (or method other than
toString()), +1 Fedor.
> I do not think I instantiate anything _extra_ here versus method-based
> approach, because in that case you still need to put _some_ object into your
> list of conditions, be that Criterion or eanything else. So I think it is
> just as bad/good. I do not see any problem with that - objects are pretty
> light.
Creating three objects when you only need one is not light. Hell,
objects aren't light. In an enterprise environment, where *tons* of
requests are getting processed, unnecessary object instantiation
further slows a mostly likely heavily loaded application.
> btw in my opinion the better design allows for cleaner reuse of
> Query/Condition objects (they are thread-safe too) so you will be able to
> save a lot of the calls etc...
Reusing/pooling them is a nice idea! It would be even better if
synchronization could be avoided for read methods so that its
penalties could be avoided. However, I'm not certain how useful this
would be in practice without native reuse support in the framework
(Turbine) itself.
> > > I'm thinking of another alternative that would use
> > > methods instead of objects. Like these: .equals(col,val),
> > > .greaterThan(col,val), .in(col,val[]), .notIn(col,val[])
> >
> > I am not adverse to this idea. It will certainly perform much better
> > than possibly excessive object instantiation.
>
> again, i am afraid you'll have to create just as many objects.
Nope--the parameters are instantiated regardless.
> This approach,
> however is less flexible. The main reason I made everything an object
> implementing Condition is that And and Or accepts conditions as members which
> in turn may be And's and Or's thjis way allowing clean way to create
> conditions of any complexity. Also code duplication is virtual zero.
I agree that well defined interfaces result in cleaner code, which is
a *huge* plus in my book.
Dan, who is really late replying to this thread but just wants to get
his two cents in
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
