Ильдар Хабибуллин - Java 7 [Наиболее полное руководство]

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

Итак, объект sharik, выполняя свой метод eat (), посылает сообщение объекту, ссылка на который содержится в переменной person, с просьбой выдать ему определенное количество еды и питья. Сообщение записано в строке person.getFood(food, drink).

Этим сообщением заключается контракт (contract) между объектами, суть которого в том, что объект sharik берет на себя ответственность (responsibility) задать правильные параметры в сообщении, а другой объект — текущее значение экземпляра person — возлагает на себя ответственность применить метод кормления getFood(), каким бы он ни был.

Для того чтобы правильно реализовать принцип ответственности, применяется четвертый принцип объектно-ориентированного программирования — модульность (modularity).

Этот принцип утверждает: каждый класс должен составлять отдельный модуль. Члены класса, к которым не планируется обращение извне, должны быть инкапсулированы.

В языке Java инкапсуляция достигается добавлением модификатора private к описанию члена класса. Например:

private int mouseCatched; private String name; private void preserve();

Эти члены классов становятся закрытыми , ими могут пользоваться только экземпляры того же самого класса, например tuzik может дать поручение sharik.preserve ().

А если в классе Master мы напишем

private void getFood(int food, int drink);

то метод getFood () не будет найден объектами других классов и несчастный sharik не сможет получить пищу.

В противоположность закрытости мы можем объявить некоторые члены класса открытыми , записав вместо слова private модификатор public, например:

public void getFood(int food, int drink);

К таким членам может обратиться любой объект любого класса.

Знатокам C++

В языке Java словами private, public и protected отмечается каждый член класса в отдельности.

Принцип модульности предписывает открывать члены класса только в случае необходимости. Вспомните надпись на железнодорожном переезде: "Нормальное положение шлагбаума — закрытое".

Если же надо обратиться к закрытому полю класса, то рекомендуется включить в класс специальные методы доступа (access methods), отдельно для чтения этого поля (get method) и отдельно для записи в это поле (set method). Имена методов доступа рекомендуется начинать со слов get и set, добавляя к этим словам имя поля. Для классов Java, используемых как компоненты большого приложения (такие классы-компоненты в технологии Java названы JavaBeans), эти рекомендации возведены в ранг закона.

В нашем примере класса Master методы доступа к полю name в самом простом виде могут выглядеть так:

public String getName(){ return name;

}

public void setName(String newName){ name = newName;

}

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

Кроме методов доступа рекомендуется создавать проверочные is-методы, возвращающие логическое значение true или false. Например, в класс Master можно включить метод, проверяющий, задано ли имя хозяина:

public boolean isEmpty(){ return name == null;

}

и использовать этот метод для проверки при доступе к полю name, например: if (master01.isEmpty()) master01.setName("Иванов");

Итак, мы оставляем открытыми только методы, необходимые для взаимодействия объектов. При этом удобно спланировать классы так, чтобы зависимость между ними была наименьшей, как принято говорить в теории ООП, было наименьшее зацепление (low coupling) между классами. Тогда структура программы сильно упрощается. Кроме того, такие классы удобно использовать как строительные блоки для создания других программ.

Напротив, члены класса должны активно взаимодействовать друг с другом, как говорят, иметь тесную функциональную связность (high cohesion). Для этого в класс следует включать все методы, описывающие поведение моделируемого объекта, и только такие методы, ничего лишнего. Одно из правил достижения сильной функциональной связности, введенное Карлом Либерхером (Karl J. Lieberherr), получило название закона Деметра. Закон гласит: "В методе m () класса а следует использовать только методы класса а, методы классов, к которым принадлежат параметры метода m(), и методы классов, экземпляры которых создаются внутри метода m()".

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

Будут ли закрытые члены класса доступны его наследникам? Если в классе Pet написано

private Master person;

то можно ли использовать sharik.person? Разумеется, нет. Ведь в противном случае каждый, интересующийся закрытыми полями класса а, может расширить его классом в и просмотреть закрытые поля класса а через экземпляры класса в.

Когда надо разрешить доступ наследникам класса, но нежелательно открывать его всему миру, тогда в Java используется защищенный (protected) доступ, отмечаемый модификатором protected, например объект sharik может обратиться к полю person родительского класса Pet, если в классе Pet это поле описано так:

protected Master person;

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

Из этого общего схематического описания принципов объектно-ориентированного программирования видно, что язык Java позволяет легко воплощать все эти принципы. Вы уже поняли, как записать класс, его поля и методы, как инкапсулировать члены класса, как сделать расширение класса и какими принципами следует при этом пользоваться. Разберем теперь подробнее правила записи классов и рассмотрим их дополнительные возможности.

Но, говоря о принципах ООП, я не могу удержаться от того, чтобы не напомнить основной принцип всякого программирования.

Основной, базовый и самый великий принцип программирования на любом языке и при любой парадигме — принцип KISS — не нуждается в переводе. Он расшифровывается так:

"Keep It Simple, Stupid!"

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