Обязательно ли использовать модификаторы доступа в Java?

#java

Везде наблюдаю использование private. Зачем? Это же твоя программа, объявил её public
и все. Зачем все это вообще? 
    

Ответы

Ответ 1

@m-vokhm надеюсь это вы написали или не подумамши или спросонья...

Первичная задача модификаторов доступа отнюдь не в разграничении доступа разных девелоперов,
а в идее инкапсуляции, которая преследует 2 цели:


механизм для ограничения прямого доступа к некоторым компонентам объекта
механизм, который облегчает связывание данных с методами/функциями, которые работают
с этими данными


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


public функция у часов одна: показывать время, иногда дату, иногда еще что-то. 
publicметодов у часиков всего несколько: подвести время, завести/зарядить - всё


Внутри часиков имеется огромное количество механизмов, шестеренок, винтиков, гаечек,
иногда процессоров - да мало ли чего. Все это таинство скрыто от вас и обозначено как
private. Почему то никому не приходит в голову идея, все эти шестереночки объявить
public - представляю что произойдет, если все эти шестеренки сделать публичными - 99%
часов в мире немедленно сломаются :) - очумелые рученьки людей которые ничего не понимают
в часовых механизмах, в премудростях балансиров, маятников, регуляторов, анкерных спусков
и проч. - немедленно все испортят...

Конечно есть мастера - часовщики, которые знают как надо использовать анкерные спуски
и к какой шестеренке что должно быть прикреплено - в нашем случае это те самые девелоперы,
которые и знают как работать с private/protected членами.

Надеюсь изложил понятно.


Ответ 2

Причина одна и называется инкапсуляция. Это один из основополагающих принципов ООП. 


  Инкапсуляция (англ. encapsulation, от лат. en capsula) — в информатике упаковка
данных и функций в единый компонент. Википедия


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

Что обозначают модификаторы: 


private обеспечивает видимость внутри класса
protected внутри класса и классах наследниках
public означает, что доступ разрешен откуда угодно.


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


Ответ 3

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

Если же над проектом работает группа разработчиков (а так работает большинство профессионалов
и так создаются все сколько-нибудь серьезные проекты), разграничение доступа приобретает
критически важное значение. Хотя бы взять такое простое соображение - нам для разработки
нашей части нужно использовать класс, который разрабатывает соседняя группа. Мы обговариваем
интерфейс, ребята делают макет, который работает кое-как, или просто имитирует работу,
но уже дает возможность нам делать свою часть работы. Пока мы ее делаем, соседи могут
десять раз изменить внутренности своего класса, не меняя его интерфейса. Если мы будем
использовать то, что они завтра просто выбросят - работа будет невозможна. 

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

Поэтому разграничение доступа -- необходимое условие в работе над сколько-нибудь
серьезными задачами.