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

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

Получение величины возраста выглядело бы следующим образом:

Human h - getHuman();

int i=h.getAge(); // обращение через метод

Рассмотрим, как выглядит процесс смены типа поля age:

public class Human {

// поле получает новый тип double private /*int*/ double age;

// старые методы работают с округлением значения public int getAge() {

return (int)Math.round(age);

}

public void setAge(int a) { age=a;

// добавляются новые методы для работы с типом double public double getExactAge() { return age;

}

public void setExactAge(double a) { age=a;

}

}

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

Human h = getHuman();

int i=h.getAge(); // корректно

остается верным, переменная i получает корректное целое значение. Од­нако изменения вводились для того, чтобы можно было работать с дроб­ными величинами. Для этого были добавлены новые методы и во всех ме­стах, где требуется точное значение возраста, необходимо обращаться к ним:

Human h = getHuman();

double d=h.getExactAge(); // точное значение возраста

Итак, в класс была добавлена новая возможность, не потребовавшая никаких изменений кода.

За счет чего была достигнута такая гибкость? Необходимо выделить свойства объекта, которые потребуются будущим пользователям этого класса, и сделать их доступными (в данном случае, public). Те же элемен­ты класса, что содержат детали внутренней реализации логики класса, же­лательно скрывать, чтобы не образовались нежелательные зависимости, которые могут сдерживать развитие системы.

Этот пример одновременно иллюстрирует и другое теоретическое правило написания объектов, а именно: в большинстве случаев доступ к полям лучше реализовывать через специальные методы (accessors) для чтения (getters) и записи (setters). То есть само поле рассматривается как деталь внутренней реализации. Действительно, если рассматривать внешний интерфейс объекта как целиком состоящий из допустимых дей­ствий, то доступными элементами должны быть только методы, реализу­ющие эти действия