I know that an interface must be public. However, I don't want that.
I want my implemented methods to only be accessible from their own package, so I want my implemented methods to be protected.
The problem is I can't make the interface or the implemented methods protected.
What is a work around? Is there a design pattern that pertains to this problem?
From the Java guide, an abstract class wouldn't do the job either.
read this.
"The public access specifier indicates that the interface can be used by any class in any package. If you do not specify that the interface is public, your interface will be accessible only to classes defined in the same package as the interface."
Is that what you want?
You class can use package protection and still implement an interface:
class Foo implements Runnable
{
public void run()
{
}
}
If you want some methods to be protected / package and others not, it sounds like your classes have more than one responsibility, and should be split into multiple.
Edit after reading comments to this and other responses:
If your are somehow thinking that the visibility of a method affects the ability to invoke that method, think again. Without going to extremes, you cannot prevent someone from using reflection to identify your class' methods and invoke them. However, this is a non-issue: unless someone is trying to crack your code, they're not going to invoke random methods.
Instead, think of private / protected methods as defining a contract for subclasses, and use interfaces to define the contract with the outside world.
Oh, and to the person who decided my example should use K&R bracing: if it's specified in the Terms of Service, sure. Otherwise, can't you find anything better to do with your time?
When I have butted up against this I use a package accessible inner or nested class to implement the interface, pushing the implemented method out of the public class.
Usually it's because I have a class with a specific public API which must implement something else to get it's job done (quite often because the something else was a callback disguised as an interface <grin>) - this happens a lot with things like Comparable. I don't want the public API polluted with the (forced public) interface implementation.
Hope this helps.
Also, if you truly want the methods accessed only by the package, you don't want the protected scope specifier, you want the default (omitted) scope specifier. Using protected will, of course, allow subclasses to see the methods.
BTW, I think that the reason interface methods are inferred to be public is because it is very much the exception to have an interface which is only implemented by classes in the same package; they are very much most often invoked by something in another package, which means they need to be public.
This question is based on a wrong statement:
I know that an interface must be public
Not really, you can have interfaces with default access modifier.
The problem is I can't make the interface or the implemented methods protected
Here it is:
C:\oreyes\cosas\java\interfaces>type a\*.java
a\Inter.java
package a;
interface Inter {
public void face();
}
a\Face.java
package a;
class Face implements Inter {
public void face() {
System.out.println( "face" );
}
}
C:\oreyes\cosas\java\interfaces>type b\*.java
b\Test.java
package b;
import a.Inter;
import a.Face;
public class Test {
public static void main( String [] args ) {
Inter inter = new Face();
inter.face();
}
}
C:\oreyes\cosas\java\interfaces>javac -d . a\*.java b\Test.java
b\Test.java:2: a.Inter is not public in a; cannot be accessed from outside package
import a.Inter;
^
b\Test.java:3: a.Face is not public in a; cannot be accessed from outside package
import a.Face;
^
b\Test.java:7: cannot find symbol
symbol : class Inter
location: class b.Test
Inter inter = new Face();
^
b\Test.java:7: cannot find symbol
symbol : class Face
location: class b.Test
Inter inter = new Face();
^
4 errors
C:\oreyes\cosas\java\interfaces>
Hence, achieving what you wanted, prevent interface and class usage outside of the package.
Here's how it could be done using abstract classes.
The only inconvenient is that it makes you "subclass".
As per the java guide, you should follow that advice "most" of the times, but I think in this situation it will be ok.
public abstract class Ab {
protected abstract void method();
abstract void otherMethod();
public static void main( String [] args ) {
Ab a = new AbImpl();
a.method();
a.otherMethod();
}
}
class AbImpl extends Ab {
protected void method(){
System.out.println( "method invoked from: " + this.getClass().getName() );
}
void otherMethod(){
System.out.println("This time \"default\" access from: " + this.getClass().getName() );
}
}
Here's another solution, inspired by the C++ Pimpl idiom.
If you want to implement an interface, but don't want that implementation to be public, you can create a composed object of an anonymous inner class that implements the interface.
Here's an example. Let's say you have this interface:
public interface Iface {
public void doSomething();
}
You create an object of the Iface type, and put your implementation in there:
public class IfaceUser {
private int someValue;
// Here's our implementor
private Iface impl = new Iface() {
public void doSomething() {
someValue++;
}
};
}
Whenever you need to invoke doSomething(), you invoke it on your composed impl object.
I just came across this trying to build a protected method with the intention of it only being used in a test case. I wanted to delete test data that I had stuffed into a DB table. In any case I was inspired by #Karl Giesing's post. Unfortunately it did not work. I did figure a way to make it work using a protected inner class.
The interface:
package foo;
interface SomeProtectedFoo {
int doSomeFoo();
}
Then the inner class defined as protected in public class:
package foo;
public class MyFoo implements SomePublicFoo {
// public stuff
protected class ProtectedFoo implements SomeProtectedFoo {
public int doSomeFoo() { ... }
}
protected ProtectedFoo pFoo;
protected ProtectedFoo gimmeFoo() {
return new ProtectedFoo();
}
}
You can then access the protected method only from other classes in the same package, as my test code was as show:
package foo;
public class FooTest {
MyFoo myFoo = new MyFoo();
void doProtectedFoo() {
myFoo.pFoo = myFoo.gimmeFoo();
myFoo.pFoo.doSomeFoo();
}
}
A little late for the original poster, but hey, I just found it. :D
You can go with encapsulation instead of inheritance.
That is, create your class (which won't inherit anything) and in it, have an instance of the object you want to extend.
Then you can expose only what you want.
The obvious disadvantage of this is that you must explicitly pass-through methods for everything you want exposed. And it won't be a subclass...
I would just create an abstract class. There is no harm in it.
With an interface you want to define methods that can be exposed by a variety of implementing classes.
Having an interface with protected methods just wouldn't serve that purpose.
I am guessing your problem can be solved by redesigning your class hierarchy.
One way to get around this is (depending on the situation) to just make an anonymous inner class that implements the interface that has protected or private scope. For example:
public class Foo {
interface Callback {
void hiddenMethod();
}
public Foo(Callback callback) {
}
}
Then in the user of Foo:
public class Bar {
private Foo.Callback callback = new Foo.Callback() {
#Override public void hiddenMethod() { ... }
};
private Foo foo = new Foo(callback);
}
This saves you from having the following:
public class Bar implements Foo.Callback {
private Foo foo = new Foo(this);
// uh-oh! the method is public!
#Override public void hiddenMethod() { ... }
}
I think u can use it now with Java 9 release. From the openJdk notes for Java 9,
Support for private methods in interfaces was briefly in consideration
for inclusion in Java SE 8 as part of the effort to add support for
Lambda Expressions, but was withdrawn to enable better focus on higher
priority tasks for Java SE 8. It is now proposed that support for
private interface methods be undertaken thereby enabling non abstract
methods of an interface to share code between them.
refer https://bugs.openjdk.java.net/browse/JDK-8071453
Related
I do have a service which needs to handle two types of meal.
#Service
class MealService {
private final List<MealStrategy> strategies;
MealService(…) {
this.strategies = strategies;
}
void handle() {
var foo = …;
var bar = …;
strategies.forEach(s -> s.remove(foo, bar));
}
}
There are two strategies, ‘BurgerStrategy’ and ‘PastaStrategy’. Both implements Strategy interface with one method called remove which takes two parameters.
BurgerStrategy class retrieves meals of enum type burger from the database and iterate over them and perform some operations. Similar stuff does the PastaStrategy.
The question is, does it make sense to call it Strategy and implement it this way or not?
Also, how to handle duplications of the code in those two services, let’s say both share the same private methods. Does it make sense to create a Helper class or something?
does it make sense to call it Strategy and implement it this way or not
I think these classes ‘BurgerStrategy’ and ‘PastaStrategy’ have common behaviour. Strategy pattern is used when you want to inject one strategy and use it. However, you are iterating through all behaviors. You did not set behaviour by getting one strategy and stick with it. So, in my honour opinion, I think it is better to avoid Strategy word here.
So strategy pattern would look like this. I am sorry, I am not Java guy. Let me show via C#. But I've provided comments of how code could look in Java.
This is our abstraction of strategy:
public interface ISoundBehaviour
{
void Make();
}
and its concrete implementation:
public class DogSound : ISoundBehaviour // implements in Java
{
public void Make()
{
Console.WriteLine("Woof");
}
}
public class CatSound : ISoundBehaviour
{
public void Make()
{
Console.WriteLine("Meow");
}
}
And then we stick with one behaviour that can also be replaced:
public class Dog
{
ISoundBehaviour _soundBehaviour;
public Dog(ISoundBehaviour soundBehaviour)
{
_soundBehaviour = soundBehaviour;
}
public void Bark()
{
_soundBehaviour.Make();
}
public void SetAnotherSound(ISoundBehaviour anotherSoundBehaviour)
{
_soundBehaviour = anotherSoundBehaviour;
}
}
how to handle duplications of the code in those two services, let’s say both share the same private methods.
You can create one base, abstract class. So basic idea is to put common logic into some base common class. Then we should create abstract method in abstract class. Why? By doing this, subclasses will have particular logic for concrete case. Let me show an example.
An abstract class which has common behaviour:
public abstract class BaseMeal
{
// I am not Java guy, but if I am not mistaken, in Java,
// if you do not want method to be overriden, you shoud use `final` keyword
public void CommonBehaviourHere()
{
// put here code that can be shared among subclasses to avoid code duplication
}
public abstract void UnCommonBehaviourShouldBeImplementedBySubclass();
}
And its concrete implementations:
public class BurgerSubclass : BaseMeal // extends in Java
{
public override void UnCommonBehaviourShouldBeImplementedBySubclass()
{
throw new NotImplementedException();
}
}
public class PastaSubclass : BaseMeal // extends in Java
{
public override void UnCommonBehaviourShouldBeImplementedBySubclass()
{
throw new NotImplementedException();
}
}
I am just wandering if following is an odd behaviour.
public interface TestInterfaceTwo {
public void sayBye();
}
public interface TestInterfaceOne {
public void sayHI();
}
public abstract class TestIntefaceClass implements TestInterfaceOne, TestInterfaceTwo {
#Override
public void sayHI() {
System.out.println("HI");
}
#Override
public void sayBye() {
System.out.println("Bye");
}
}
public class InterfaceImplementer extends TestIntefaceClass{
#Override
public void sayHI() {
System.out.println("SAY HI");
}
}
public static void main(String[] args) {
InterfaceImplementer impl = new InterfaceImplementer();
TestInterfaceOne impl1 = new InterfaceImplementer();
TestInterfaceTwo impl2 = new InterfaceImplementer();
TestIntefaceClass impl3 = new InterfaceImplementer();
impl.sayHI();
impl.sayBye();
impl1.sayHI();
impl2.sayBye();
impl.sayBye();
impl3.sayBye();
impl3.sayHI();
}
These calls result the following
SAY HI
Bye
SAY HI
Bye
Bye
Bye
SAY HI
I needed to know if interface instances inherit only the expected behavior from the interface or if it inherits the abstract class. It seems it does the latter and I would like to know an explanation for this and if it is bug Or a feature. :)
This works as expected. I am not entirely sure what is that confuses you.
I needed to know if interface instances inherit only the expected behavior from the interface or if it inherits the abstract class. It seems it does the latter and I would like to know an explanation for this and if it is bug Or a feature. :)
Interfaces don't implement any 'behaviour' (although Java 8 provides default methods) and you can't instantiate one. All those instances you're creating are class instances - in your case, instances of InterfaceImplementer. So let's look at this class and its parent:
TestIntefaceClass implements two interfaces and their methods. Nothing special here.
InterfaceImplementer extends TestIntefaceClass class, it inherits the implementation of sayBye() but it provides its own implementation of sayHi().
Now the following (and the other similar examples from your code)
TestInterfaceOne impl = new InterfaceImplementer();
creates an instance of InterfaceImplementer, as you can see on the right hand side. Thus the implementations that will be used when calling sayHi() and sayBye() will be the ones that Interfaceimplementer overrides / inherits.
LE: This link will probably be useful to you. It discusses using interfaces as types, which is what you're doing.
the "new InterfaceImplementer()" is giving you exactly that ... its just you are decalring them as the various ways .... it's working as expected
I am developing a java API. During my development, I keep facing the following issue:
I have two classes in two different packages. Class A in package x, and class B in package y. I need the class A to access a method M defined in class B. Hence, the modifier that should be used for the method M is public. However, I do not want to allow the developer who will use my API in his/her java application to access the method M. The problem is that the method M has a public modifier as I mentioned, and hence anyone can access it within the API or from outside the API. At the same time, if I decrease the modifier level of the method M to protected or private, the class A will not be able to access the method M because it belongs to a different package. How can I solve this problem? Is my only solution to have A and B in the same package?
Create an interface and expose only that to the public, hiding your implementation. For example:
My implementation (in say, for example, application.jar):
public class Test implements TestInterface {
public void somePrivateStuff() { }
public void somePublicStuff() { }
}
Dear world, here is my API (in say, for example, publicAPI.jar):
public interface TestInterface {
public void somePublicStuff();
}
Other developers would compile against your publicAPI.jar. The runtime implementation would come from your application.jar.
The only way to restrict access to specific classes is to make the method protected or package-private. Both only allow access within the package. I would suggest reformatting your package structure.
Inside the method, you can insert:
Throwable th = new Throwable().fillInStackTrace();
StackTraceElement element = th.getStackTrace()[TEST BETWEEN 3 AND 5];
if (element.getClassName().startsWith("your.package")) {
// CONTINUE YOUR METHOD.
}
else {
// USER ACCESSING FROM AN APPLICATION.
// THROW EXCEPTIONS, SHUTDOWN THE SYSTEM... DO WHAT YOU WANT.
}
On the second line, test between 3, 4 and 5, and see which one returns the correct element.getClassName().
You can split you project into 2: the public API and it implementation.
Define 2 interfaces for the class B:
The public interface for your library users (in API project).
Your inner interface that extends the public one and adds method M.
User will be dependent on you API in compilation and will get the implementation in the run-time.
You could use reflection. Here's an example.
package b;
public class B {
private void m() {
System.out.println("Called m()");
}
}
and
package a;
import b.B;
import java.lang.reflect.Method;
public class A {
public static void main(String[] args) throws Exception {
B b = new B();
Method m = B.class.getDeclaredMethod("m");
m.setAccessible(true);
m.invoke(b);
}
}
Which outputs
Called m()
This might seem like an odd thing to want, but is there a way in Java to stop subclasses from adding new methods (including constructors) whilst still allowing subclasses to override methods?
The actual situation is where we have an abstract class with some abstract methods and a constructor
abstract class A {
abstract A doX();
abstract boolean isY();
public A(String s){ ... };
}
and we want all concrete subclasses of this class to only override these methods and constructor.
This is about enforcing a certain style in our code i.e. stopping other people working on the code from adding things. We could just tell them not to, but that rarely works, so we wondered if there was a programmatic way of achieving this.
Obviously the class cannot be final. Efficiency isn't paramount - cleaner code is more important.
Update - dynamic approach
As has been pointed out in the answers, there is no way to do this statically as the only way to prevent subclasses being created is using final, which won't work. But I could use a dynamic approach so my current solution is to add this aspect to the project (which already uses AspectJ).
public aspect WatchA{
before() : execute(* A.*()) || execute(* A.*(..)) {
String methodCalled = joinPoint.getSignature().getName();
Class<?> c = Class.forName(args[0])
Method[] allMethods = c.getDeclaredMethods();
boolean found = false;
for(Method m : allMethods)
found |= m.getName().equals(methodCalled);
if(!found)
throw new RuntimeException("Do not add method "+methodCalled+" to A");
}
}
Which will cause their tests to fail if they use any of these new methods.
You cannot do that. Only if classes are final can you ensure that no subclass can be created.
You can also make methods final (even in abstract classes) so that overriding them is forbidden.
Your best bet is to create an interface, with all methods you want visible, and force all users of your API to access the objects via this interface. This way, even if implementations add their own stuff, said stuff won't be visible.
One solution for this is to implement a factory to return the concrete classes; for "added security", you could put all implementations in the same package as this factory and make constructors package local (but this is often not practical):
public final class MyFactory
{
// ....
public MyInterface getConcrete()
{
return new MyInterfaceImpl();
}
// etc etc -- getStones(), getTar(), getFeathers() and so on
}
Note that builders can also be used for that.
If you really wan't to do this.. one way would be to programatically check in the abstract class constructor that the methods defined in the class are those that are allowed.
import java.lang.reflect.Method;
import java.util.Arrays;
import java.util.HashSet;
import java.util.Set;
public abstract class Base {
private static final Set<String> allowedMethodNames = new HashSet<>(Arrays.asList("doThis", "wait", "wait", "wait", "equals", "toString", "hashCode", "getClass", "notify", "notifyAll"));
public Base() {
Set<String> allMethods = new HashSet<>();
for (Method aMethod : getClass().getMethods()) {
allMethods.add(aMethod.getName());
}
if (!allowedMethodNames.equals(allMethods)) {
allMethods.removeAll(allowedMethodNames);
throw new IllegalStateException("Following methods not allowed <" + allMethods + ">");
}
}
public abstract void doThis();
}
public class Disallowed extends Base {
#Override
public void doThis() {
System.out.println("dooooooo");
}
public void doSomethingElse() {
System.out.println("not allowed");
}
public static void main(String[] args) {
new Allowed().doThis();
new Disallowed();
}
}
public class Allowed extends Base {
#Override
public void doThis() {
System.out.println("doing this");
}
}
When someone is trying create an instance of 'Disallowed' it would fail. However 'new Allowed().doThis()' will work fine.
A more graceful way to do this would be to introduce a custom annotation + annotation processor and do the same check during the compilation time.
There is no such way.
Why would you want to enforce such a coding style?
If you really must enforce such a style you could create a "rule enforcer" which checks your classpath and compares the methods of your abstract parent classes with their sub classes.
It is Java which means flexibility. So java gives you more convinient in using the abstract methods and overriding them from your subclasses. Also one should have an idea of adding new methods to these subclasses. Even java can't change this. If it does then the whole Java community crash. It is impossible that you can prevent from adding methods to their subclasses. Only you can stop them extending your classes and overridding your methods.
Here is code:
IDefaultInterface.aj:
public interface IDefaultInterface {
public void m1();
static aspect Impl{
public int f1;
public void IDefaultInterface.m1(){
}
}
}
DefaulstInterfaceClass.java:
public class DefaultInterfaceClass implements IDefaultInterface {
#Override
public void m1() {
}
void mm() {
f1 = 9;
}
}
In the second piece of code I'm trying to override m1() method and access f1 field. The compiler allows neither one.
How to overcome these limitations?
Additional thoughts. I would not wonder so much if in "AspectJ in action" 2 edition wasn't said about using this idiom that effect should be the same "as extending the default implementation for both (if multiple inheritance was allowed in Java)." I believe that multiple inheritance associated with C++ for majority. So, why not provide the semantics to which people used to?
I'm not fluent in AspectJ, but I see a couple of questionable things: your aspect is trying to define a non-abstract method in an interface, and your class is trying to access field f1 as if it owns the field, when you've declared f1 on the aspect. I'm not quite sure what you're trying to do here, but I don't think you're going about it in the right way.
First of all I misspelled f1 declaration. It should be
public int IDefaultInterface.f1;
It solves access field problem.
The second problem is solved by using following code:
public interface IDefaultInterface {
public void m1();
public static interface Impl extends IDefaultInterface{
static aspect Implementation{
public int IDefaultInterface.Impl.f1;
public void IDefaultInterface.Impl.m1(){
}
}
}
}
And then:
public class DefaultInterfaceClass implements IDefaultInterface.Impl ....