Программирование на JAVA

Один из случаев, в котором такой подход приносит необходимую гибкость, уже рассмотрен.

Есть и другие соображения. Например, вернемся к вопросу о кор­ректном использовании объекта и установки верных значений полей. Как следствие, правильное разграничение доступа позволяет ввести механиз­мы проверки входных значений:

public void setAge(int а) { (if а>=0) { age=a;

}

}

В этом примере поле age никогда не примет некорректное отрица­тельное значение. (Недостатком приведенного примера является то, что в случае неправильных входных данных они просто игнорируются, нет ни­каких сообщений, позволяющих узнать, что изменения поля возраста на самом деле не произошло; для полноценной реализации метода необхо­димо освоить работу с ошибками в Java.)

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

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

Таким образом, модификаторы доступа вводятся не для защиты типа °т внешнего пользователя, а, напротив, для защиты, или избавления, Пользователя от излишних зависимостей от деталей внутренней реализа­ции. Что же касается неправильного применения класса,