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: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
