cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Cayenne.java
Date Fri, 08 Mar 2013 19:50:48 GMT
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 <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