Is & ldquo; protected & rdquo; модификатор бесполезен? [Дубликат]

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

• Видно для пакета. по умолчанию. Модификаторы не нужны.
• Видно только для класса: private.
• Видно миру, public.
• Видно для пакета и всех подклассов; .

Итак, давайте поговорим о Access Control and Inheritance . Следующие правила для унаследованных методов:

• Объявленные методы public в суперклассе также должно быть общедоступным во всех подклассах.
• Объявленные методы protected в суперклассе должны быть либо protected, либо public в подклассах; они не могут быть частными.
• Способы, объявленные без контроля доступа (без использования модификатора), могут быть объявлены более частными в подклассах.
• Объявленные методы private не наследуются вообще, поэтому для них нет правила.

Я просто хочу обратиться к деталям, которые чрезвычайно часто ошибаются, в том числе большинством ответов на этой странице. Доступ «по умолчанию» (когда нет модификатора доступа) не всегда совпадает с пакетом-частным. Это зависит от того, что это такое.

• Типы нечленов (то есть классы, перечисления, интерфейсы и типы аннотаций, не объявленные внутри другого типа) по умолчанию являются закрытыми по пакетам. ( JLS §6.6.1 )
• Члены класса и конструкторы по умолчанию закрыты по пакетам. ( JLS §6.6.1 )
• Конструкторы Enum по умолчанию являются закрытыми. (Действительно, enum contructors должны быть закрытыми, и это ошибка, чтобы попытаться сделать их общедоступными или защищенными). Константы Enum являются общедоступными и не допускают спецификатор доступа. Другие члены перечисления по умолчанию закрыты по пакетам. ( JLS §8.9 )
• Все члены интерфейсов и типы аннотаций по умолчанию являются общедоступными. (Действительно, члены интерфейсов и типы аннотаций должны быть публичными, и это ошибка, чтобы попытаться сделать их частными или защищенными.) ( JLS §9.3 - 9.5 )

Все дело в инкапсуляции (или, как сказал Джо Филлипс, наименьшее знание ).

Начните с самого ограничительного (частного) и посмотрите, нужно ли вам менее ограничительные модификаторы позже .

Мы все используем модификаторы метода и члена, такие как private, public, ... но одна вещь, которую слишком мало разработчиков делают, это использовать пакеты для логического упорядочения кода.

Например: You могут помещать чувствительные методы защиты в пакет «безопасность». Затем поместите открытый класс, который обращается к некоторому коду безопасности, содержащемуся в этом пакете, но сохраняет другие классы классов безопасности частными. Таким образом, другие разработчики смогут использовать общедоступный класс вне этого пакета (если только они не изменят модификатор). Это не функция безопасности, но будет определять использование.

Outside world -> Package (SecurityEntryClass ---> Package private classes)

Другое дело, что классы, которые много зависят друг от друга, могут оказаться в одном пакете и в конечном итоге могут быть реорганизованы или объединены, если

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

Частный

• Методы, переменные и конструкторы

Методы, переменные и конструкторы, объявленные как private, могут быть доступны только в объявленном классе

• Класс и интерфейс

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

Примечание

Переменные, объявленные как private, могут быть доступны за пределами класса, если публичный getter методы присутствуют в классе. Доступ к переменным, методам и конструкторам, которые объявлены защищенными в суперклассе, могут быть доступны только подклассами другого пакета или любого класса в пакете класса защищенных членов.

Защищено

• Класс и интерфейс

Модификатор защищенного доступа не может применяться к классу и интерфейсам.

Методы, поля могут быть объявлены защищенными, однако методы и поля в интерфейсе не могут быть объявлены защищенными.

Примечание

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

Public

Доступ к классу, методу, конструктору, интерфейсу и т. д. может быть доступен из любого другого класса.

Поэтому поля, методы, блоки, объявленные внутри открытого класса, могут быть доступны из любого класса, принадлежащего Java-юнита

• Различные пакеты

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

Из-за наследования класса все общедоступные методы и переменные класса наследуются его подклассами.

По умолчанию - Нет ключевого слова:

Модификатор по умолчанию означает, что мы явно не объявляем модификатор доступа для класса, поля, метода и т. д.

• В тех же пакетах

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

Примечание

Мы не можем переопределить Статические поля. Если вы пытаетесь переопределить его, он не показывает никаких ошибок, но он не работает, кроме нас.

Ответы на вопросы

• Переопределение статических методов в java

Ссылки ссылки

http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html http://www.tutorialspoint.com/java/java_access_modifiers.htm

Самый непонятый модификатор доступа в Java - protected. Мы знаем, что он похож на модификатор по умолчанию с одним исключением, в котором подклассы могут его видеть. Но как? Вот пример, который, надеюсь, прояснит путаницу:

• Предположим, что у нас есть 2 класса; Father и Son, каждый в своем собственном пакете:

  package fatherpackage;
  
  public class Father
  {
  
  }
  
  -------------------------------------------
  
  package sonpackage;
  
  public class Son extends Father
  {
  
  }
  

• Давайте добавим защищенный метод foo() в Father.

  package fatherpackage;
  
  public class Father
  {
      protected void foo(){}
  }
  

• Метод foo() можно вызвать в 4 контекстах: внутри класса, который находится в том же пакете, где foo() определен (fatherpackage):

  package fatherpackage;
  
  public class SomeClass
  {
      public void someMethod(Father f, Son s)
      {
          f.foo();
          s.foo();
      }
  }
  

  Внутри подкласса , в текущем экземпляре через this или super:

  package sonpackage;
  
  public class Son extends Father
  {
      public void sonMethod()
      {
          this.foo();
          super.foo();
      }
  }
  

  В ссылке, тип которой является одним и тем же классом:

  package fatherpackage;
  
  public class Father
  {
      public void fatherMethod(Father f)
      {
          f.foo(); // valid even if foo() is private
      }
  }
  
  -------------------------------------------
  
  package sonpackage;
  
  public class Son extends Father
  {
      public void sonMethod(Son s)
      {
          s.foo();
      }
  }
  

  В ссылке, тип которой является родительским классом, и внутри пакет, где foo() определен (fatherpackage) [Это может быть включено внутри контекста no. 1]:

  package fatherpackage;
  
  public class Son extends Father
  {
      public void sonMethod(Father f)
      {
          f.foo();
      }
  }
  

• Следующие ситуации недействительны. В ссылке, тип которой является родительским классом, и вне определен пакет fatherpackage:

  package sonpackage;
  
  public class Son extends Father
  {
      public void sonMethod(Father f)
      {
          f.foo(); // compilation error
      }
  }
  

  : не подкласс внутри пакета подкласса наследует защищенные члены от своего родителя и делает их частными для не-подклассов):

  package sonpackage;
  
  public class SomeClass
  {
      public void someMethod(Son s) throws Exception
      {
          s.foo(); // compilation error
      }
  }
  

Часто я осознавал, что запоминание основных понятий любого языка может быть сделано путем создания реальных аналогов. Вот моя аналогия для понимания модификаторов доступа в Java:

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

• Когда вы приводите его в университетский городок, первое, что вы и ваш друг видите, это эта статуя. Это означает, что любой, кто ходит в кампусе, может смотреть на статую без разрешения университета. Это делает статую PUBLIC.
• Затем вы хотите забрать своего друга в общежитие, но для этого вам необходимо зарегистрировать его в качестве посетителя. Это означает, что он получает пропуск доступа (который такой же, как ваш), чтобы попасть в различные здания на территории кампуса. Это сделало бы его карточку доступа ЗАЩИЩЕНА.
• Ваш друг хочет войти в университетский городок WiFi, но у него нет никаких учетных данных. Единственный способ, по которому он может выйти в интернет, - это поделиться своим логином с ним. (Помните, что каждый студент, который идет в университет, также обладает этими учетными данными). Это сделало бы ваши учетные данные как NO MODIFIER.
• Наконец, ваш друг хочет прочитать ваш отчет о проделанной работе за семестр, который размещен на веб-сайте. Однако каждый студент имеет свой личный логин для доступа к этому разделу веб-сайта кампуса. Это сделало бы эти полномочия как PRIVATE.

Надеюсь, что это поможет!

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

Легкое правило. Начните с объявления всех частных. И затем продвигаться к общественности по мере возникновения потребностей, и дизайн ее оправдывает.

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

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

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

Как правило:

• private: класс scope.
• default (или package-private ): область пакета.
• protected: package scope + child (например, пакет, но мы можем подклассифицировать его из разных пакетов).

В результате, если мы разделим права доступа на три права:

g9]

• (D) direct (вызов из метода внутри одного класса).
• (R) eference (вызов метода с использованием ссылки на класс или через «точку») синтаксис).
• (I) nheritance (через подклассирование).

, тогда у нас есть эта простая таблица:

+—-———————————————+————————————+———————————+
|                 |    Same    | Different |
|                 |   Package  | Packages  |
+—————————————————+————————————+———————————+
| private         |   D        |           |
+—————————————————+————————————+———————————+
| package-private |            |           |
| (no modifier)   |   D R I    |           |
+—————————————————+————————————+———————————+
| protected       |   D R I    |       I   |
+—————————————————+————————————+———————————+
| public          |   D R I    |    R  I   |
+—————————————————+————————————+———————————+

Ответ Дэвида дает смысл каждого модификатора доступа. Что касается использования каждого из них, я бы предложил публиковать все классы и методы каждого класса, предназначенные для внешнего использования (его API), и все остальное частное.

Со временем вы будете развивать смысл для того, чтобы сделать некоторые классы private-private и когда объявлять определенные методы, защищенные для использования в подклассах.

Когда вы думаете о модификаторах доступа, просто подумайте об этом таким образом (применительно к обеим переменным и методам):

public -> доступно из любого места private -> доступно только в том же классе, где он объявлен

. Теперь возникает путаница, когда дело доходит до default и protected

default -> Нет ключевого слова модификатора доступа , Это означает, что он доступен строго в пакете класса. Нигде за пределами этого пакета он доступен.

protected -> Чуть менее строже, чем default, и кроме тех же классов пакетов, к ним могут обращаться под-классы вне пакета / g0] объявлено.