защищенные данные в абстрактном классе

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

Теперь я понимаю, что мы хотим защитить данные от прямого манипулирования случайными пользователями класса, и что общедоступные члены данных в целом являются сомнительной практикой. Я посмотрел на «Поля, защищенные Java против общедоступных получателей» ( Поля, защищенные Java, против общедоступных получателей ), но я все еще сомневаюсь, что:

protected int i;  

хуже в абстрактном классе, чем:

private int i;  
protected int geti();  
protected void seti(int j); 

Я просто не вижу обратной стороны, когда абстрактный класс существует именно для предоставления родительских / общих возможностей дочерним классам, а защищенная область предназначена для предоставления доступа детям, при этом защищая данные от случайных пользователей. Я отмечаю в вышеупомянутом вопросе, что большинство ответов, похоже, касаются вопроса о том, почему данные в целом должны быть частными, а не общедоступными. Я пытаюсь сосредоточить свой вопрос конкретно на данных, существующих в абстрактном родителе, предназначенном для использования детьми. Единственный разумный комментарий, который я слышал на сегодняшний день, заключается в том, что использование защищенных родителями данных (например, int i выше) оставляет вас с кодом в дочернем классе, который ссылается на переменную, не объявленную в дочернем классе. Менее убедительным является аргумент (см. Общий защищенный элемент данных в базовом классе? ), что вы можете захотеть изменить доступ однажды, и теперь вы должны соблюдать свой интерфейс. Это абстрактный класс, предназначенный для расширения в 100% случаев.

Спасибо! Конкретные ссылки на книги под заголовком / на страницу # гораздо более полезны, чем ссылки на "... любой базовый текст программирования на Java ..."

=================== ====================== 10-13-2010
Единственный разумный комментарий, который я слышал на сегодняшний день, заключается в том, что использование защищенных родителями данных (например, int i выше) оставляет вас с кодом в дочернем классе, который ссылается на переменную, не объявленную в дочернем классе. Менее убедительным является аргумент (см. Общий защищенный элемент данных в базовом классе? ), что вы можете захотеть изменить доступ однажды, и теперь вы должны соблюдать свой интерфейс. Это абстрактный класс, предназначенный для расширения в 100% случаев.

Спасибо! Конкретные ссылки на книги под заголовком / на страницу # гораздо более полезны, чем ссылки на "... любой базовый текст программирования на Java ..."

=================== ====================== 10-13-2010
Единственный разумный комментарий, который я слышал на сегодняшний день, заключается в том, что использование защищенных родителями данных (например, int i выше) оставляет вас с кодом в дочернем классе, который ссылается на переменную, не объявленную в дочернем классе. Менее убедительным является аргумент (см. Общий защищенный элемент данных в базовом классе? ), что вы можете захотеть изменить доступ однажды, и теперь вы должны соблюдать свой интерфейс. Это абстрактный класс, предназначенный для расширения в 100% случаев.

Спасибо! Конкретные ссылки на книги под заголовком / на страницу # гораздо более полезны, чем ссылки на "... любой базовый текст программирования на Java ..."

=================== ====================== 10-13-2010
int i выше) оставляет вас с кодом в дочернем классе, который ссылается на переменную, не объявленную в дочернем классе. Менее убедительным является аргумент (см. Общий защищенный элемент данных в базовом классе? ), что вы можете захотеть изменить доступ однажды, и теперь вы должны соблюдать свой интерфейс. Это абстрактный класс, предназначенный для расширения в 100% случаев.

Спасибо! Конкретные ссылки на книги под заголовком / на страницу # гораздо более полезны, чем ссылки на "... любой базовый текст программирования на Java ..."

=================== ====================== 10-13-2010
int i выше) оставляет вас с кодом в дочернем классе, который ссылается на переменную, не объявленную в дочернем классе. Менее убедительным является аргумент (см. Общий защищенный элемент данных в базовом классе? ), что вы можете захотеть изменить доступ однажды, и теперь вы должны соблюдать свой интерфейс. Это абстрактный класс, предназначенный для расширения в 100% случаев.

Спасибо! Конкретные ссылки на книги под заголовком / на страницу # гораздо более полезны, чем ссылки на "... любой базовый текст программирования на Java ..."

=================== ====================== 10-13-2010
и предназначен для продления 100% времени.

Спасибо! Конкретные ссылки на книги под заголовком / на страницу # гораздо более полезны, чем ссылки на "... любой базовый текст программирования на Java ..."

=================== ====================== 10-13-2010
и предназначен для продления 100% времени.

Спасибо! Конкретные ссылки на книги под заголовком / на страницу # гораздо более полезны, чем ссылки на "... любой базовый текст программирования на Java ..."

=================== ====================== 10-13-2010
Это был такой же вопрос об абстрактных классах, как и об защищенных данных. Меня разочаровывает, что в ответах акцент сместился на то, является ли сокрытие данных хорошей вещью в ООП (ответ: да). Здесь много глубины, затрагивающей природу абстрактного класса, и как он отличается от обычного не финального класса, и какие возможные преимущества могут быть для исправления имен и типов элементов данных в абстрактном родительском элементе для использования детские классы. Я думаю, что здесь есть возможность для инноваций и большего контроля, распространяющегося от абстрактного родителя к реализующим дочерним классам. Я обеспокоен тем, что общие принципы, такие как преимущества сокрытия данных, могут стать догмой и препятствовать инновациям и разработке новых моделей и идей.

Спасибо всем, кто внес свой вклад.

14
задан Community 23 May 2017 в 11:54
поделиться

7 ответов

Ограниченный доступ - не недостаток, а преимущество. Классы всегда должны ограничивать доступ к как можно большей части своего внутреннего состояния. Не думайте, почему внутренние элементы должны быть скрыты, вместо этого подумайте, почему они должны быть открыты. В этом случае, как и в любом другом случае, если нет действительно веской причины для раскрытия переменной, не раскрывайте ее.

3
ответ дан 1 December 2019 в 10:32
поделиться

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

Также есть вопрос, который Алексей поднимал ранее.

1
ответ дан 1 December 2019 в 10:32
поделиться

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

Предоставление средств доступа позволяет базовому классу поддерживать свое состояние: подкласс не может повредить его без умышленного трюка.

9
ответ дан 1 December 2019 в 10:32
поделиться

Скрытие информации полезно даже для классов, связанных наследованием.

В дополнение к разрешению повторной реализации, как отмечено выше alex:

  • Вы можете устанавливать точки останова в методах.
  • Вы можете добавлять ограничения в одном месте.
0
ответ дан 1 December 2019 в 10:32
поделиться

Если вам не нужно, чтобы ваш ребенок напрямую имел к нему доступ, почему вы позволяете ему?

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

1
ответ дан 1 December 2019 в 10:32
поделиться

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

Стоит ли это того, решать вам.

11
ответ дан 1 December 2019 в 10:32
поделиться

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

В остальном это действительно зависит от вас. Однако существует соглашение, что для всего есть геттеры и сеттеры.

0
ответ дан 1 December 2019 в 10:32
поделиться
Другие вопросы по тегам:

Похожие вопросы: