BTW, even though this won't be my coding style to extend o.a.c.Cayenne, I have nothing against removing "final" from it.
On Mar 8, 2013, at 6:45 PM, Michael Gentry <[email protected]> wrote: > 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 > <[email protected]>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 <[email protected]> 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 >> >>
