Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #2959 > unrolled thread

Why only public methods on interfaces?

Back to article view | Back to comp.lang.java.programmer

Contents

  Why only public methods on interfaces? kramer31 <kramer.newsreader@gmail.com> - 2011-04-07 17:09 -0700
    Re: Why only public methods on interfaces? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-04-07 21:48 -0300
    Re: Why only public methods on interfaces? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-04-07 21:01 -0400
      Re: Why only public methods on interfaces? v_borchert@despammed.com (Volker Borchert) - 2011-04-08 02:43 +0000
        Re: Why only public methods on interfaces? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-04-08 00:24 -0400
    Re: Why only public methods on interfaces? Patricia Shanahan <pats@acm.org> - 2011-04-07 21:49 -0700
      Re: Why only public methods on interfaces? Owen Jacobson <angrybaldguy@gmail.com> - 2011-04-08 01:01 -0400
        Re: Why only public methods on interfaces? Patricia Shanahan <pats@acm.org> - 2011-04-07 22:37 -0700
          Re: Why only public methods on interfaces? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-04-08 00:14 -0700
            Re: Why only public methods on interfaces? Patricia Shanahan <pats@acm.org> - 2011-04-08 06:59 -0700
              Re: Why only public methods on interfaces? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-04-08 07:17 -0700
                Re: Why only public methods on interfaces? Patricia Shanahan <pats@acm.org> - 2011-04-08 08:59 -0700
                  Re: Why only public methods on interfaces? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-04-08 17:27 -0700
                  Re: Why only public methods on interfaces? "Mike Schilling" <mscottschilling@hotmail.com> - 2011-04-09 22:14 -0700
                  Re: Why only public methods on interfaces? "Mike Schilling" <mscottschilling@hotmail.com> - 2011-04-09 22:28 -0700
                    Re: Why only public methods on interfaces? Tom Anderson <twic@urchin.earth.li> - 2011-04-10 16:02 +0100
    Re: Why only public methods on interfaces? Roedy Green <see_website@mindprod.com.invalid> - 2011-04-08 03:18 -0700
      Re: Why only public methods on interfaces? Esmond Pitt <esmond.pitt@bigpond.com> - 2011-04-08 20:32 +1000
    Re: Why only public methods on interfaces? Tom Anderson <twic@urchin.earth.li> - 2011-04-08 20:34 +0100
    Re: Why only public methods on interfaces? Tom Anderson <twic@urchin.earth.li> - 2011-04-10 18:10 +0100

#2959 — Why only public methods on interfaces?

Could someone please explain to me the rational behind only allowing
public methods on interfaces?  In my mind, protection and interfaces
are two independent if perhaps somewhat related concepts.

For instance, I have an aspect which creates a proxy of a given
interface (which handles transaction propagation).  Now in order to
use this aspect, I need an interface (otherwise, no proxy can be
created).  However, I have some methods on this class which I would
like to proxy which are public, some are protected, some are package.
Because of this stupid restriction, I have to make all of the methods
public, or do ridiculous things with protection on inner classes.

There are other examples, too.  In fact one could imagine a case where
one would only want protected methods on an interface.

Yuck, Java, yuck.

[toc] | [next] | [standalone]

#2961

On 11-04-07 09:09 PM, kramer31 wrote:
> Could someone please explain to me the rational behind only allowing
> public methods on interfaces?  In my mind, protection and interfaces
> are two independent if perhaps somewhat related concepts.
> 
> For instance, I have an aspect which creates a proxy of a given
> interface (which handles transaction propagation).  Now in order to
> use this aspect, I need an interface (otherwise, no proxy can be
> created).  However, I have some methods on this class which I would
> like to proxy which are public, some are protected, some are package.
> Because of this stupid restriction, I have to make all of the methods
> public, or do ridiculous things with protection on inner classes.
> 
> There are other examples, too.  In fact one could imagine a case where
> one would only want protected methods on an interface.
> 
> Yuck, Java, yuck.

I can't agree with your take on things here, with all due respect. To me
that is what an interface is for - it's the set of public methods that
you want an implementing object, including a proxy, to present to the
rest of the world.

And proxies in Java, by definition, implement a list of interfaces.
That's what they are for.

Maybe it's just me, but if I wanted an object that implemented public,
protected and private methods, I'd construct an instance of a class that
defines all those methods. Is there any reason you can't have a class
that implements the transaction interface in question?

AHS

-- 
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

[toc] | [prev] | [next] | [standalone]

#2963

On 04/07/2011 08:09 PM, kramer31 wrote:
> Could someone please explain to me the rational behind only allowing
> public methods on interfaces?  In my mind, protection and interfaces
> are two independent if perhaps somewhat related concepts.

An interface is a public contract of methods that an object guarantees 
it will support. In my view, the idea of an interface is that you are 
letting someone else do the implementing. That "someone else" part 
implies that the methods can't be package-protected, since it might not 
be in your package. Private interface methods would of course be 
useless, and protected methods would be severely limited to only the 
implementing classes. In my mind, protected means "it's really private, 
but you need to have your children see or use them", which suggests that 
a protected method is inherently tied up in the implementation as 
opposed to an interface.

> For instance, I have an aspect which creates a proxy of a given
> interface (which handles transaction propagation).  Now in order to
> use this aspect, I need an interface (otherwise, no proxy can be
> created).  However, I have some methods on this class which I would
> like to proxy which are public, some are protected, some are package.
> Because of this stupid restriction, I have to make all of the methods
> public, or do ridiculous things with protection on inner classes.

You can use abstract classes where reasonable; where not reasonable, it 
is also possible to make top-level package-private interfaces.

> There are other examples, too.  In fact one could imagine a case where
> one would only want protected methods on an interface.

I would use an abstract class in that case. Think about stuff like an 
AbstractDefaultImpl class, which implements most of the methods on top 
of a simpler protected interface.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#2970

Joshua Cranmer wrote:
> You can use abstract classes where reasonable;

No, you can't, at least in some cases, because Java does not support
multiple inheritance... and there are cases where the memory overhead
of a Delegate is not tolerable.

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

[toc] | [prev] | [next] | [standalone]

#2976

On 04/07/2011 10:43 PM, Volker Borchert wrote:
> Joshua Cranmer wrote:
>> You can use abstract classes where reasonable;
>
> No, you can't, at least in some cases, because Java does not support
> multiple inheritance... and there are cases where the memory overhead
> of a Delegate is not tolerable.

I said "where reasonable" did I not? I know that multiple inheritance 
renders flaws in using abstract classes, etc., etc., etc... but, given 
the little I know of this use case, abstract classes seem like a 
feasible way to go.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#2978

On 4/7/2011 5:09 PM, kramer31 wrote:
> Could someone please explain to me the rational behind only allowing
> public methods on interfaces?  In my mind, protection and interfaces
> are two independent if perhaps somewhat related concepts.

I think the original Java design underestimated the extreme usefulness
of Java interfaces. At the time one of their uses, representing the
public face of a package, was assumed to be the only possible use.

I've wanted to use intra-package interfaces, containing only default
access methods. There is an unpleasant choice between making something
that should be an interface into an abstract class or having public
methods that are supposed to only be used within one package.

Patricia

[toc] | [prev] | [next] | [standalone]

#2980

On 2011-04-08 00:49:02 -0400, Patricia Shanahan said:

> On 4/7/2011 5:09 PM, kramer31 wrote:
>> Could someone please explain to me the rational behind only allowing
>> public methods on interfaces?  In my mind, protection and interfaces
>> are two independent if perhaps somewhat related concepts.
> 
> I think the original Java design underestimated the extreme usefulness
> of Java interfaces. At the time one of their uses, representing the
> public face of a package, was assumed to be the only possible use.
> 
> I've wanted to use intra-package interfaces, containing only default
> access methods. There is an unpleasant choice between making something
> that should be an interface into an abstract class or having public
> methods that are supposed to only be used within one package.

As Stefan pointed out, interfaces themselves don't have to be public. 
This is legal:

package com.example;

interface SomeInternalAbstraction {
	public void flog(Horse horse);
}

-o

[toc] | [prev] | [next] | [standalone]

#2982

On 4/7/2011 10:01 PM, Owen Jacobson wrote:
> On 2011-04-08 00:49:02 -0400, Patricia Shanahan said:
>
>> On 4/7/2011 5:09 PM, kramer31 wrote:
>>> Could someone please explain to me the rational behind only allowing
>>> public methods on interfaces? In my mind, protection and interfaces
>>> are two independent if perhaps somewhat related concepts.
>>
>> I think the original Java design underestimated the extreme usefulness
>> of Java interfaces. At the time one of their uses, representing the
>> public face of a package, was assumed to be the only possible use.
>>
>> I've wanted to use intra-package interfaces, containing only default
>> access methods. There is an unpleasant choice between making something
>> that should be an interface into an abstract class or having public
>> methods that are supposed to only be used within one package.
>
> As Stefan pointed out, interfaces themselves don't have to be public.
> This is legal:
>
> package com.example;
>
> interface SomeInternalAbstraction {
> public void flog(Horse horse);
> }
>
> -o
>

Yes, but then the implementing methods do have to be public, which is
undesirable if they should not be used outside the package.

Patricia

[toc] | [prev] | [next] | [standalone]

#2987

On 4/7/11 10:37 PM, Patricia Shanahan wrote:
> [...]
>> As Stefan pointed out, interfaces themselves don't have to be public.
>> This is legal:
>>
>> package com.example;
>>
>> interface SomeInternalAbstraction {
>> public void flog(Horse horse);
>> }
>>
>> -o
>>
>
> Yes, but then the implementing methods do have to be public, which is
> undesirable if they should not be used outside the package.

The implementing type doesn't have to be public either.

Perhaps a future version of Java will include a feature C# offers: 
explicit implementation of an interface.  In C#, one can implement an 
interface implicitly as in Java, in which case if the implementing type 
is visible, then yes…one has access to the public members of that type 
that implement the interface.

But one can also implement interfaces explicitly, necessarily implying 
that a member is private, used only to implement an interface:

   interface IA { void A(); }

   class A : IA { void IA.A(); }

In that case, one can only call IA.A through an interface reference, and 
not a reference typed as A:

   A a = new A();
   IA ia = a;

   ia.A(); // legal
   a.A(); // not legal

In the meantime, in Java if you don't want the implemented methods 
called, just keep the implementing type non-public as well.

Pete

[toc] | [prev] | [next] | [standalone]

#2992

On 4/8/2011 12:14 AM, Peter Duniho wrote:
> On 4/7/11 10:37 PM, Patricia Shanahan wrote:
>> [...]
>>> As Stefan pointed out, interfaces themselves don't have to be public.
>>> This is legal:
>>>
>>> package com.example;
>>>
>>> interface SomeInternalAbstraction {
>>> public void flog(Horse horse);
>>> }
>>>
>>> -o
>>>
>>
>> Yes, but then the implementing methods do have to be public, which is
>> undesirable if they should not be used outside the package.
>
> The implementing type doesn't have to be public either.

How do you know that? Of course, implementing the interface does not
require it to be public, but the class may also be part of the public
face of the package.

Patricia

[toc] | [prev] | [next] | [standalone]

#2993

On 4/8/11 6:59 AM, Patricia Shanahan wrote:
> [...]
>>> Yes, but then the implementing methods do have to be public, which is
>>> undesirable if they should not be used outside the package.
>>
>> The implementing type doesn't have to be public either.
>
> How do you know that? Of course, implementing the interface does not
> require it to be public, but the class may also be part of the public
> face of the package.

Since it's an implementation choice, you can just as easily choose to 
implement the interface in a non-public class.

[toc] | [prev] | [next] | [standalone]

#2994

On 4/8/2011 7:17 AM, Peter Duniho wrote:
> On 4/8/11 6:59 AM, Patricia Shanahan wrote:
>> [...]
>>>> Yes, but then the implementing methods do have to be public, which is
>>>> undesirable if they should not be used outside the package.
>>>
>>> The implementing type doesn't have to be public either.
>>
>> How do you know that? Of course, implementing the interface does not
>> require it to be public, but the class may also be part of the public
>> face of the package.
>
> Since it's an implementation choice, you can just as easily choose to
> implement the interface in a non-public class.

Yes, it is often possible to work around the public-methods-only
limitation, in several different ways, including a non-public inner
class object that implements the interface on behalf of its surrounding
class.

Interfaces would have been even more useful than they are now if it were
not necessary to work around the limitation.

The really unfortunate decision is not the public methods only, but the
decision to make non-specification of access mean public interface
method declarations but package access in class method declarations.
That cuts off any possibility of changing interfaces now to make them
more flexible.

Patricia

[toc] | [prev] | [next] | [standalone]

#3001

On 4/8/11 8:59 AM, Patricia Shanahan wrote:
> [...]
> The really unfortunate decision is not the public methods only, but the
> decision to make non-specification of access mean public interface
> method declarations but package access in class method declarations.
> That cuts off any possibility of changing interfaces now to make them
> more flexible.

You mean other than following the example of C#.

I realize that's anathema to the designers of Java, but it _could_ be 
done and it _would_ address the specific concern voiced here.

Pete

[toc] | [prev] | [next] | [standalone]

#3018

"Patricia Shanahan" <pats@acm.org> wrote in message 
news:58-dnYYCMK1urQLQnZ2dnUVZ_gGdnZ2d@earthlink.com...
>
> The really unfortunate decision is not the public methods only, but the
> decision to make non-specification of access mean public interface
> method declarations but package access in class method declarations.
> That cuts off any possibility of changing interfaces now to make them
> more flexible.

Unless new syntax like "package-private" is introduced. 

[toc] | [prev] | [next] | [standalone]

#3019

"Patricia Shanahan" <pats@acm.org> wrote in message 
news:58-dnYYCMK1urQLQnZ2dnUVZ_gGdnZ2d@earthlink.com...
>
> The really unfortunate decision is not the public methods only, but the
> decision to make non-specification of access mean public interface
> method declarations but package access in class method declarations.
> That cuts off any possibility of changing interfaces now to make them
> more flexible.

Actually, you could make an argument that "protected" on an interface method 
would mean "only visible within the package", because it can't mean "and 
also visible to derived types". 

[toc] | [prev] | [next] | [standalone]

#3020

On Sat, 9 Apr 2011, Mike Schilling wrote:

> "Patricia Shanahan" <pats@acm.org> wrote in message 
> news:58-dnYYCMK1urQLQnZ2dnUVZ_gGdnZ2d@earthlink.com...
>
>> The really unfortunate decision is not the public methods only, but the 
>> decision to make non-specification of access mean public interface 
>> method declarations but package access in class method declarations. 
>> That cuts off any possibility of changing interfaces now to make them 
>> more flexible.
>
> Actually, you could make an argument that "protected" on an interface 
> method would mean "only visible within the package", because it can't 
> mean "and also visible to derived types".

It could mean 'visible to types derived from implementors of the 
interface'. It would mostly act to constrain the access modifier on the 
implementing method.

If you interpreted interface-protected your way, you would have to permit 
implementors to declare their implementations package-access, otherwise it 
would be pointless, and that would mean that you would be writing 
implementations that appeared to have a narrower access modifier than 
their specification.

In code:

package x;

public interface I {
 	protected void m();
}

public class A implements I {
 	protected void m() {} // legal, looks normal, but widens access!
}

public class B implements I {
 	/*package*/ void m() {} // is this legal?
}

package y;

class C extends x.A {
 	void foo() {
 		m(); // i probably shouldn't be able to do this
 		I i = this;
 		i.m(); // i won't be able to do this
 	}
}

Which is why ...

On Sat, 9 Apr 2011, Mike Schilling wrote:

> Unless new syntax like "package-private" is introduced.

That seems like a very good idea. Indeed, a future revision of the 
language could do that, and at the same time deprecate the omission of an 
access modifier altogether.

What i'd really like to see is a slightly more complicated but much more 
expressive system of access control. I worked this out with a friend a 
while ago, and i think the model should be:

1. The universe consists of a tree of things: the leaves are features 
(fields and methods), and the branches are containers (packages and 
classes - classes are also features in some ways, and i don't think that 
causes any difficulty), with the root being the default package. Packages 
can contain packages and classes; classes can contain classes and 
features.

2. Every feature explicitly exposes itself at one scope; it is visible to 
any code defined within that scope, including nested scopes. 'public' 
means it is exposed to the default package. 'private' means that it is 
exposed to the outermost enclosing class. This is as now. A new modifier 
'package' means that it is exposed to the innermost enclosing package. 
This differs from the current default in that it is visible to subpackages 
(the current default is not visible in subpackages, although it is visible 
in nested classes in the same package). The lack of an explicit modifier 
would elicit a compiler warning, and be treated the same as 'package' 
(this widens access to these features, but in a backwards-compatible way).

3. In addition to these simple modifiers, it is possible to explicitly 
specify an exposure scope - this can be any scope enclosing the feature. 
The syntax i would use would be 'private(name.of.scope)'. 'public' is thus 
shorthand for 'private()', 'package' is shorthand for 
'private(innermost.enclosing.package)', and 'private' is shorthand for 
'private(outermost.enclosing.class)'. The scope name is resolved in the 
usual way, so scopes which are classes would not need to be fully 
qualified.

4. In addition to the exposure scope, a feature can be made visible to 
subclasses of its defining class, whatever package they may be in. This is 
done by replacing 'private' with 'protected'; this accepts an explicit 
scope in the same way as 'private'. The natural exposure scope for an 
unqualified 'protected' would be the same as for an unqualified 'private', 
ie the outermost enclosing class, but this would break backwards 
compatibility, so sadly, it must mean 
'protected(innermost.enclosing.package)'. Perhaps we should allow a 
shorthand for the outermost enclosing class, perhaps 'this', so you could 
write 'protected(this)' to allow access only to subclasses and inner 
classes.

The main thing that this gives you is a way to make features visible 
across packages in a hierarchy. This is a frequent problem in large 
projects which are intended to be modules in a larger world (eg on a vast 
project, or libraries for public consumption); a class in org.foo.io might 
need to be visible to one in org.foo or org.foo.core, but should not be 
visible to unrelated code in com.bar. Similarly, methods in a class in 
org.foo often need to be accessible to classes in org.foo.io, but not 
com.bar. At present, you end up with public methods marked 'PRIVATE API, 
DO NOT USE', which is total rubbish. The proposed access system would let 
you scope all these methods to org.foo, and have them visible to 
everything in the project.

What it no longer lets you do is have things in org.foo that are *not* 
visible throughout the project. However, i would suggest that such things 
really belong in a subpackage. The parent package should be minimal, and 
only contain things for general consumption.

It also lets you have features which are visible to subclasses but not the 
rest of the package, which is something i have always wanted.

If we extend the explicit scope notation to accept multiple exposure 
scopes, then we have essentially copied the C++ friend mechanism. That 
would let me solve the classic JPA problem of how i stop unrelated classes 
calling the internal-use-only innerWhatever methods in this scenario (this 
is actually a slight variation in the classic pattern, but i hope it's 
clear):

@Entity
public class Department {
 	@OneToMany(mappedBy="dept")
 	private List<Employee> employees;

 	public void addEmployee(Employee emp) {
 		emp.setDepartment(this);
 	}

 	public void removeEmployee(Employee emp) {
 		emp.setDepartment(null);
 	}

 	void innerAddEmployee(Employee emp) {
 		employees.add(emp);
 	}

 	void innerRemoveEmployee(Employee emp) {
 		employees.remove(emp);
 	}
}

@Entity
public class Employee {
 	@ManyToOne
 	private Department dept;

 	public void setDepartment(Department dept) {
 		if (this.dept != null) this.dept.innerRemoveEmployee(this);
 		if (dept != null) dept.innerAddEmployee(this);
 		this.dept = dept;
 	}
}

At the moment, the methods have to be at least package-access, because 
Employee needs to be able to call them. But with the proposed mechanism, i 
could declare them:

 	private(Employee) void innerAddEmployee(Employee emp)
 	private(Employee) void innerRemoveEmployee(Employee emp)

And access would be restricted to just where they were needed.

Compared to C++'s friendship system (which i don't understand well, so 
correct me if i'm wrong), we have finer-grained control over what is 
exposed (individual features, rather than all the features in the class), 
but coarser-grained control over who we expose it to (classes, rather than 
individual methods). The former is clearly better, because it means we can 
expose the things we need to, whilst keeping most details of the class 
encapsulated. I would argue that the latter is also better, because the 
exposing class has no business knowing which particular methods of the 
friend class are going to make use of the exposure; in the above example, 
i want to be free to refactor the calls from Employee to Department.inner* 
into a separate method (perhaps updateDepartmentEmployeeLists), without 
having to modify Department (particularly because it might be a private 
method - in which case in C++, Department would have to know about a 
private method of Employee!).

tom

-- 
A military-industrial illusion of democracy

[toc] | [prev] | [next] | [standalone]

#2990

On Thu, 7 Apr 2011 17:09:51 -0700 (PDT), kramer31
<kramer.newsreader@gmail.com> wrote, quoted or indirectly quoted
someone who said :

>Could someone please explain to me the rational behind only allowing
>public methods on interfaces?  In my mind, protection and interfaces
>are two independent if perhaps somewhat related concepts.

Interfaces are for gluing things together that have different
ancestries.  If you could specify that at interface were package
scope, which you would limit all implementors to being in the
interface's package.  In that case, you might as well use an abstract
class.

I too have often wanted non-public methods in interfaces, but that is
a possible rationale why they are always public.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Doing what the user expects with respect to navigation is absurdly important for user satisfaction.
~ anonymous Google Android developer

[toc] | [prev] | [next] | [standalone]

#2991

On 8/04/2011 8:18 PM, Roedy Green wrote:
> If you could specify that at interface were package
> scope

... which you can ...

, which you would limit all implementors to being in the
> interface's package.

... which again you can.

> In that case, you might as well use an abstract
> class.

Or an interface.

> I too have often wanted non-public methods in interfaces, but that is
> a possible rationale why they are always public.

It doesn't have anything to do with it. Interfaces themselves can be 
specified without an access modifier, which gives them package access; 
and nested interfaces can have any of the access modifiers.

The OP is asking about the access to what is *inside* the interface.

[toc] | [prev] | [next] | [standalone]

#2997

On Thu, 7 Apr 2011, kramer31 wrote:

> Could someone please explain to me the rational behind only allowing
> public methods on interfaces?  In my mind, protection and interfaces
> are two independent if perhaps somewhat related concepts.
>
> For instance, I have an aspect which creates a proxy of a given
> interface (which handles transaction propagation).  Now in order to
> use this aspect, I need an interface (otherwise, no proxy can be
> created).  However, I have some methods on this class which I would
> like to proxy which are public, some are protected, some are package.
> Because of this stupid restriction, I have to make all of the methods
> public, or do ridiculous things with protection on inner classes.
>
> There are other examples, too.  In fact one could imagine a case where
> one would only want protected methods on an interface.

Do you have any examples of this problem that don't involve the horrific 
crime against nature that is aspect-oriented programming?

tom

-- 
the logical extension of a zero-infinity nightmare topology

[toc] | [prev] | [next] | [standalone]

#3022

[Multipart message — attachments visible in raw view] — view raw

On Sun, 10 Apr 2011, Stefan Ram wrote:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>> A proxy could use several interfaces, one for public methods,
>>> one for private methods. But »private« to whom?
>> I want to give an example for what I was thinking about:
>
>  Two compilets (aka SSCCEs):
>
>  First: Make some methods of the interface callable only from
>  a certain scope in a way so that calls from other scopes
>  will be refuted already at compile time.
>
>  [snip]
>
> public class Main
> { public static void main( final java.lang.String[] args )
>  {
>    /* Can't get direct access to method( Key ) from here. */

Yes you can:

      publicInterface.method(null);

For this technique to be effective, there has to be a null check in the 
method. Even then, it will be a runtime error, not a compile-time error, 
when it is called from outside the intended scope.

Your second technique does work, though, because it requires the caller to 
be able to provide an instance of the hidden Acceptor type. Another way of 
using that, which i think gives you static safety, is:

public class PublicFace {
 	public class PrivateFace { // intended private
 		public void secret() {}
 	}
 	private PrivateFace hyde = new PrivateFace();
 	private static class Extractor {
 		public static final Extractor THIS = new Extractor();
 		public PrivateFace extract(PublicFace jekyll) {
 			return jekyll.hyde;
 		}
 	}

 	public static void insider(PublicFace jekyll) {
 		Extractor.THIS.extract(jekyll).secret();
 	}
}

public class Main {
 	public static void outsider(PublicFace jekyll) {
 		// i claim that there is no way to write an expression of type Extractor here
 		// without that, you cannot possibly extract hyde from jekyll
 	}
}

tom

-- 
I am the best at what i do.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web