Интерфейсы в Java: нельзя сделать реализованные методы защищенными или частными

Вы, класс, можете использовать защиту пакетов и по-прежнему реализовывать интерфейс:

class Foo implements Runnable 
{
    public void run()
    {
    }
}

Если вы хотите, чтобы некоторые методы были защищены / упакованы, а другие нет, похоже, что ваши классы имеют более одной ответственности и должны быть разделены на несколько.

Отредактируйте после прочтения комментариев к этому и другим ответам:

Если вы почему-то думаете, что видимость метода влияет на возможность его вызова, подумайте еще раз. Не впадая в крайности, вы не можете помешать кому-либо использовать отражение для идентификации методов вашего класса и их вызова. Однако это не проблема: если кто-то не пытается взломать ваш код, он не будет вызывать случайные методы.

Вместо этого думайте о частных / защищенных методах как об определении контракта для подклассов и используйте интерфейсы для определения контракта с внешним миром.

Да, и тому, кто решил, что мой пример следует использовать распорки K&R: если это указано в Условиях обслуживания, конечно. В противном случае, разве вы не можете найти что-нибудь лучше, чем заняться со своим временем?

Когда я столкнулся с этим, я использую внутренний или вложенный класс, доступный для пакета, для реализации интерфейса, выталкивая реализованный метод из общедоступного класса.

Обычно это потому, что у меня есть класс с конкретным общедоступным API, который должен реализовывать что-то еще, чтобы выполнить свою работу (довольно часто потому, что что-то еще было обратным вызовом, замаскированным под интерфейс ‹grin›) - это часто случается с такими вещами, как Comparable. Я не хочу, чтобы публичный API был загрязнен (принудительно публичной) реализацией интерфейса.

Надеюсь это поможет.

Кроме того, если вы действительно хотите, чтобы методы были доступны только для пакета, вам не нужен описатель защищенной области, вам нужен описатель области по умолчанию (опущен). Использование protected, конечно же, позволит подклассам видеть методы.

Кстати, я думаю, что причина, по которой методы интерфейса считаются общедоступными, заключается в том, что в значительной степени исключение имеет интерфейс, который реализуется только классами в том же пакете; они очень часто вызываются чем-то в другом пакете, что означает, что они должны быть общедоступными.

Этот вопрос основан на неверном утверждении:

Я знаю, что интерфейс должен быть общедоступным

Не совсем, у вас могут быть интерфейсы с модификатором доступа по умолчанию.

Проблема в том, что я не могу защитить интерфейс или реализованные методы

Вот:

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>

Следовательно, достигнув желаемого, предотвратите использование интерфейса и класса за пределами пакета.

Вот как это можно сделать с помощью абстрактных классов.

Единственное неудобство - это то, что он делает вас «подклассом».

Согласно руководству по java, вы должны следовать этому совету "в большинстве" случаев, но я думаю, что в этой ситуации все будет нормально.

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()  );
    }
}

Вот еще одно решение, вдохновленное идиомой C ++ Pimpl.

Если вы хотите реализовать интерфейс, но не хотите, чтобы эта реализация была общедоступной, вы можете создать составной объект анонимного внутреннего класса, который реализует интерфейс.

Вот пример. Допустим, у вас есть такой интерфейс:

public interface Iface {
    public void doSomething();
}

Вы создаете объект типа Iface и помещаете туда свою реализацию:

public class IfaceUser {
    private int someValue;
    // Here's our implementor
    private Iface impl = new Iface() {
        public void doSomething() {
            someValue++;
        }
    };
}

Всякий раз, когда вам нужно вызвать doSomething(), вы вызываете его на своем составном объекте impl.

Я только что наткнулся на это, пытаясь создать защищенный метод с намерением использовать его только в тестовом примере. Я хотел удалить тестовые данные, которые я поместил в таблицу БД. В любом случае меня вдохновил @Karl Giesing / a / 24395109/1024005 "> post. К сожалению, это не сработало. Я нашел способ заставить его работать, используя защищенный внутренний класс.

Интерфейс:

package foo;
interface SomeProtectedFoo {
    int doSomeFoo();
}

Затем внутренний класс определяется как защищенный в общедоступном классе:

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();
    }
}

Затем вы можете получить доступ к защищенному методу только из других классов в том же пакете, как показано в моем тестовом коде:

package foo;
public class FooTest {
    MyFoo myFoo = new MyFoo();
    void doProtectedFoo() {
        myFoo.pFoo = myFoo.gimmeFoo();
        myFoo.pFoo.doSomeFoo();
    }
}

Немного поздно для оригинального плаката, но эй, я только что его нашел. : D

Вы можете использовать инкапсуляцию вместо наследования.

То есть создайте свой класс (который ничего не наследует) и в нем есть экземпляр объекта, который вы хотите расширить.

Тогда вы сможете выставлять только то, что хотите.

Очевидным недостатком этого является то, что вы должны явно передавать методы для всего, что вы хотите раскрыть. И это не будет подкласс ...

Я бы просто создал абстрактный класс. В этом нет ничего плохого.

С помощью интерфейса вы хотите определить методы, которые могут быть предоставлены множеством реализующих классов. Наличие интерфейса с защищенными методами просто не служит этой цели.

Я предполагаю, что вашу проблему можно решить, изменив иерархию классов.

Один из способов обойти это (в зависимости от ситуации) - просто создать анонимный внутренний класс, реализующий интерфейс с областью видимости protected или private. Например:

public class Foo {
    interface Callback {
        void hiddenMethod();
    }

    public Foo(Callback callback) {
    }
}

Затем в пользователе Foo:

public class Bar {
    private Foo.Callback callback = new Foo.Callback() { 
        @Override public void hiddenMethod() { ... }
    };
    private Foo foo = new Foo(callback);
}

Это избавит вас от следующего:

public class Bar implements Foo.Callback {
    private Foo foo = new Foo(this);

    // uh-oh! the method is public!
    @Override public void hiddenMethod() { ... }
}

Думаю, теперь вы можете использовать его с выпуском Java 9. Из заметок openJdk для Java 9,

Поддержка частных методов в интерфейсах кратко рассматривалась для включения в Java SE 8 как часть усилий по добавлению поддержки лямбда-выражений, но была отменена, чтобы лучше сосредоточиться на задачах с более высоким приоритетом для Java SE 8. Теперь предлагается, чтобы поддержка для методов частного интерфейса, тем самым позволяя неабстрактным методам интерфейса совместно использовать код между собой.

см. https://bugs.openjdk.java.net/browse/JDK-8071453