Действительно ли возможно скрыть или понизить доступ к Унаследованным методам в Java?

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

Возможно, если вы объясните , почему вы хотите сделать это , вы можете получить несколько советов по , как .

При переопределении метода вы можете сделать его только общедоступным , а не более частным. Я не знаю, почему вы используете слово «общий»

. Помните, что в порядке от наименее ограничительного к наиболее строгому:

public<protected<default<private

Да, « защищенный » является модификатором доступа с меньшими ограничениями, чем default (когда модификатор не используется), поэтому вы можете переопределить метод по умолчанию, пометив метод переопределения как protected , но не делать наоборот.

Банка: Вы можете заменить защищенный метод на открытый метод.

Невозможно: Вы не можете заменить общедоступный метод на защищенный метод.

Если бы вы сделали это, то DerivedOne не был бы Базой с точки зрения DerivedTwo. Вместо этого вам нужен класс-оболочка

//Uses myMethod but keeps it hidden
public class HiddenBase {
    private final Base base = new Base();
    private void myMethod();
    public void otherMethod() {base.otherMethod();}
}

Вы не можете получить доступ к защищенным методам базы, хотя таким образом ...

Наследование работает, потому что везде, где вы можете использовать базовый класс, вы также можете использовать один из его подклассов. Поведение может быть другим, но API - нет. Эта концепция известна как принцип подстановки Лискова .

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

То, что вы действительно хотите сделать, можно сделать с помощью интерфейсов:

interface IBase1 {
}

class Derived1 implements IBase1 {
  public void myMethod() {
  }
}

class Derived2 implements IBase1 {
}

class UseMe {
  public void foo(IBase1 something) {
     // Can take both Derived1 and Derived2
     // Can not call something.myMethod()
  }
  public void foo(Derived1 something) {
     something.myMethod();
  }
  public void foo(Derived2 something) {
    // not something.myMethod()
  }
}

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

рассмотрите следующее:

package a;

public class Base {
    void myMethod() {
        System.out.println("a");
    }
}

package a;

public class DerivedOne extends Base {
    @Override
    void myMethod() {
        System.out.println("b");
    }
}

package b;

public class DerivedTwo extends a.DerivedOne {
    public static void main(String... args) {
        myMethod(); // this does not compile...
    }
}

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

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

Если вы наследуете от базовых классов, у вас есть отсутствие контроля над этим может создать проблему, вы можете сделать метод недоступным для других, вызвав исключение, сделав унаследованный код доступным для ваших классов, вызвав super напрямую, что-то вроде:

// Uses myMethod and then hides it.
public class DerivedOne extends Base {
    @Override
    public void myMethod() {
        throw new IllegalStateException("Illegal access to myMethod");
    }

    private void myPrivateMethod() {
        super.myMethod();
    }

}

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

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

Интерфейс будет реализован в виде (статического?) Вложенного внутри среднего класса. То, что я имею в виду, выглядит так:

public interface Specific {
    public void doSomething();
}

public class Base {
    private final Specific specificImpl;

    protected Base(Specific s) {
        specificImpl = s;
    }

    public void doAlot() {

         // ...

         specificImpl.doSomething();

         // ...
    }
}

public class Middle extends Base {

    public Middle() {
        super(new Impl());
    }

    private Impl implements Specific {

        public void doSomething() {

            System.out.println("something done");
        }
    }
}

public class Derived extends Middle {

    // Access to doAlot()
    // No access to doSomething()
}