Ограничат ли модификаторы публичного доступа гибкость при изменении кода? Если да, приведите несколько примеров.

Question

Ограничат ли модификаторы общего доступа гибкость при изменении кода? Если да, приведите несколько примеров.

Answer 1

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

Но это ограничивает вашу гибкость? Я бы сказал, да.

Поскольку это домашнее задание, я не собираюсь объяснять вам ответ ... или приводить примеры, которые вы можете вырезать и вставить. Но рассмотрим правила Java для переопределения членов в подклассе. В частности, подумайте, что вы можете и не можете делать с точки зрения изменения доступа к методу.

Answer 2

Первые два ответа от поиска вашего вопроса в значительной степени говорят обо всем

java.sun.com / документы / книги / учебник / Java / javaOO / accesscontrol.html

www.java-samples.com / showtutorial.php? Tutorialid = 655

Теперь моя точка зрения: я думаю, что стоит добавить, что хорошей практикой является начинать с private по умолчанию и переходить в защищенный, если класс расширен; и public, когда вы хотите предоставить доступ к классам из разных пакетов.

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

Итак, если вы абсолютно не обеспокоены безопасностью, наращивайте модификаторы по мере необходимости.

Answer 3

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

package com.app.access;

public class  Car{
  public int wheels;
  public int lights;
  //  Method for how wheels rotate
 // Method for how lights on
}

public class TestCar{
  public static void main(String [] args) {

      Car c = new Car();
      c.wheels = -5; // Legal but bad 00 because we know it cannot have a negative value
   }
}

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

get<propertyName> or for booleans is<propertyName> and set<propertyName>

предоставить место для проверки и / или проверки перед возвратом или изменением значения.

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

Answer 4

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

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