On Thursday, May 17, 2001, at 12:49 PM, Fedor Karpelevitch wrote:
>> Yep, inheriting implementation would be nice. So I put all the
>> functionality for SELECT, INSERT, UPDATE and DELETE together in my
>> first suggestion. When I was extending that to create Select,
>> Insert, Update, and Delete objects, my first draft was to make
>> Query an abstract class and make the others subclasses. Where
>> there were methods in Query that were inappropriate for Insert, I
>> would override the inappropriate methods and maybe throw an
>> exception. The whole point was to be able to inherit
>> implementation while providing an API that reads well. This
>> inheritance convenience comes at the expense of having objects
>> totally specialized to their task.
>
> hm,hmm.... I do not like providing an API and not implementing it....
> It's
> just not right... I am not sure how it can be done better.... I don't
> have a
> solid opinion here yet.
I don't think it's right or wrong. It's a trade off. In the
Composite pattern, the GoF encourage programmers to not implement
the full API for some of the objects in order to simplify the
client code that uses that api. The pattern is good design, but
there are known consequences and trade offs. We just have to
choose our consequences.
>> I take Dan's suggestion to be names for the two interfaces I suggested.
>> I think Where interface would be more specific,
>
> I am still in doubt what Clase (Where) interface function would be...
In my example this would be the interface for .and() and .or() methods.
The stuff that builds the where clause. I don't know where this fits
in your model. Maybe it isn't even appropriate.
>> I'm not sure StringStackBuffer is the right choice for the return type.
>
> I think it is :-) It saves a lot of string concatenation. StringBuffer
> would
> not help much in this case.... In fact current Criteria & friends use
> StringStackBuffer and I found that reasonable.
>
>> With a StringStackBuffer you can do .toString("/"). That's reasonable
>> to
>> do with a StringStackBuffer, but not reasonable for the SQL we want
>> out.
>
> In our case we'd use .toString() as there is no need for a separator.
Yeah, I understand that. Just pointing out that people can do
things with a StringStackBuffer that would be stupid to do with
SQL. I know you can't prevent all stupidity. Is this a place
where we want some prevention, or just warnings in the javadocs?
>> Every place in the API you propose that has new XYZ() is instantiating
>> an object. By contrast, this latest suggestion I've offered...
>>
>>> new Comparison().equals(col,val).or().equals(col2,val2)
>
> but how do you implement .equals() method? You will have to instanciate
> _some_ object to add to your list of conditions, won't you? That's
> what I
> meant... So there should be just as much object instantiation... am I
> wrong?
The above example could be rewritten to better show the number of
instances:
Comparison comp = new Comparison();
comp.equals(col,val);
comp.or();
comp.equals(col2,val2);
One object created and occupying memory. Many methods called for
that object. When the methods are chained together, there's
still only one object in memory. It's references to that object
that are being passed around.
>> ...the Comparison object is instantiated only once. All of the methods
>> would modify that Comparison instance and return a reference to it.
>> The only place where another instance would be created is when nested
>> groups are needed in the comparison. That might look like this:
>> new Comparison().equals(col,val).and(
>> new Comparison().equals(col2,val2).or().equals(col2,val3))
>> which would create SQL like this:
>> COL=VAL AND (COL2=VAL2 OR COL2=VAL3)
Comparison inside = new Comparison();
inside.equals(col2,val2);
inside.or();
inside.equals(col2,val3);
Comparison outside = new Comparison();
outside.equals(col,val);
outside.and(inside);
Two objects, many method calls.
>> With your model the equivalent SQL would need something like this:
>> new And(new Equals(col,val),
>> new Or(new Equals(col2,val2), new Equals(col2,val3)))
Equals inside1 = new Equals(col2,val2);
Equals inside2 = new Equals(col2,val3);
Equals middle1 = new Equals(col,val);
Or middle2 = new Or(inside1,inside2);
And outside = new And(middle1,middle2);
Five objects, only constructors are called. (I miscounted in my
last email. 8^)
> so the only difference is _where_ in the code object is created, but the
> number should be the same....
Your model is definitely instantiating more objects.
> On a side note, .equals is a bad name for the method as it looks like an
> overload for Object.equals(Object) method, but it has a completely
> different
> semantics which is confusing and is not good.
Yeah, I thought of that too. Any suggestions for a better name?
-Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
