Hello,
On Monday, September 2, 2002, at 04:17 , Holger Hoffstätte wrote:
> - Strings are evil! I beg you to please, PLEASE! change the APIs that
> take
> Strings as arguments to only use classes or proper Db/ObjEntities
> whereever possible. For example:
Well, I do have to agree with Holger that ""Strings are evil!"... And
yes, a lot of them can be eliminated (eg class name and such)... Which
leaves the crux of the problem untouched: attribute names. Which is kind
of a bummer, because that leaves the entire KVC way of doing thing
floating in the amorphic world of the untyped: no type information about
method, parameter, return type, exceptions... Casting everywhere, every
time. Duh...
Which is, as pointed out, very counterproductive and error prone.
On the other hand, generating before hand a bunch of classes simply to
get proper methods and some place holder for ivars seems, well, not
worth the trouble. Plus, it's ugly, cumbersome and inflexible.
Ideally, I would like to see something that is both strongly typed,
generic, and does not require any specific class hierarchy... :-) Which
seems to be a tough one to crack in Java.
Putting feasibility issues aside, here is a scenario I was thinking of
trying to pursue to try to square is off...
For example, an EO could access its data the following way:
public class MyEO extends Object
{
public String name()
{
(1) ObjectStore aStore = ObjectStore.storeForObject( this );
(2) MyEOI anInterface = (MyEOI) aStore.interfaceForObject( this );
(3) return anInterface.name();
}
}
(1) First, an EO get its object store.
(2) Then, it asks for an interface to its data... instead of using KVC
or relying on some imposed superclass implementation.
(3) Finally, it simply ask the interface for a given value... Will all
the benefit of a strongly typed method.
The interface itself could be generated (urgh!) by the system during
modelization and would mimic all the EO attributes properties:
public interface MyEOI
{
public String name();
}
Now, the object store could provide a default implementation of the
interface to retrieve data by using java.lang.reflect.Proxy. Something
along the line of:
public Object interfaceForObject(Object anObject)
{
InvocationHandler anHandler = new DataHandler( this, anObject );
Class aClass = Class.forName( anInterfaceName );
Object anInterface = Proxy.newProxyInstance
( aClass.getClassLoader(), new Class[] { aClass }, anHandler );
return anInterface;
}
Now the InvocationHandler could be implemented in whichever way the
ObjectStore see fit to retrieve any given data.
To summarize:
- The Modeler generates an *interface* to interact with an EO data.
- The EO can be of any class.
- To access its data, the EO would ask its ObjectStore for a "data"
interface.
- The ObjectStore will provide an interface implementation through the
Proxy mechanism.
Bottom line:
- Only one *interface* get generated for each entity.
- Only one cast necessary (from Object to a specific EO "data"
interface).
- Everything from then on is strongly typed.
- No need for any artificially imposed class hierarchy.
What do you think? Any thoughs, comments, criticisms are more than
welcome!-)
Cheers,
PA.
This archive was generated by hypermail 2.0.0 : Tue Sep 03 2002 - 05:43:07 EDT