cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <mgen...@masslight.net>
Subject Re: Cayenne.java
Date Fri, 08 Mar 2013 15:45:43 GMT
Well, they "inherit" in the ability to call them.  For example, if you had:

public class CayenneUtil extends Cayenne
{
  // Many more static utility methods here
}

You could still then still call:

CayenneUtil.intPKForObject(artist)

This will call the "inherited" Cayenne.java method, plus you can call your
project-defined utilities with the same class.  I see this as being more
user-friendly.  I'm not talking about redefining the static methods, but
compositing new static methods in a subclass for simplification of calling
Cayenne-supplied utility methods and project-supplied utility methods.

Thanks,

mrg


On Fri, Mar 8, 2013 at 10:27 AM, Andrus Adamchik <andrus@objectstyle.org>wrote:

> Yeah. All its methods are static. There's no static inheritance in Java
> (unlike in say Objective C, you can't truly redefine a static method). So
> there's no instance behavior to inherit. In my mind this is a good reason
> to not ever want to subclass "Cayenne".
>
> Of course API style often comes down to personal preferences :)
>
> Andrus
>
> On Mar 8, 2013, at 4:22 PM, Michael Gentry <mgentry@masslight.net> wrote:
>
> > I was just looking at Cayenne.java introduced in 3.1 and noticed that it
> is
> > declared to be a final class.  Is there any reason for this?  I can quite
> > easily see people wanting to subclass it to add their own utility methods
> > which would make it easier for all those utilities to be grouped together
> > in one bigger class rather than spread out over several classes (from an
> > end-user's perspective of having to deal with different imports to access
> > the utilities -- obviously there would still be multiple classes, it
> would
> > just be better hidden).
> >
> > Thanks,
> >
> > mrg
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message