I've done similar things myself. extending unit test Assert classes to add more convenience methods. I leave the class name the same, but change the package.
On Fri, Mar 8, 2013 at 10:45 AM, 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 >> >>
