Re: Question about OM classes

[Robert Jenks <rj...@cvsroot.org>]

> The BaseFoo and Foo classes are designed so that they both have to be
> present.  The BaseFoo class is contains code that can be regenerated and
> any modifications should be made to Foo.  One case for referencing Foo
> in BaseFoo is when instantiating a new Foo as happens in the copy
> method.  BaseFoo is abstract as there should not be any instances of
> BaseFoo.
>
> If you want to create a separate package, just extend from Foo in the
> new package.  Though I do not see the reason for doing so.
>
> john mcnally

I'm not actually going to extend it in another package, just in another
directory tree so that my auto-generated Java classes are kept separate from
my editable classes.  It just seems like a violation of OO principals for a
base class to depend on it's sub class, that's all.  Typically if a base
class needs to manipulate sub-classes it does so using factory methods and
not direct references.  Again, I'm not suggesting that this is horribly
evil, just that it seems odd and maybe isn't necessary.

-Robert



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Question about OM classes

[John McNally <jm...@collab.net>]

The way i consider it the two classes make up one object.  Not perfect
oo design, but if you think of BaseFoo.java as just a place to store
methods available for use in Foo.class, maybe it is more tolerable?

john mcnally

Robert Jenks wrote:
> 
> > The BaseFoo and Foo classes are designed so that they both have to be
> > present.  The BaseFoo class is contains code that can be regenerated and
> > any modifications should be made to Foo.  One case for referencing Foo
> > in BaseFoo is when instantiating a new Foo as happens in the copy
> > method.  BaseFoo is abstract as there should not be any instances of
> > BaseFoo.
> >
> > If you want to create a separate package, just extend from Foo in the
> > new package.  Though I do not see the reason for doing so.
> >
> > john mcnally
> 
> I'm not actually going to extend it in another package, just in another
> directory tree so that my auto-generated Java classes are kept separate from
> my editable classes.  It just seems like a violation of OO principals for a
> base class to depend on it's sub class, that's all.  Typically if a base
> class needs to manipulate sub-classes it does so using factory methods and
> not direct references.  Again, I'm not suggesting that this is horribly
> evil, just that it seems odd and maybe isn't necessary.
> 
> -Robert
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Question about OM classes

[Eric Dobbs <er...@dobbse.net>]

On Friday, November 30, 2001, at 08:25  PM, Robert Jenks wrote:

>> If you want to create a separate package, just extend from Foo in the
>> new package.  Though I do not see the reason for doing so.
>>
>> john mcnally
>
> I'm not actually going to extend it in another package, just in another
> directory tree so that my auto-generated Java classes are kept separate 
> from
> my editable classes.

I think that Scarab (http://scarab.tigris.org) stores the
BaseFoo in separate directories from the Foo.  I glanced
through the source and it looks like that his handled
with ant in the build.xml files.  After the object model
is generated there's a filter to copy the Base*.java files
to a different directory.

Probably easier than rewriting the subclasses from scratch
and would probably solve your compiling problems.

-Eric


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>