Какая польза от менее строгих модификаторов доступа к членам, чем модификатор доступа к классу? - PullRequest
8 голосов
/ 08 октября 2019

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

Конкретный пример может быть:

package apples;

class A { // package private
    public int foo() { // public (=> less restrictive than *package private*)
        return 42;
    }
}

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

  • Правильно ли мое понимание?
    • Если нет, каковы последствия?
  • Какие могут быть веские причины иметь менее строгие модификаторы доступа к элементам?
  • Наконец, какие есть передовой опыт , которому нужно следовать?

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

Ситуация, которую я построил, следующая:

  • apples.B предоставляет открытый метод bla(), который возвращает ссылку на apples.A.foo.
  • Затем pizzas.C вызывает apples.B.bla, чтобы получить ссылку на A.foo и вызывает ее.
  • Так что A.foo() не виден напрямую C, но доступен только косвенно через B.bla()

Я проверил его, и не имеет значения, делаю ли я модификатор доступа foo() пакет приватным или нет.

package apples;

import java.util.function.IntSupplier;

public class B {
    public IntSupplier getReferenceToAFoo() {
        A aInstance = new A();
        return aInstance::foo;
    }
}
package pizzas;

import apples.B;

import java.util.function.IntSupplier;

public class C {
    private int callAFooIndirectly() {
        B bInstance = new B();
        IntSupplier intsupplier = bInstance.getReferenceToAFoo();
        return intsupplier.getAsInt();
    }

    public static void main(String[] args) {
        C cInstance = new C();

        int i = cInstance.callAFooIndirectly();
        System.out.println(i);
        assert 42 == i;
    }
}

1 Ответ

8 голосов
/ 08 октября 2019

Правильно ли мое понимание?

Да.

Какие могут быть веские причины иметь менее строгие модификаторы доступа к элементам?

Две причины:

  • Иногда вы реализуете интерфейс;Методы интерфейса должны быть public
  • Это облегчает изменение общего доступа вашего класса. Например, если вы пометите все методы, которые вы когда-либо хотели бы сделать общедоступными public, даже в классе с закрытыми пакетами, то позже все, что вам нужно сделать, чтобы сделать класс общедоступным, это добавить public в класс. объявление.

И, наконец, какой практикой лучше следовать?

Это вопрос мнения, поэтому он не очень подходит для вопроса переполнения стека илиответ. Делайте то, что кажется разумным для вас и / или вашей команды, и / или делайте то, что советует вам руководство по стилю вашей команды.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...