Почему осторожно использовать "защищенный"

Question

В книге ядро ​​Java Ⅰ, он говорит ...

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

Не могу понять. Если Son extends Father и Father изменился, Son не был затронут. Это правильно?

Answer 1

Не могу понять. Если Son extends Father и Father изменился, Son не был затронут. это правильно?

Короткий ответ: Нет, для общего случая!

Предположим, у вас есть два класса, которые Вы описываете в версии 1 исходного кода:

Version 1

class Father { protected int asdf; } 
class Son extends Father { int qwer = 2 * asdf; } 

Теперь давайте изменим Защищенное поле asdf из Father

Version 2

class Father { protected int fdsa; } 
class Son extends Father { int qwer = 2 * asdf; } // compile error 

Теперь вы ДОЛЖНЫ измените значение Son, так что это определенно влияет на подкласс.

Библиотеки

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

Дальнейшего чтение

Есть несколько хороших ресурсов, изображающих все изящные детали об этой проблеме, хорошее Суммирование можно найти here на программист SE сети. Я пытаюсь обобщить его еще больше.

Использование protected имеет тенденцию к увеличению;

1. привести к YAGNI вопросам.
2. привести к LSP вопросам.
3. Нарушение OCP.
4. дизайн, где наследование предпочтительнее композиции.
5. привести к большему количеству нарушений SRP.

Еще одна хорошая ссылка: Clean Code от Robert C. Martin (также дядя Боб).

Answer 2

Пример: Если отец имеет сейф и дает своему сыну комбинацию.Сын может забрать деньги из сейфа, не уведомив отца, или наоборот. В любом случае, нет гарантии, что сын, беря деньги из сейфа, сообщит об этом отцу.

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

Это эквивалентно инкапсуляции. Всегда лучше защищать частные поля и публиковать публичные или защищенные методы. Таким образом, ответственный человек (где объявлено поле) может скрыть сведения о том, как изменяется поле, но может предоставить доступ к информации, относящейся к вызывающей стороне метода.

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