|
Replies:
5
-
Last Post:
May 20, 2005 10:28 AM
by: alexlamsl
|
|
|
|
|
|
|
Finer grained method access specifier
Posted:
Apr 29, 2005 8:42 AM
|
|
|
I don't know whether this has been discussed yet or not (I suspect so) but we need finer grain control over who sees what methods. Specifically, I want to give my own API public access to some of its own methods and make them private to end-users. Or, I want to give Hibernate public access to some methods, and private to end-users.
In a lot of cases we are running into, especially when using 3rd party frameworks, we want to expose different "views" of our objects to different frameworks.
I guess maybe the idea is to have your object implement different interfaces and expose it to different frameworks with different interfaces. Either this approach should be better documented (some sort of public guide would be nice) or there should be better support for this in the language itself.
Gili
|
|
|
|
|
|
|
Re: Finer grained method access specifier
Posted:
Apr 29, 2005 4:17 PM
in response to: cowwoc
|
|
|
A followup, I implemented what I proposed (exposing different interfaces depending on the user). The downside is that you have a lot of different interfaces floating around for what really should be a single interface, and secondly you end up having to do a lot of casting back and forth between one "view" of the class to the other and this is expensive.
|
|
|
|
|
|
|
|
|
Re: Finer grained method access specifier
Posted:
May 1, 2005 10:16 PM
in response to: cowwoc
|
|
|
To present different versions of an object to varius thingies, you use adapter classes.
To stop things calling your methods that you don't want calling them, java already has access control at the method level. Yes, you have to learn how it works and sign your JARs etc.
|
|
|
|
|
|
|
|
|
Re: Finer grained method access specifier
Posted:
May 3, 2005 9:32 AM
in response to: pmurray_bigpond
|
|
|
I don't think the adapter pattern solved this (correct me if I'm wrong)...
For example, I have the following inheritance hierarchy:
// Methods common to all views of Theme
interface ThemeCommon
// Theme interface as seen by the end-user
interface ThemeUser extends ThemeCommon
// Theme interface as seen by Hibernate
interface ThemeHibernate extends ThemeCommon
// Concrete implementation
class ConcreteTheme implements ThemeUser, ThemeHibernate
Now, if I understand you correctly if I were to refactor this in terms of adapters I'd have:
// Theme as seen by Hibernate
interface ThemeHibernate
// Theme as seen by User
interface ThemeUser
// All methods in all views
interface Theme extends ThemeHibernate, ThemeUser
class ConcreteTheme implements Theme
The problem is that if I tell Hibernate I have a class hierarchy of "ConcreteTheme implements ThemeHibernate" (since I don't want it to see ThemeUser) then it won't let me cast any object I retrieve from DB from type ThemeHibernate to ThemeUser because in-so-far as it knows, there is no such thing as ThemeUser and ConcreteTheme doesn't extend it. To make matters worse, Hibernate will only allow mapped entities to extend one other mapped entity so it is technically impossible for me to tell it about the ThemeUser interface anyway.
Any ideas?
Gili
|
|
|
|
|
|
|
|
|
Re: Finer grained method access specifier
Posted:
May 4, 2005 5:25 AM
in response to: cowwoc
|
|
|
Let's have an semipublicbutnotquitesoabitofprotectedplease access specifier.
Maybe also an almostprivateexceptafewmethodsiwanttobepublicandthatfieldiwantprotected specifier as well.
|
|
|
|
|
|
|
|
|
Re: Finer grained method access specifier
Posted:
May 20, 2005 10:28 AM
in response to: jwenting
|
|
|
I think you don't miss the point of this request it would have been an amusing passage to read.
I am thinking though - could this be accomplished nicely with Annotations, since it has a far better syntactic flexibility (hence more expressive) than mere keywords in the Java Language?
|
|
|
|
|
java.net RSS
