cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
Subject Re: Cayenne.java
Date Fri, 08 Mar 2013 15:49:38 GMT
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 <mgentry@masslight.net> 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 <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
View raw message