Глава 5. Скрытие процесса реализации

"При проведении объектно-ориентированного проектирования одной из основных задач является разделение изменяемых компонентов от неизменяемых."

Это особенно важно для библиотек. Пользователи библиотеки (клиентские программисты) должны иметь возможность полагаться на ту часть библиотеки, которую они используют, и знать, что при выпуске новой версии библиотеки им не придётся менять свой код. В то же время создателям библиотеки должно быть предоставлено свободное пространство для модификаций и улучшений, гарантирующее, что изменения в библиотеке не повлияют на клиентский код.Для достижения этой цели следует придерживаться определённых соглашений или правил. Например, когда библиотечный программист изменяет класс внутри библиотеки, он обязан гарантировать, что существующие методы не будут удалены, так как это может привести к появлению ошибок в коде клиентских программистов. Однако обратная ситуация представляет собой проблему. Как создатель библиотеки может узнать, какие члены данных были использованы клиентскими программистами? Если метод является уникальной частью класса и не используется непосредственно клиентским программистом, эта проблема также актуальна. Если создатель библиотеки хочет удалить старую реализацию и внедрить новую, что делать с теми членами, которые могут вызывать проблемы для клиентского кода? Любое изменение этих членов может привести к прекращению работы клиентского кода. Таким образом, создателю библиотеки оказывается сложно сделать хоть какие-либо изменения.Чтобы решить эту проблему, Java ввела концепцию "уровней доступа", позволяющую создателям библиотек указывать, какие части доступны для использования клиентскими программистами, а какие нет. Уровни доступа варьируются между максимальным уровнем доступа (public) и минимальным (private). Они включают также ключевые слова protected и "дружественный" уровень доступа (без ключевого слова).Согласно вышеописанному, можно заключить, что как дизайнер библиотеки, вы должны стремиться к тому, чтобы все компоненты были как можно более закрытыми (private), и показывали только те методы, которые предназначены для использования клиентскими программистами. Этот подход абсолютно правильный, хотя он противоречит интуиции многих программистов, работающих на других языках (особенно на C), где они привыкли иметь свободный доступ ко всему. К концу этой главы вы сможете глубже понять ценность контроля доступа в Java. Однако концепция библиотечного компонента и компонента управления доступом к этой библиотеке пока ещё не является полной. Вопрос заключается в том, как связывать компоненты с отдельными единицами одного общего хранилища. Это достигается с помощью ключевого слова package в Java, а также влиянием на это оказывают модификаторы доступа, зависящие от того, находится ли класс в одном и том же пакете или в разных пакетах. Поэтому в начале данной главы следует изучить, как библиотечные компоненты помещаются в пакеты, чтобы лучше понять полное значение модификаторов доступа.