Что такое private в java
Модификаторы доступа Java
Модификаторы доступа Java. ключевое слово public private protected для контроля доступа. примеры java private, java protected, java public. Спецификаторы доступа Java.
Модификаторы доступа Java
Мы можем использовать модификаторы доступа java с классами, а также переменными и методами классов.
Нам разрешено использовать только модификаторы доступа “общедоступный” или “по умолчанию” с классами java.
Модификаторы доступа Java с членом класса
У нас могут быть все четыре модификатора доступа для переменных и методов-членов класса. Однако правила модификатора доступа к членам применяются после правил доступа на уровне класса. Например, если класс имеет доступ по умолчанию, то он не будет виден в других пакетах, и, следовательно, методы и переменные класса также не будут видны.
Мы рассмотрим каждый из них отдельно, а затем покажем использование модификаторов доступа java с помощью простой программы.
Модификаторы доступа Java – ключевое слово public
Если член класса является “общедоступным”, то к нему можно получить доступ из любого места. Доступ к переменной – члену или методу осуществляется глобально. Это самый простой способ предоставить доступ членам класса. Однако мы должны позаботиться об использовании этого ключевого слова с переменными класса, иначе любой может изменить значения. Обычно переменные класса хранятся как частные, и для работы с ними предоставляются методы getter-setter.
Модификаторы доступа Java – частное ключевое слово
Если член класса является “частным”, то он будет доступен только внутри того же класса. Это самый ограниченный доступ, и член класса не будет виден внешнему миру. Обычно мы сохраняем переменные класса как частные, а методы, которые предназначены для использования только внутри класса, как частные.
Модификаторы доступа Java – защищенное ключевое слово
Если член класса “защищен”, то он будет доступен только классам в том же пакете и подклассам . Этот модификатор менее ограничен для частного, но более ограничен для публичного доступа. Обычно мы используем это ключевое слово, чтобы убедиться, что переменные класса доступны только подклассам.
Модификаторы доступа Java – доступ по умолчанию
Если у члена класса не указан какой-либо модификатор доступа, то он обрабатывается доступом по умолчанию. Правила доступа аналогичны классам, и член класса с доступом по умолчанию будет доступен только классам в одном пакете. Этот доступ более ограничен, чем публичный, и защищен, но менее ограничен, чем частный.
(Наименее доступный) частный Метки
В чем разница между public, protected, package-private и private на Java?
25 ответов
(предостережение: я не программист Java, я программист Perl. Perl не имеет формальной защиты, поэтому, возможно, я так хорошо понимаю проблему :))
частная
Как вы думаете, только класс, в котором он объявлен вижу.
Частный Пакет
можно увидеть и использовать только пакета, в котором он был объявлен. Это значение по умолчанию в Java (которое некоторые видят как ошибка.)
защищенный
Package Private + можно увидеть подклассы или член пакета.
общественные
опубликовано
видимый вне кода I control. (Хотя это не синтаксис Java, это важно для этого обсуждения).
C++ определяет дополнительный уровень под названием «друг», и чем меньше вы знаете об этом, тем лучше.
когда вы должны использовать то, что? Этот вся идея заключается в инкапсуляции, чтобы скрыть информацию. Как можно больше вы хотите скрыть детали того, как что-то делается от ваших пользователей. Почему? Потому что тогда вы можете изменить их позже и не нарушать чей-либо код. Это позволяет оптимизировать, рефакторинг, редизайн и исправить ошибки, не беспокоясь, что кто-то использовал этот код, который вы только что отремонтировали.
Итак, эмпирическое правило-делать вещи только такими видимыми, какими они должны быть. Начните с private и только добавьте больше видимости по мере необходимости. Только обнародуйте то, что абсолютно необходимо пользователю знать, каждая деталь, которую вы обнародуете, ограничивает вашу способность перепроектировать систему.
лично я придерживаюсь только «частного»и » общественного». Многие языки OO просто имеют это. «Защищенный» может быть удобным, но это действительно обман. Как только интерфейс больше, чем частный, он вне вашего контроля и вы должны искать в коде других людей, чтобы найти применение.
вот где приходит идея «опубликованного». Изменение интерфейса (рефакторинг) требует, чтобы вы нашли весь код, который его использует, и изменили его. Если интерфейс является частным, ну нет проблем. Если он защищен, вы должны найти все свои подклассы. Если это общедоступно, вы должны найти весь код, который использует ваш код. Иногда это возможно, например, если вы работаете на корпоративной код, который предназначен только для внутреннего использования, не имеет значения, является ли интерфейс общедоступным. Вы можете взять весь код из корпоративного репозитория. Но если интерфейс «опубликован», если есть код, использующий его вне вашего контроля, то вы обливаетесь. Вы должны поддерживать этот интерфейс или рисковать взломать код. Даже защищенные интерфейсы можно считать опубликованными (поэтому я не беспокоюсь о защищенных).
многие языки считают иерархическую природу публичного / защищенного / частного слишком ограничивающий и не соответствующий реальности. С этой целью существует понятие черта класс, но это другое шоу.
вот лучшая версия таблицы. (Будущее доказательство со столбцом для модулей.)
объяснениями
A частная член только доступно в том же классе, что и объявлено.
член нет доступа модификатор доступно только в классах в то же пакет.
A защищенный член доступен во всех классах в одном пакете и внутри подклассов в других пакетах.
A общественные член доступен для всех классов (если он проживает в модуль это не экспортирует пакет, в котором он объявлен).
какой модификатор выбрать?
примеры:
простое правило. Начните с объявления всего личного. А затем прогресс в направлении общественности по мере возникновения потребностей и оправдания дизайна.
Как правило, я стараюсь избегать переопределения метода реализации с помощью подклассов; слишком легко испортить логику. Объявите абстрактные защищенные методы, Если вы хотите, чтобы они были переопределены.
кроме того, используйте аннотацию @Override при переопределении, чтобы вещи не ломались при рефакторинге.
на самом деле это немного сложнее, чем показывает простая сетка. Сетка говорит вам, разрешен ли доступ, но что именно представляет собой доступ? Кроме того, уровни доступа взаимодействуют с вложенными классами и наследованием сложными способами.
доступ «по умолчанию» (задается отсутствием ключевого слова) также называется пакета-частная. Исключение: в интерфейсе нет модификатора означает открытый доступ; модификаторы, отличные от public, запрещены. Константы перечисления всегда являются общедоступными.
резюме
разрешен ли доступ к члену с этим спецификатором доступа?
какие спецификаторы доступа применяются к
локальные переменные и формальные параметры не могут принимать спецификаторы доступа. Поскольку они по своей сути недоступны для внешнего мира в соответствии с правилами определения области, они фактически являются частными.
для классов в верхней области, только public и package-private разрешены. Этот выбор дизайна, по-видимому, потому что protected и private будет излишним на уровне пакетов (наследование пакетов отсутствует).
все спецификаторы доступа возможны для членов класса (конструкторы, методы и статические функции-члены, вложенные классы).
ордер
спецификаторы доступа могут быть строго упорядочены
public > protected > package-private > private
означает, что public обеспечивает наибольший доступ, private меньше. Возможные ссылкой на собственный член тоже действует пакет-отдельный член; любая ссылка на пакет-отдельный член действует по защищенному члену, и так далее. (Предоставление доступа защищенным членам к другим классам в том же пакете считалось ошибкой.)
Примечания
внутренние классы
вы также должны рассмотреть вложенные областей, такие как внутренние классы. Примером сложности является то, что внутренние классы имеют члены, которые сами могут принимать модификаторы доступа. Таким образом, вы можете иметь частный внутренний класс с публичным членом; можно ли получить доступ к члену? (Смотреть ниже.) Общее правило-смотреть на область и думать рекурсивно, чтобы увидеть, можете ли вы получить доступ к каждому уровню.
однако, это довольно сложно, и для полной информации,обратитесь к спецификации языка Java. (Да, в компиляторе были ошибки прошлое.)
чтобы попробовать, как они взаимодействуют, рассмотрим этот пример. Возможно «утечка» частных внутренних классов; это обычно предупреждение:
в результате, если мы разделим право доступа на три права:
затем у нас есть эта простая таблица:
метод foo() можно вызвать в 4 контекстах:
внутри класса, который находится в том же пакете, где foo() определяется ( fatherpackage ):
внутри подкласса, в текущем экземпляре через this или super :
по ссылке, тип которой совпадает класс:
по ссылке, тип которой является родительским классом, и это внутри пакета, где foo() определяется ( fatherpackage ) [это может быть включено в контекст no. 1]:
следующие ситуации недопустимы.
по ссылке, тип которой является родительским классом, и это за пределами пакета, где foo() is определено ( fatherpackage ):
не-подкласс внутри пакета подкласса (подкласс наследует защищенные члены от своего родителя, и это делает их частными для не-подклассов):
частная
методы, переменные и конструкторы, объявленные частными, могут быть доступны только в самом объявленном классе.
модификатор частного доступа является наиболее ограничительным уровнем доступа. Класс и интерфейсы не могут быть частный.
Примечание
переменные, объявленные закрытыми, могут быть доступны вне класса, если в классе присутствуют общедоступные методы геттера. Переменные, методы и конструкторы, которые объявлены защищенными в суперклассе, могут быть доступны только подклассам в другом пакете или любому классу в пакете защищенных членов класс.
защищенный
модификатор защищенного доступа не может быть применен к классу и интерфейсам.
методы, поля могут быть объявлены защищенными, однако методы и поля в интерфейсе не могут быть объявлены защищенный.
Примечание
защищенный доступ дает подкласс возможность использовать вспомогательный метод или переменную, предотвращая класс неродственными от того, чтобы использовать его.
Public
класс, метод, конструктор, интерфейс и т. д. объявляются могут быть доступны из любого другого класса.
поэтому поля, методы, блоки, объявленные внутри открытого класса, могут быть доступны из любого класса, принадлежащего Вселенной Java.
однако, если открытый класс, к которому мы пытаемся получить доступ, находится в другом пакете, то открытый класс все равно нужно импортировать.
из-за наследования класса все открытые методы и переменные класса наследуются его подклассами.
модификатор доступа по умолчанию означает, что мы явно не объявляем модификатор доступа для класса, поля, метода и т. д.
переменная или метод, объявленные без модификатора управления доступом, доступны для любого другого класса в та же посылка. Поля в интерфейс неявно общедоступные статические Заключительные и методов в интерфейсе по умолчанию Public.
Примечание
мы не можем переопределить статические поля.если вы попытаетесь переопределить, он не покажет никакой ошибки но не работает то, что мы исключаем.
В чем преимущества использования закрытых (private) методов в классе?
В чем преимущества использования закрытых (private) методов в классе, кроме скрытых вычислений?
11 ответов 11
При написании достаточно большого куска кода (неважно, класса, функции или чего-нибудь ещё) важным приёмом является декомпозиция. Вы делите функциональность на логические части, и в главной функции складываете из них, как из кирпичиков, общую логику.
При этом сами кирпичики могут быть не приспособлены для доступа снаружи. Например, открытый метод может проверять входные параметры, а вспомогательным методам-кирпичикам это уже не нужно, т. к. они вызываются лишь изнутри. Если бы эти методы были открытыми, в них нужно было бы реализовывать проверку параметров, и при их имплементации нельзя было бы рассчитывать на то, что они будут вызваны в контролируемый вами момент.
Кроме того, внутренние методы имеют право портить состояние класса, если вы знаете, что вызывающий их код потом эту проблему исправит. Если сделать эти методы открытыми, пользователи этого класса смогут испортить внутреннее состояние класса без исправления.
Затем, внутренние методы могут не иметь ничего общего с тем, что должен предоставлять класс, с его внешним интерфейсом. Например, если класс представляет машину, то открытый метод в нём, переводящий дюймы в сантиметры, смотрелся бы нелепо. А вот внутри такой перевод вполне может понадобиться.
Ну и в конце-концов, публичный метод — это обещание для пользователей. Каждое изменение (удаление, изменение сигнатуры, а иногда и добавление) открытого метода — breaking change для клиентов, они должны пересмотреть код, который использует ваш класс. Таким образом, вы не должны просто так, без особой на то необходимости менять открытые методы класса. А вот изменения в закрытых методах обычно происходят при рефакторинге в массовом порядке: методы упрощаются, объединяются, раскладываются на несколько, переносятся вверх-вниз по иерархии, меняется их семантика, и всё это никак не отражается на пользователях вашего класса.
Чтобы добавить что-то, private метод может ВСЕГДА безопасно меняться, потому что вы точно знаете, что вызывается только из собственного класса, никакие внешние классы не могут вызвать private метод (они даже не видят его).
Таким образом, наличие private метода всегда хорошо, поскольку вы знаете, что нет никаких проблем по его изменению, даже вы можете безопасно добавить дополнительные параметры в метод.
Что касается о public методах, любой может вызвать этот метод, поэтому, если вы добавляете/удаляете параметр, вам также нужно будет изменить ВСЕ вызовы этого метода.
Вот некоторые преимущества создания переменных или методов private в Java:
частные методы хорошо инкапсулированы в классе, и разработчик знает, что они не используются где-либо еще в коде, что дает им уверенность в изменении, изменении или улучшении частного метода без какого-либо побочного эффекта.
Если посмотреть на закрытый метод, вы наверняка знаете, что никто его не использует, что очень помогает при отладке java-программы.
IDE, например Netbeans, IDEA и Eclipse, используют эту информацию и автоматически проверяют, используются ли частные методы внутри класса или нет, и могут отображать соответствующее предупреждение для улучшения качества кода или удаления неиспользуемых операторов, переменных или методов.
Частные методы используют статическую привязку в Java, и они связываются во время компиляции, которое быстро сравнивается с динамическим связыванием, которое происходит во время выполнения, а также дает JVM шанс либо встроить метод, либо оптимизировать его.
Присвоение переменных приватным в java и предоставление им getter и setter делает ваш класс совместимым с именованием бинов Java и другими структурами на основе отражения, такими как displaytag.
Неплохая (на мой взгляд) статья на эту тему
Сделав метод закрытым, совсем не обязательно его сохранять при переходе к
другой реализации. Такой метод труднее реализовать, а возможно, он окажется
вообще ненужным, если изменится представление данных, что, в общем, несущественно. Важнее другое: до тех пор, пока метод является закрытым (private), разработчики класса могут быть уверены в том, что он никогда не будет использован в операциях, выполняемых за пределами класса, а следовательно, они могут просто удалить его. Если же метод является открытым (public), его нельзя просто так опустить,
поскольку от него может зависеть другой код.
ИТОГО: В следствии использовании принципа инкапсуляции у програмиста уменьшается возможность допустить ошибку по-дурости и повышается производительность на средне-малых, средних и больших проэктах т.к. код становится проще и безопаснее при изменении самого класса.
(На совсем малых проэктах в пару малых классов производительность программиста может упасть за счет «лишних действий», но по-факту, оно того все равно стоит)
off-topic
В этом контексте забавно читать:
private методы и переменные видны только внутри класс. Их не видят никакие постороннме классы. Даже их дети. Это делают для предотвращения нежелательного изменения данных извне.
Теперь к сути вопроса ТС
Так что кроме инкапсуляции я вижу плюс использования приватных методов еще как средство планирования будущих релизов.
Инкапсуляция предохраняет данные объекта от нежелательного доступа, позволяя объекту самому управлять доступом к своим данным.
Есть такое понятие- инкапсуляция.
Т.е пользователям твоего класса не следует знать о внутреннем устройстве твоего класса.
Инкапсуляция предохраняет данные объекта от нежелательного доступа, позволяя объекту самому управлять доступом к своим данным.
Для закрытого члена класса нельзя задать значение непосредственно в коде за пределами класса. Но в то же время можно полностью управлять тем, как и когда данные используются в объекте. Следовательно, правильно реализованный класс образует некий “черный ящик”, которым можно пользоваться, но внутренний механизм «его действия закрыт для вмешательства извне.
Как следствие мы имеем:
1 Более простую структуру кода (ты точно видишь где внутренне важная реализация, а где важная для внешних обьектов)
1.1 При написании достаточно большого куска кода (неважно, класса, функции или чего-нибудь ещё) важным приёмом является декомпозиция. Вы делите функциональность на логические части, и в главной функции складываете из них, как из кирпичиков, общую логику.
При этом сами кирпичики могут быть не приспособлены для доступа снаружи. Например, открытый метод может проверять входные параметры, а вспомогательным методам-кирпичикам это уже не нужно, т. к. они вызываются лишь изнутри. Если бы эти методы были открытыми, в них нужно было бы реализовывать проверку параметров, и при их имплементации нельзя было бы рассчитывать на то, что они будут вызваны в контролируемый вами момент.
2 Кроме того, внутренние методы имеют право портить состояние класса, если вы знаете, что вызывающий их код потом эту проблему исправит. Если сделать этим методы открытыми, пользователи этого класса смогут испортить внутреннее состояние класса без исправления.
3.1 Невозможно по-ошибке вызвать метод с другого класса который с него вызывать не нужно.
3.2 Невозможно извне изменить проперти, которую не нужно изменять извне.
4 Возможность изменять реализацию внутренней структуры класса(все что относится к приватам) не ламая при этом «внешний код», который привязан исключительно к пабликам.
4.1. В совместных проектах у программистов уменьшается возможность допустить ошибку из-за незнания особенностей вешнего кода.
4.2 Повышается производительность на средне-малых, средних и больших проэктах т.к. код становится проще и безопаснее. (На совсем малых проэктах в пару малых классов производительность программиста может упасть за счет «лишних действий», но по-факту, оно того все равно стоит)
4.3 Ну и в конце-концов, публичный метод — это обещание для пользователей. Каждое изменение (удаление, изменение сигнатуры, а иногда и добавление) открытого метода — breaking change для клиентов, они должны пересмотреть код, который использует ваш класс. Таким образом, вы не должны просто так, без особой на то необходимости менять открытые методы класса. А вот изменения в закрытых методах обычно происходят при рефакторинге в массовом порядке: методы упрощаются, объединяются, раскладываются на несколько, переносятся вверх-вниз по иерархии, меняется их семантика, и всё это никак не отражается на пользователях вашего класса.
5 Частные методы используют статическую привязку в Java, и они связываются во время компиляции, которое быстро сравнивается с динамическим связыванием, которое происходит во время выполнения, а также дает JVM шанс либо встроить метод, либо оптимизировать его.
6 Присвоение переменных приватным в java и предоставление им getter и setter делает ваш класс совместимым с именованием бинов Java и другими структурами на основе отражения, такими как displaytag.
7 Если посмотреть на закрытый метод, вы наверняка знаете, что никто его не использует, что очень помогает при отладке java-программы.
IDE, например Netbeans, IDEA и Eclipse, используют эту информацию и автоматически проверяют, используются ли частные методы внутри класса или нет, и могут отображать соответствующее предупреждение для улучшения качества кода или удаления неиспользуемых операторов, переменных или методов.
Единственный чрезвычайно важный фактор, отличающий хорошо спроектированный модуль от неудачного,- степень сокрытия его внутренних данных и иных деталей реализации от других модулей. Хорошо спроектированный модуль скрывает все детали реализации, четко разделяя свой АРI и реализацию. Модули взаимодействуют друг с другом только через свои API, и ни один из них не знает, какая обработка происходит внутри другого модуля. Эта концепция, называемая сокрытием информации ( information hiding ) или инкапсуляцией ( encapsulatiori ), представляет собой один из фундаментальных принципов разработки программного обеспечения.
Сокрытие информации важно по многим причинам, большинство из которых Связано с тем обстоятельством, что этот механизм эффективно изолирует друг от друга модули, составляющие систему, позволяя разрабатывать, тестировать, оптимизировать, использовать, исследовать и обновлять их по отдельности. Благодаря этому ускоряется разработка системы, так как различные модули могут создаваться параллельно. Кроме того, уменьшаются расходы на сопровождение приложения, поскольку каждый модуль можно быстро изучить и отладить, минимально рискуя навредить остальным модулям. Само по себе сокрытие информации не может обеспечить хорошей производительности, но оно создает условия для эффективного управления производительностью. Когда разработка системы завершена и процедура ее профилирования показала, работа каких модулей вызывает падение производительности, можно заняться их оптимизацией, не нарушая функционирования остальных модулей. Сокрытие информации повышает возможность повторного использования программ, поскольку каждый отдельно взятый модуль независим от остальных модулей и часто оказывается полезен в иных контекстах, чем тот, для которого он разрабатывался. Наконец, сокрытие информации уменьшает риски при построении больших систем: удачными могут оказаться отдельные модули, даже если в целом система не будет пользоваться успехом.
Главное правило заключается в том, что вы должны сделать каждый класс или член максимально недоступным. Другими словами, вы должны использовать самый низший из возможных уровней доступа, который еще допускает правильное функционирование создаваемой программы.
Для членов класса (полей, методов, вложенных классов и вложенных интерфейсов) существуют четыре возможных уровня доступа, которые перечислены здесь в порядке увеличения доступности:
Если уровень доступа для члена открытого класса меняется с доступного в пакете на защищенный, уровень доступности данного члена резко возрастает. Для этого класса защищенный член является частью внешнего API, а потому ему навсегда должна быть обеспечена поддержка. Более того, наличие защищенного члена в классе, передаваемом за пределы пакета, представляет собой открытую передачу деталей реализации. Потребность в использовании защищенных членов должна возникать сравнительно редко. Существует одно правило, ограничивающее ваши возможности по уменьшению доступности методов. Если какой-либо метод переопределяет метод супер класса, то методу в подклассе не разрешается иметь более низкий уровень доступа, чем был у метода в суперклассе. Это необходимо для гарантии того, что экземпляр подкласса можно будет использовать повсюду, где можно было использовать экземпляр суперкласса. Если вы нарушите это правило, то когда попытаетесь скомпилировать этот подкласс, компилятор сгенерирует сообщение об ошибке. Частный случай правила: если класс реализует некий интерфейс, то все методы класса, представленные в этом интерфейсе, должны быть объявлены как открытые ( public ). Это объясняется тем, что в интерфейсе все методы неявно подразумеваются открытыми.
Открытые поля (в отличие от открытых методов) в открытых классах должны быть редким явлением (если вообще должны ПОЯВЛЯТЬСЯ). Если поле не имеет модификатора final или имеет модификатор и ссылается на изменяемый объект, то, делая его открытым, вы упускаете возможность наложения ограничений на значения, которые могут быть записаны в этом поле. Вы также лишаетесь возможности предпринимать какие-либо действия в ответ на изменение этого поля. Отсюда простой вывод: классы с открытыми изменяемыми полями небезопасны в системе с несколькими потоками (not thread-safe). Даже если поле имеет модификатор final и не ссылается на изменяемый объект, объявляя его открытым, вы отказываетесь от возможности гибкого перехода на новое представление внутренних данных, в котором это поле будет отсутствовать.
Открытый массив следует заменить закрытым массивом и открытым неизменяемым списком:
Другой способ: если на этапе компиляции вам необходима проверка типов и вы готовы пожертвовать производительностью, то можете заменить открытое поле массива открытым методом, который возвращает копию закрытого массива.
Источник: «Java. Эффективное программирование.» Джошуа Блох.