Философия java [Брюс Эккель] (fb2) читать онлайн

Чтобы изменить документ по умолчанию, отредактируйте файл "blank.fb2" вручную.

Содержание

Предисловие 13

Java SE5 и SE6 14

Благодарности 14

Глава 1. Введение в объекты 17

Развитие абстракции   18

Объект имеет интерфейс 20

Объект предоставляет услуги 22

Скрытая реализация 23

Повторное использование реализации 24

Наследование 25

Взаимозаменяемые объекты и полиморфизм 29

Однокорневая иерархия 33

Контейнеры 33

Параметризованные типы 35

Создание, использование объектов и время их жизни 36

Обработка исключений: борьба с ошибками 38

Параллельное выполнение  38

Java и Интернет 39

Резюме 47

Глава 2. Все является объектом 48

Для работы с объектами используются ссылки 48

Все объекты должны создаваться явно 49

Объекты никогда не приходится удалять 53

Создание новых типов данных   54

Методы, аргументы и возвращаемые значения 56

Создание программы на Java 58

Ключевое слово static 60

Наша первая программа на Java 61

Комментарии и встроенная документация 64

Стиль оформления программ 70

Резюме 70

Глава 3. Операторы 71

Простые команды печати 71

Операторы Java 72

Литералы 82

В Java отсутствует sizeof() 92

Резюме 100

Глава 4. Управляющие конструкции 101

Синтаксис foreach 105

return,   107

break и continue 108

Нехорошая команда goto 109

Резюме 115

Глава 5. Инициализация и завершение 116

Конструктор гарантирует инициализацию 116

Перегрузка методов 118

Очистка: финализация и сборка мусора 130

Инициализация членов класса 137

Инициализация конструктором 140

Инициализация массивов 146

Резюме 151

Глава 6. Управление доступом 152

Пакет как библиотечный модуль 153

Спецификаторы доступа Java 159

Интерфейс и реализация 163

Доступ к классам 164

Резюме 167

Глава 7. Повторное использование классов 169

Синтаксис композиции 170

Синтаксис наследования 172

Делегирование 176

Сочетание композиции и наследования 178

Композиция в сравнении с наследованием 184

protected 185

Восходящее преобразование типов 186

Ключевое слово final 188

Инициализация и загрузка классов 195

Резюме 197

Глава 8. Полиморфизм 198

Снова о восходящем преобразовании. . . > 199

Особенности 201

Конструкторы и полиморфизм 208

Ковариантность возвращаемых типов 216

Разработка с наследованием 217

Резюме 220

Глава 9. Интерфейсы 221

Абстрактные классы и методы 221

Интерфейсы 224

Отделение интерфейса от реализации 227

Расширение интерфейса через наследование 233

Интерфейсы как средство адаптации 236

Вложенные интерфейсы 239

Интерфейсы и фабрики 242

Резюме 244

Глава 10. Внутренние классы 245

Создание внутренних классов 245

Связь с внешним классом 246

Конструкции .this и .new 248

Внутренние классы и восходящее преобразование 249

Безымянные внутренние классы 253

Внутренние классы: зачем? 261

Наследование от внутренних классов 272

Можно ли переопределить внутренний класс? 272

Локальные внутренние классы 274

Резюме 276

Глава 11. Коллекции объектов 277

Параметризованные и типизованные контейнеры 277

Основные концепции 280

Добавление групп элементов 281

List 285

Итераторы 288

LinkedList 291

Стек 292

Множество 294

Карта 296

Очередь 298

PriorityQueue 299

Collection и Iterator 301

Идиома «метод-адаптер» 306

Резюме 309

Глава 12. Обработка ошибок и исключения 310

Основные исключения 310

Перехват исключений 312

Создание собственных исключений 314

Спецификации исключений 319

Перехват произвольных исключений 320

Стандартные исключения Java 328

Завершение с помощью finally 330

Использование finally с return 334

Ограничения при использовании исключений 336

Конструкторы 339

Идентификация исключений 343

Альтернативные решения 344

Резюме 351

Глава 13. Информация о типах 352

Необходимость в динамическом определении типов (RTTI) 352

Регистрация фабрик 372

Рефлексия: динамическая информация о классе 376

Динамические посредники 380

Объекты с неопределенным состоянием 384

Интерфейсы и информация о типах 390

Резюме 394

Глава 14. Параметризация 397

Простая параметризация 398

Параметризованные интерфейсы 404

Параметризованные методы 407

Построение сложных моделей 419

Ограничения 437

Метасимволы 440

Резюме 452

Глава 15. Массивы 454

Особенности массивов 454

Массив как объект 456

Возврат массива 458

Многомерные массивы 460

Массивы и параметризация 463

Создание тестовых данных 465

Создание массивов с использованием генераторов 470

Вспомогательный инструментарий Arrays 474

Резюме 482

Глава 16. Система ввода/вывода Java 483

Класс File 484

Ввод и вывод 489

Добавление атрибутов и интерфейсов 491

Классы Reader и Writer 494

RandomAccessFile: сам по себе 497

Типичное использование потоков ввода/вывода 498

Средства чтения и записи файлов 505

Стандартный ввод/вывод 507

Новый ввод/вывод (nio)  510

Сжатие данных 531

Сериализация объектов 536

Предпочтения 553

Резюме 555

Глава 17. Параллельное выполнение 557

Класс Thread 559

Исполнители 561

Совместное использование ресурсов 578

Взаимодействие между потоками 598

Взаимная блокировка 602

Новые библиотечные компоненты 607

CountDownLatch 607

CyclicBarrier 609

DelayQueue 611

PriorityBlockingQueue 614

Семафоры 619

Exchanger 623

Моделирование 624

Резюме 629

Алфавитный указатель 631

Введение в объекты

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

Бенджамин Ли Ворф (1897-1941)

Возникновением компьютерной революции мы обязаны машине. Поэтому наши языки программирования стараются быть ближе к этой машине.

Но в то же время компьютеры не столько механизмы, сколько средства уси¬ления мысли («велосипеды для ума», как любит говорить Стив Джобе), и еще одно средство самовыражения. В результате инструменты программирования все меньше склоняются к машинам и все больше тяготеют к нашим умам, также как и к другим формам выражения человеческих устремлений, как-то: литера¬тура, живопись, скульптура, анимация и кинематограф. Объектно-ориентиро- ванное программирование (ООП) — часть превращения компьютера в средство самовыражения.

Эта глава познакомит вас с основами ООП, включая рассмотрение основ¬ных методов разработки программ. Она, и книга вообще, подразумевает нали¬чие у вас опыта программирования на процедурном языке, не обязательно С. Если вам покажется, что перед прочтением этой книги вам не хватает познаний в программировании и синтаксисе С, воспользуйтесь мультимедийным семина¬ром Thinking in С, который можно загрузить с сайта www.MindView.net.

Настоящая глава содержит подготовительный и дополнительный материалы. Многие читатели предпочитают сначала представить себе общую картину, а уже потом разбираться в тонкостях ООП. Поэтому многие идеи в данной главе слу¬жат тому, чтобы дать вам цельное представление об ООП. Однако многие люди не воспринимают общей идеи до тех пор, пока не увидят конкретно, как все ра¬ботает; такие люди нередко вязнут в общих словах, не имея перед собой приме¬ров. Если вы принадлежите к последним и горите желанием приступить к осно¬вам языка, можете сразу перейти к следующей главе — пропуск этой не будет препятствием для написания программ или изучения языка. И все же чуть позже вам стоит вернуться к этой главе, чтобы расширить свой кругозор и по¬нять, почему так важны объекты и какое место они занимают при проектирова¬нии программ.

Развитие абстракции

Все языки программирования построены на абстракции. Возможно, трудность решаемых задач напрямую зависит от типа и качества абстракции. Под словом «тип» я имею в виду: «Что конкретно мы абстрагируем?» Язык ассемблера есть небольшая абстракция от компьютера, на базе которого он работает. Мно¬гие так называемые «командные» языки, созданные вслед за ним (такие,* как Fortran, BASIC и С), представляли собой абстракции следующего уровня. Эти языки обладали значительным преимуществом по сравнению с ассемблером, но их основная абстракция по-прежнему заставляет думать вас о структуре компьютера, а не о решаемой задаче. Программист должен установить связь ме¬жду моделью машины (в «пространстве решения», которое представляет место, где реализуется решение, — например, компьютер) и моделью задачи, которую и нужно решать (в «пространстве задачи», которое является местом существо¬вания задачи — например, прикладной областью). Для установления связи тре¬буются усилия, оторванные от собственно языка программирования; в резуль¬тате появляются программы, которые трудно писать и тяжело поддерживать. Мало того, это еще создало целую отрасль «методологий программирования».

Альтернативой моделированию машины является моделирование решаемой задачи. Ранние языки, подобные LISP и APL, выбирали особый подход к моде¬лированию окружающего мира («Все задачи решаются списками» или «Алго¬ритмы решают все» соответственно). PROLOG трактует все проблемы как це¬почки решений. Были созданы языки для программирования, основанного на сис¬теме ограничений, и специальные языки, в которых программирование осуще¬ствлялось посредством манипуляций с графическими конструкциями (область применения последних оказалась слишком узкой). Каждый из этих подходов хорош в определенной области решаемых задач, но стоит выйти из этой сферы, как использовать их становится затруднительно.

Объектный подход делает шаг вперед, предоставляя программисту средства для представления задачи в ее пространстве. Такой подход имеет достаточно общий характер и не накладывает ограничений на тип решаемой проблемы. Элементы пространства задачи и их представления в пространстве решения на¬зываются «объектами». (Вероятно, вам понадобятся и другие объекты, не имеющие аналогов в пространстве задачи.) Идея состоит в том, что програм¬ма может адаптироваться к специфике задачи посредством создания новых ти¬пов объектов так, что во время чтения кода, решающего задачу, вы одновремен¬но видите слова, ее описывающие. Это более гибкая и мощная абстракция, превосходящая по своим возможностям все, что существовало ранее . Таким

Развитие абстракции 19

образом, ООП позволяет описать задачу в контексте самой задачи, а не в кон¬тексте компьютера, на котором будет исполнено решение. Впрочем, связь с компьютером все же сохранилась. Каждый объект похож на маленький ком¬пьютер; у него есть состояние и операции, которые он позволяет проводить. Та¬кая аналогия неплохо сочетается с внешним миром, который есть «реальность, данная нам в объектах», имеющих характеристики и поведение.

Алан Кей подвел итог и вывел пять основных черт языка Smalltalk — перво¬го удачного объектно-ориентированного языка, одного из предшественников Java. Эти характеристики представляют «чистый», академический подход к объектно-ориентированному программированию:

• Все является объектом. Представляйте себе объект как усовершенство¬ванную переменную; он хранит данные, но вы можете «обращаться с за¬просами» к объекту, требуя у него выполнить операции над собой. Теоре¬тически абсолютно любой компонент решаемой задачи (собака, здание, услуга и т. п.) может быть представлен в виде объекта.

• Программа — это группа объектов, указывающих друг другу, что де¬лать, посредством сообщений. Чтобы обратиться с запросом к объекту, вы «посылаете ему сообщение». Более наглядно можно представить сооб¬щение как вызов метода, принадлежащего определенному объекту.

• Каждый объект имеет собственную «память», состоящую из других объектов. Иными словами, вы создаете новый объект с помощью встраи¬вания в него уже существующих объектов. Таким образом, можно сконст¬руировать сколь угодно сложную программу, скрыв общую сложность за простотой отдельных объектов.

• У каждого объекта есть тип. В других терминах, каждый объект являет¬ся экземпляром класса, где «класс» является аналогом слова «тип». Важ¬нейшее отличие классов друг от друга как раз и заключается в ответе на вопрос: «Какие сообщения можно посылать объекту?»

• Все объекты определенного типа могут получать одинаковые сообще¬ния. Как мы вскоре убедимся, это очень важное обстоятельство. Так как объект типа «круг» также является объектом типа «фигура», справедливо утверждение, что «круг» заведомо способен принимать сообщения для «фигуры». А это значит, что можно писать код для фигур и быть уверен¬ным в том, что он подойдет для всего, что попадает под понятие фигуры. Взаимозаменяемость представляет одно из самых мощных понятий ООП.

Буч предложил еще более лаконичное описание объекта:

Объект обладает состоянием, поведением и индивидуальностью.

Суть сказанного в том, что объект может иметь в своем распоряжении внут¬ренние данные (которые и есть состояние объекта), методы (которые опреде¬ляют поведение), и каждый объект можно уникальным образом отличить от любого другого объекта — говоря более конкретно, каждый объект обладает уникальным адресом в памяти .

Объект имеет интерфейс

Вероятно, Аристотель был первым, кто внимательно изучил понятие типа\ он говорил о «классе рыб и классе птиц». Концепция, что все объекты, будучи уникальными, в то же время являются частью класса объектов со сходными ха¬рактеристиками и поведением, была использована в первом объектно-ориенти¬рованном языке Simula-67, с введением фундаментального ключевого слова class, которое вводило новый тип в программу.

Язык Simula, как подразумевает его имя, был создан для развития и модели¬рования ситуаций, подобных классической задаче «банковский кассир». У вас есть группы кассиров, клиентов, счетов, платежей и денежных единиц — много «объектов». Объекты, идентичные во всем, кроме внутреннего состояния во время работы программы, группируются в «классы объектов». Отсюда и пришло ключевое слово class. Создание абстрактных типов данных есть фун¬даментальное понятие во всем объектно-ориентированном программировании. Абстрактные типы данных действуют почти так же, как и встроенные типы: вы можете создавать переменные типов (называемые объектами или экземплярами в терминах ООП) и манипулировать ими (что называется посылкой сообщений или запросом; вы производите запрос, и объект решает, что с ним делать). Чле¬ны (элементы) каждого класса обладают сходством: у каждого счета имеется баланс, каждый кассир принимает депозиты, и т. п. В то же время все члены от¬личаются внутренним состоянием: у каждого счета баланс индивидуален, каж¬дый кассир имеет человеческое имя. Поэтому все кассиры, заказчики, счета, пе¬реводы и прочее могут быть представлены уникальными сущностями внутри компьютерной программы. Это и есть суть объекта, и каждый объект принад¬лежит к определенному классу, который определяет его характеристики и по¬ведение.

Таким образом, хотя мы реально создаем в объектных языках новые типы данных, фактически все эти языки используют ключевое слово «класс». Когда видите слово «тип», думайте «класс», и наоборот .

Поскольку класс определяет набор объектов с идентичными характеристи¬ками (элементы данных) и поведением (функциональность), класс на самом деле является типом данных, потому что, например, число с плавающей запя¬той тоже имеет ряд характеристик и особенности поведения. Разница состоит в том, что программист определяет класс для представления некоторого аспек¬та задачи, вместо использования уже существующего типа, представляющего единицу хранения данных в машине. Вы расширяете язык программирования, добавляя новые типы данных, соответствующие вашим потребностям. Система программирования благосклонна к новым классам и уделяет им точно такое же внимание, как и встроенным типам.

Объектно-ориентированный подход не ограничен построением моделей. Со¬гласитесь вы или нет, что любая программа — модель разрабатываемой вами

Объект имеет интерфейс 21

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

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

Но как заставить объект выполнять нужные вам действия? Должен сущест¬вовать механизм передачи запроса к объекту на выполнение некоторого дейст¬вия — завершения транзакции, рисования на экране и т. д. Каждый объект умеет выполнять только определенный круг запросов. Запросы, которые вы можете посылать объекту, определяются его интерфейсом, причем интерфейс объекта определяется его типом. Простейшим примером может стать электрическая лампочка:

Имя типа

Интерфейс

Light It = new LightO,

It on().

Интерфейс определяет, какие запросы вы вправе делать к определенному объекту. Однако где-то должен существовать и код, выполняющий запросы. Этот код, наряду со скрытыми данными, составляет реализацию. С точки зре¬ния процедурного программирования происходящее не так уж сложно. Тип со¬держит метод для каждого возможного запроса, и при получении определенно¬го запроса вызывается нужный метод. Процесс обычно объединяется в одно целое: и «отправка сообщения» (передача запроса) объекту, и его обработка объектом (выполнение кода).

В данном примере существует тип (класс) с именем Light (лампа), конкрет¬ный объект типа Light с именем It, и класс поддерживает различные запросы к объекту Light: выключить лампочку, включить, сделать ярче или притушить. Вы создаете объект Light, определяя «ссылку» на него (It) и вызывая оператор new для создания нового экземпляра этого типа. Чтобы послать сообщение объ¬екту, следует указать имя объекта и связать его с нужным запросом знаком точки. С точки зрения пользователя заранее определенного класса, этого вполне дос¬таточно для того, чтобы оперировать его объектами.

Диаграмма, показанная выше, следует формату UML (Unified Modeling Lan¬guage). Каждый класс представлен прямоугольником, все описываемые поля данных помещены в средней его части, а методы (функции объекта, которому вы посылаете сообщения) перечисляются в нижней части прямоугольника.

Часто на диаграммах UML показываются только имя класса и открытые методы, а средняя часть отсутствует. Если же вас интересует только имя класса, то мо¬жете пропустить и нижнюю часть.

Объект предоставляет услуги

В тот момент, когда вы пытаетесь разработать или понять структуру программы, часто бывает полезно представить объекты в качестве «поставщиков услуг». Ваша программа оказывает услуги пользователю, и делает она это посредством услуг, предоставляемых другими объектами. Ваша цель — произвести (а еще лучше отыскать в библиотеках классов) тот набор объектов, который будет оп¬тимальным для решения вашей задачи.

Для начала спросите себя: «если бы я мог по волшебству вынимать объекты из шляпы, какие бы из них смогли решить мою задачу прямо сейчас?» Предпо¬ложим, что вы разрабатываете бухгалтерскую программу. Можно представить себе набор объектов, предоставляющих стандартные окна для ввода бухгалтер¬ской информации, еще один набор объектов, выполняющих бухгалтерские рас¬четы, объект, ведающий распечаткой чеков и счетов на всевозможных принте¬рах. Возможно, некоторые из таких объектов уже существуют, а для других объектов стоит выяснить, как они могли бы выглядеть. Какие услуги могли бы предоставлять те объекты, и какие объекты понадобились бы им для выполне¬ния своей работы? Если вы будете продолжать в том же духе, то рано или позд¬но скажете: «Этот объект достаточно прост, так что можно сесть и записать его», или «Наверняка такой объект уже существует». Это разумный способ рас¬пределить решение задачи на отдельные объекты.

Представление объекта в качестве поставщика услуг обладает дополнитель¬ным преимуществом: оно помогает улучшить связуемостъ (cohesiveness) объекта. Хорошая связуемостъ — важнейшее качество программного продукта: она озна¬чает, что различные аспекты программного компонента (такого как объект, хотя сказанное также может относиться к методу или к библиотеке объектов) хорошо «стыкуются» друг с другом. Одной из типичных ошибок, допускаемых при проектировании объекта, является перенасыщение его большим количест¬вом свойств и возможностей. Например, при разработке модуля, ведающего распечаткой чеков, вы можете захотеть, чтобы он «знал» все о форматировании и печати. Если подумать, скорее всего, вы придете к выводу, что для одного объекта этого слишком много, и перейдете к трем или более объектам. Один объект будет представлять собой каталог всех возможных форм чеков, и его можно будет запросить о том, как следует распечатать чек. Другой объект или набор объектов станут отвечать за обобщенный интерфейс печати, «знающий» все о различных типах принтеров (но ничего не «понимающий» в бухгалте¬рии — такой объект лучше купить, чем разрабатывать самому). Наконец, тре¬тий объект просто будет пользоваться услугами описанных объектов, для того чтобы выполнить задачу. Таким образом, каждый объект представляет собой связанный набор предлагаемых им услуг. В хорошо спланированном объект¬но-ориентированном проекте каждый объект хорошо справляется с одной конкретной задачей, не пытаясь при этом сделать больше нужного. Как было показано, это не только позволяет определить, какие объекты стоит приобрести (объект с интерфейсом печати), но также дает возможность получить в итоге объект, который затем можно использовать где-то еще (каталог чеков).

Представление объектов в качестве поставщиков услуг значительно упроща¬ет задачу. Оно полезно не только во время разработки, но и когда кто-либо по¬пытается понять ваш код или повторно использовать объект — тогда он сможет адекватно оценить объект по уровню предоставляемого сервиса, и это значи¬тельно упростит интеграцию последнего в другой проект.

Скрытая реализация

Программистов полезно разбить на создателей классов (те, кто создает новые типы данных) и программистов-клиентов (потребители классов, использующие типы данных в своих приложениях). Цель вторых — собрать как можно больше классов, чтобы заниматься быстрой разработкой программ. Цель создателя класса — построить класс, открывающий только то, что необходимо программи¬сту-клиенту, и прячущий все остальное. Почему? Программист-клиент не смо¬жет получить доступ к скрытым частям, а значит, создатель классов оставляет за собой возможность произвольно их изменять, не опасаясь, что это кому-то повредит. «Потаенная» часть обычно и самая «хрупкая» часть объекта, которую легко может испортить неосторожный или несведущий программист-клиент, поэтому сокрытие реализации сокращает количество ошибок в программах.

В любых отношениях важно иметь какие-либо границы, не переступаемые никем из участников. Создавая библиотеку, вы устанавливаете отношения с программистом-клиентом. Он является таким же программистом, как и вы, но будет использовать вашу библиотеку для создания приложения (а может быть, библиотеки более высокого уровня). Если предоставить доступ ко всем членам класса кому угодно, программист-клиент сможет сделать с классом все, что ему заблагорассудится, и вы никак не сможете заставить его «играть по пра¬вилам». Даже если вам впоследствии понадобится ограничить доступ к опреде¬ленным членам вашего класса, без механизма контроля доступа это осущест¬вить невозможно. Все строение класса открыто для всех желающих.

Таким образом, первой причиной для ограничения доступа является необхо¬димость уберечь «хрупкие» детали от программиста-клиента — части внутрен¬ней «кухни», не являющиеся составляющими интерфейса, при помощи которого пользователи решают свои задачи. На самом деле это полезно и пользователям — они сразу увидят, что для них важно, а что они могут игнорировать.

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

Java использует три явных ключевых слова, характеризующих уровень дос¬тупа: public, private и protected. Их предназначение и употребление очень про¬сты. Эти спецификаторы доступа определяют, кто имеет право использовать следующие за ними определения. Слово public означает, что последующие опре¬деления доступны всем. Наоборот, слово private значит, что следующие за ним предложения доступны только создателю типа, внутри его методов. Термин private — «крепостная стена» между вами и программистом-клиентом. Если кто-то по¬пытается использовать private-члены, он будет остановлен ошибкой компиля¬ции. Спецификатор protected действует схоже с private, за одним исключени¬ем — производные классы имеют доступ к членам, помеченным protected, но не имеют доступса к private-членам (наследование мы вскоре рассмотрим).

В Java также есть доступ «по умолчанию», используемый при отсутствии како¬го-либо из перечисленных спецификаторов. Он также иногда называется дос¬тупом в пределах пакета (package access), поскольку классы могут использовать дружественные члены других классов из своего пакета, но за его пределами те же дружественные члены приобретают статус private.

Повторное использование реализации

Созданный и протестированный класс должен (в идеале) представлять собой полезный блок кода. Однако оказывается, что добиться этой цели гораздо труд¬нее, чем многие полагают; для разработки повторно используемых объектов требуется опыт и понимание сути дела. Но как только у вас получится хорошая конструкция, она будет просто напрашиваться на внедрение в другие программы. Многократное использование кода — одно из самых впечатляющих преиму¬ществ объектно-ориентированных языков.

Проще всего использовать класс повторно, непосредственно создавая его объект, но вы можете также поместить объект этого класса внутрь нового класса. Мы называем это внедрением объекта. Новый класс может содержать любое ко¬личество объектов других типов, в любом сочетании, которое необходимо для достижения необходимой функциональности. Так как мы составляем новый класс из уже существующих классов, этот способ называется композицией (если композиция выполняется динамически, она обычно именуется агрегировани¬ем). Композицию часто называют связью типа «имеет» (has-a), как, например, в предложении «у автомобиля есть двигатель».

Автомобиль  Двигатель

(На UML-диаграммах композиция обозначается закрашенным ромбом. Я несколько упрощу этот формат: оставлю только простую линию, без ромба, чтобы обозначить связь .)

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

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

Наследование

Сама по себе идея объекта крайне удобна. Объект позволяет совмещать данные и функциональность на концептуальном уровне, то есть вы можете представить нужное понятие проблемной области прежде, чем начнете его конкретизиро¬вать применительно к диалекту машины. Эти концепции и образуют фундамен¬тальные единицы языка программирования, описываемые с помощью ключево¬го слова class.

(Стрелка на UML-диаграмме направлена от производного класса к базовому классу. Как вы вскоре увидите, может быть и больше одного производного класса.)

Но согласитесь, было бы обидно создавать какой-то класс, а потом проделы¬вать всю работу заново для похожего класса. Гораздо рациональнее взять гото¬вый класс, «клонировать» его, а затем внести добавления и обновления в полу¬ченный клон. Это именно то, что вы получаете в результате наследования, с одним исключением — если изначальный класс (называемый также базовым- классом, суперклассом или родительским классом) изменяется, то все измене¬ния отражаются и на его «клоне» (называемом производным классом, унаследо¬ванным классом, подклассом или дочерним классом).

Тип определяет не только свойства группы объектов; он также связан с дру¬гими типами. Два типа могут иметь общие черты и поведение, но различаться количеством характеристик, а также способностью обработать большее число сообщений (или обработать их по-другому). Для выражения этой общности ти¬пов при наследовании используется понятие базовых и производных типов. Ба¬зовый тип содержит все характеристики и действия, общие для всех типов, про¬изводных от него. Вы создаете базовый тип, чтобы представить основу своего представления о каких-то объектах в вашей системе. От базового типа порож¬даются другие типы, выражающие другие реализации этой сущности.

Например, машина по переработке мусора сортирует отходы. Базовым ти¬пом будет «мусор», и каждая частица мусора имеет вес, стоимость и т. п., и мо¬жет быть раздроблена, расплавлена или разложена. Отталкиваясь от этого, на¬следуются более определенные виды мусора, имеющие дополнительные характеристики (бутылка имеет цвет) или черты поведения (алюминиевую банку можно смять, стальная банка притягивается магнитом). Вдобавок, неко¬торые черты поведения могут различаться (стоимость бумаги зависит от ее типа и состояния). Наследование позволяет составить иерархию типов, описы¬вающую решаемую задачу в контексте ее типов.

Второй пример — классический пример с геометрическими фигурами. Базо¬вым типом здесь является «фигура», и каждая фигура имеет размер, цвет, рас¬положение и т. п. Каждую фигуру можно нарисовать, стереть, переместить, за¬красить р т. д. Далее производятся (наследуются) конкретные разновидности фигур: окружность, квадрат, треугольник и т. п., каждая из которых имеет свои дополнительные характеристики и черты поведения. Например, для некоторых фигур поддерживается операция зеркального отображения. Отдельные черты поведения могут различаться, как в случае вычисления площади фигуры. Ие¬рархия типов воплощает как схожие, так и различные свойства фигур.

Приведение решения к понятиям, использованным в примере, чрезвычайно удобно, потому что вам не потребуется множество промежуточных моделей, связывающих описание решения с описанием задачи. При работе с объектами первичной моделью становится иерархия типов, так что вы переходите от опи¬сания системы реального мира прямо к описанию системы в программном коде. На самом деле одна из трудностей в объектно-ориентированном планировании состоит в том, что уж очень просто вы проходите от начала задачи до конца ре¬шения. Разум, натренированный на сложные решения, часто заходит в тупик при использовании простых подходов.

Используя наследование от существующего типа, вы создаете новый тип. Этот новый тип не только содержит все члены существующего типа (хотя члены, помеченные как private, скрыты и недоступны), но и, что еще важнее, повторя¬ет интерфейс базового класса. Значит, все сообщения, которые вы могли по¬сылать базовому классу, вы также вправе посылать и производному классу. А так как мы различаем типы классов по совокупности сообщений, которые мо¬жем им посылать, это означает, что производный класс является частным слу¬чаем базового класса. В предыдущем примере «окружность есть фигура». Экви¬валентность типов, достигаемая при наследовании, является одним из осно¬вополагающих условий понимания смысла объектно-ориентированного про¬граммирования.

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

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

Хотя наследование иногда наводит на мысль, что интерфейс будет дополнен новыми методами (особенно в Java, где наследование обозначается ключевым словом extends, то есть «расширять»), это совсем не обязательно. Второй, более важный способ модификации классов заключается в изменении поведения уже существующих методов базового класса. Это называется переопределением (или замещением) метода.

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

Отношение «является» в сравнении с «похоже»

При использовании наследования встает очевидный вопрос: следует ли при на¬следовании переопределять только методы базового класса (и не добавлять но¬вые методы, не существующие в базовом классе)? Это означало бы, что произ¬водный тип будет точно такого же типа, как и базовый класс, так как они имеют одинаковый интерфейс. В результате вы можете свободно заменять объ¬екты базового класса объектами производных классов. Можно говорить о пол¬ной замене, и это часто называется принципом замены. В определенном смысле это способ наследования идеален. Подобный способ взаимосвязи базового и производного классов часто называют связью «является тем-то», поскольку можно сказать «круг есть фигура». Чтобы определить, насколько уместным бу¬дет наследование, достаточно проверить, существует ли отношение «является» между классами и насколько оно оправданно.

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

Предположим, что ваш дом снабжен всем необходимым оборудованием для контроля процесса охлаждения. Представим теперь, что кондиционер сломался и вы заменили его обогревателем, способным как нагревать, так и охлаждать. Обогреватель «похож на» кондиционер, но он способен и на большее. Так как система управления вашего дома способна контролировать только охлаждение, она ограничена в коммуникациях с охлаждающей частью нового объекта. Ин¬терфейс нового объекта был расширен, а существующая система ничего не при¬знает, кроме оригинального интерфейса.

Конечно, при виде этой иерархии становится ясно, что базовый класс «охла¬ждающая система» недостаточно гибок; его следует переименовать в «систему контроля температуры» так, чтобы он включал и нагрев, — и после этого зара¬ботает принцип замены. Тем не менее эта диаграмма представляет пример того, что может произойти в реальности.

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

Взаимозаменяемые объекты и полиморфизм

При использовании иерархий типов часто приходится обращаться с объектом определенного типа как с базовым типом. Это позволяет писать код, не завися¬щий от конкретных типов. Так, в примере с фигурами методы манипулируют просто фигурами, не обращая внимания на то, являются ли они окружностями, прямоугольниками, треугольниками или некоторыми еще даже не определен¬ными фигурами. Все фигуры могут быть нарисованы, стерты и перемещены, а методы просто посылают сообщения объекту «фигура»; им безразлично, как объект обойдется с этим сообщением.

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

Однако при попытке обращения к объектам производных типов как к базо¬вым типам (окружности как фигуре, велосипеду как средству передвижения, баклану как птице и т. п.) возникает одна проблема. Если метод собирается приказать обобщенной фигуре нарисовать себя, или средству передвижения следовать по определенному курсу, или птице полететь, компилятор не может точно знать, какая именно часть кода выполнится. В этом все дело — когда по¬сылается сообщение, программист и не хочет знать, какой код выполняется; метод прорисовки с одинаковым успехом может применяться и к окружности, и к прямоугольнику, и к треугольнику, а объект выполнит верный код, завися¬щий от его характерного типа.

Если вам не нужно знать, какой именно фрагмент кода выполняется, то, ко¬гда вы добавляете новый подтип, код его реализации может измениться, но без изменений в том методе, из которого он был вызван. Если компилятор не обла¬дает информацией, какой именно код следует выполнить, что же он делает? В следующем примере объект BirdController (управление птицей) может рабо¬тать только с обобщенными объектами Bird (птица), не зная типа конкретного объекта. С точки зрения BirdController это удобно, поскольку для него не придет¬ся писать специальный код проверки типа используемого объекта Bird для об¬работки какого-то особого поведения. Как же все-таки происходит, что при вы¬зове метода move() без указания точного типа Bird исполняется верное дейст¬вие — объект Goose (гусь) бежит, летит или плывет, а объект Penguin (пингвин) бежит или плывет?

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

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

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

В некоторых языках необходимо явно указать, что для метода должен ис¬пользоваться гибкий механизм позднего связывания (в С++ для этого преду¬смотрено ключевое слово virtual). В этих языках методы по умолчанию компо¬нуются не динамически. В Java позднее связывание производится по умолча¬нию, и вам не нужно помнить о необходимости добавления каких-либо ключе¬вых слов для обеспечения полиморфизма.

Вспомним о примере с фигурами. Семейство классов (основанных на одина¬ковом интерфейсе) было показано на диаграмме чуть раньше в этой главе. Для демонстрации полиморфизма мы напишем фрагмент кода, который игнорирует характерные особенности типов и работаеттолько с базовым классом. Этот код отделен от специфики типов, поэтому его проще писать и понимать. И если но¬вый тип (например, шестиугольник) будет добавлен посредством наследова¬ния, то написанный вами код будет работать для нового типа фигуры так же хо¬рошо, как прежде. Таким образом, программа становится расширяемой.

Допустим, вы написали на Java следующий метод (вскоре вы узнаете, как это делать):

void doSomething(Shape shape) { shape.eraseO: II стереть II...

shape.drawO, II нарисовать }

Метод работает с обобщенной фигурой (Shape), то есть не зависит от кон¬кретного типа объекта, который рисуется или стирается. Теперь мы используем вызов метода doSomething() в другой части программы:

Circle circle = new CircleO. // окружность Triangle triangle = new TriangleO; II треугольник Line line = new LineO; // линия doSomething(circle). doSomething(triangle). doSomething( line);

Вызовы метода doStuff() автоматически работают правильно, вне зависимо¬сти от фактического типа объекта. На самом деле это довольно важный факт. Рассмотрим строку:

doSomething(c);

Здесь происходит следующее: методу, ожидающему объект Shape, передается объект «окружность» (Circle). Так как окружность (Circle) одновременно являет¬ся фигурой (Shape), то метод doSomething() и обращается с ней, как с фигурой. Другими словами, любое сообщение, которое метод может послать Shape, также принимается и Circle. Это действие совершенно безопасно и настолько же ло¬гично.

Мы называем этот процесс обращения с производным типом как с базовым восходящим преобразованием типов. Слово преобразование означает, что объект трактуется как принадлежащий к другому типу, а восходящее оно потому, что на диаграммах наследования базовые классы обычно располагаются вверху, а производные классы располагаются внизу «веером». Значит, преобразование к базовому типу — это движение по диаграмме вверх, и поэтому оно «восходя¬щее».

Объектно-ориентированная программа почти всегда содержит восходящее преобразование, потому что именно так вы избавляетесь от необходимости знать точный тип объекта, с которым работаете. Посмотрите на тело метода doSomething():

shape erase().

// .

shape drawO,

Заметьте, что здесь не сказано «если ты объект Circle, делай это, а если ты объект Square, делай то-то и то-то». Такой код с отдельными действиями для ка¬ждого возможного типа Shape будет путаным, и его придется менять каждый раз при добавлении нового подтипа Shape. А так, вы просто говорите: «Ты фигура, и я знаю, что ты способна нарисовать и стереть себя, ну так и делай это, а о де¬талях позаботься сама».

В коде метода doSomething() интересно то, что все само собой получается правильно. При вызове draw() для объекта Circle исполняется другой код, а не тот, что отрабатывает при вызове draw() для объектов Square или Line, а когда draw() применяется для неизвестной фигуры Shape, правильное поведение обеспечива¬ется использованием реального типа Shape. Это в высшей степени интересно, потому что, как было замечено чуть ранее, когда компилятор генерирует код doSomething(), он не знает точно, с какими типами он работает. Соответственно, можно было бы ожидать вызова версий методов draw() и erase() из базового класса Shape, а не их вариантов из конкретных классов Circle, Square или Line. И тем не менее все работает правильно благодаря полиморфизму. Компилятор и система исполнения берут на себя все подробности; все, что вам нужно знать, — как это происходит... и, что еще важнее, как создавать программы, используя такой подход. Когда вы посылаете сообщение объекту, объект выбе¬рет правильный вариант поведения даже при восходящем преобразовании.

Однокорневая иерархия

Вскоре после появления С++ стал активно обсуждаться вопрос — должны ли все классы обязательно наследовать от единого базового класса? В Java (как практически во всех других ООП-языках, кроме С++) на этот вопрос был дан положительный ответ. В основе всей иерархии типов лежит единый базовый класс Object. Оказалось, что однокорневая иерархия имеет множество преиму¬ществ.

Все объекты в однокорневой иерархии имеют некий общий интерфейс, так что по большому счету все они могут рассматриваться как один основополагаю¬щий тип. В С++ был выбран другой вариант — общего предка в этом языке не существует. С точки зрения совместимости со старым кодом эта модель лучше соответствует традициям С, и можно подумать, что она менее ограничена. Но как только возникнет необходимость в полноценном объектно-ориентирован¬ном программировании, вам придется создавать собственную иерархию клас¬сов, чтобы получить те же преимущества, что встроены в другие ООП-языки. Да и в любой новой библиотеке классов вам может встретиться какой-нибудь несо¬вместимый интерфейс. Включение этих новых интерфейсов в архитектуру ва¬шей программы потребует лишних усилий (и возможно, множественного насле¬дования). Стоит ли дополнительная «гибкость» С++ подобных издержек? Если вам это нужно (например, при больших вложениях в разработку кода С), то в проигрыше вы не останетесь. Если же разработка начинается «с нуля», подход Java выглядит более продуктивным.

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

Однокорневая иерархия позволяет гораздо проще реализовать уборку мусо¬ра — одно из важнейших усовершенствований Java по сравнению с С++. Так как информация о типе во время исполнения гарантированно присутствует в любом из объектов, в системе никогда не появится объект, тип которого не удастся определить. Это особенно важно при выполнении системных опера¬ций, таких как обработка исключений, и для обеспечения большей гибкости программирования.

Контейнеры

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

Многие проблемы в объектно-ориентированном программировании реша¬ются простым действием: вы создаете еще один тип объекта. Новый тип объекта, решающего эту конкретную задачу, содержит ссылки на другие объекты. Конечно, эту роль могут исполнить и массивы, поддерживаемые в большин¬стве языков. Однако новый объект, обычно называемый контейнером (или же коллекцией, но в Java этот термин используется в другом смысле), будет по не¬обходимости расширяться, чтобы вместить все, что вы в него положите. По¬этому вам не нужно будет знать загодя, на сколько объектов рассчитана ем¬кость контейнера. Просто создайте контейнер, а он уже позаботится о подроб¬ностях.

К счастью, хороший ООП-язык поставляется с набором готовых контейне¬ров. В С++ это часть стандартной библиотеки С++, иногда называемая библио¬текой стандартных шаблонов (Standard Template Library, STL). Smalltalk по¬ставляется с очень широким набором контейнеров. Java также содержит кон¬тейнеры в своей стандартной библиотеке. Для некоторых библиотек считается, что достаточно иметь один единый контейнер для всех нужд, но в других (на¬пример, в Java) предусмотрены различные контейнеры на все случаи жизни: не¬сколько различных типов списков List (для хранения последовательностей эле¬ментов), карты Map (известные также как ассоциативные массивы, позволяют связывать объекты с другими объектами), а также множества Set (обеспечиваю¬щие уникальность значений для каждого типа). Контейнерные библиотеки так¬же могут содержать очереди, деревья, стеки и т. п.

С позиций проектирования, все, что вам действительно необходимо, — это контейнер, способный решить вашу задачу. Если один вид контейнера отвечает всем потребностям, нет основания использовать другие виды. Существует две причины, по которым вам приходится выбирать из имеющихся контейнеров. Во-первых, контейнеры предоставляют различные интерфейсы и возможности взаимодействия. Поведение и интерфейс стека отличаются от поведения и ин¬терфейса очереди, которая ведет себя по-иному, чем множество или список. Один из этих контейнеров способен обеспечить более эффективное решение вашей задачи в сравнении с остальными. Во-вторых, разные контейнеры по-разному выполняют одинаковые операции. Лучший пример — это ArrayList и LinkedList. Оба представляют собой простые последовательности, которые мо¬гут иметь идентичные интерфейсы и черты поведения. Но некоторые операции значительно отличаются по времени исполнения. Скажем, время выборки про¬извольного элемента в ArrayList всегда остается неизменным вне зависимости от того, какой именно элемент выбирается. Однако в LinkedList невыгодно рабо¬тать с произвольным доступом — чем дальше по списку находится элемент, тем большую задержку вызывает его поиск. С другой стороны, если потребуется вставить элемент в середину списка, LinkedList сделает это быстрее ArrayList. Эти и другие операции имеют разную эффективность, зависящую от внутренней структуры контейнера. На стадии планирования программы вы можете вы¬брать список LinkedList, а потом, в процессе оптимизации, переключиться на ArrayList. Благодаря абстрактному характеру интерфейса List такой переход потребует минимальных изменений в коде.

Параметризованные типы 35

Параметризованные типы

До выхода Java SE5 в контейнерах могли храниться только данные Object — единственного универсального типа Java. Однокорневая иерархия означает, что любой объект может рассматриваться как Object, поэтому контейнер с элемен¬тами Object подойдет для хранения любых объектов1.

При работе с таким контейнером вы просто помещаете в него ссылки на объ¬екты, а позднее извлекаете их. Но если контейнер способен хранить только Object, то при помещении в него ссылки на другой объект происходит его преоб¬разование к Object, то есть утрата его «индивидуальности». При выборке вы полу¬чаете ссылку на Object, а не ссылку на тип, который был помещен в контейнер. Как же преобразовать ее к конкретному типу объекта, помещенного в контейнер?

Задача решается тем же преобразованием типов, но на этот раз тип изменя¬ется не по восходящей (от частного к общему), а по нисходящей (от общего к частному) линии. Данный способ называется нисходящим преобразованием. В случае восходящего преобразования известно, что окружность есть фигура, поэтому преобразование заведомо безопасно, но при обратном преобразовании невозможно заранее сказать, представляет ли экземпляр Object объект Circle или Shape, поэтому нисходящее преобразование безопасно только в том случае, если вам точно известен тип объекта.

Впрочем, опасность не столь уж велика — при нисходящем преобразовании к неверному типу произойдет ошибка времени исполнения, называемая исклю¬чением (см. далее). Но при извлечении ссылок на объекты из контейнера необ¬ходимо каким-то образом запоминать фактический тип их объектов, чтобы вы¬полнить верное преобразование.

Нисходящее преобразование и проверки типа во время исполнения требуют дополнительного времени и лишних усилий от программиста. А может быть, можно каким-то образом создать контейнер, знающий тип хранимых объектов, и таким образом устраняющий необходимость преобразования типов и потен¬циальные ошибки? параметризованные типы представляют собой классы, ко¬торые компилятор может автоматически адаптировать для работы с определен¬ными типами. Например, компилятор может настроить параметризованный контейнер на хранение и извлечение только фигур (Shape).

Одним из важнейших изменений Java SE5 является поддержка параметри¬зованных типов (generics). Параметризованные типы легко узнать по угловым скобкам, в которые заключаются имена типов-параметров; например, контейнер ArrayList, предназначенный для хранения объектов Shape, создается следующим образом:

ArrayList<Shape> shapes = new ArrayList<Shape>(),

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

Создание, использование объектов и время их жизни

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

Допустим, например, что вы разрабатываете систему для управления движе¬нием авиатранспорта. (Эта же модель пригодна и для управления движением тары на складе, или для системы видеопроката, или в питомнике для бродячих животных.) Сначала все кажется просто: создается контейнер для самолетов, затем строится новый самолет, который помещается в контейнер определенной зоны регулировки воздушного движения. Что касается освобождения ресурсов, соответствующий объект просто уничтожается при выходе самолета из зоны слежения.

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

Теперь задача усложняется: как узнать, когда нужно удалять объекты? Даже если вы закончили работу с объектом, возможно, с ним продолжает взаимодействовать другая система. Этот же вопрос возникает и в ряде других ситуаций, и в программных системах, где необходимо явно удалять объекты после завершения работы с ними (например, в С++), он становится достаточ¬но сложным.

Где хранятся данные объекта и как определяется время его жизни? В С++ на первое место ставится эффективность, поэтому программисту предоставля¬ется выбор. Для достижения максимальной скорости исполнения место хране¬ния и время жизни могут определяться во время написания программы. В этом случае объекты помещаются в стек (такие переменные называются автомати¬ческими) или в область статического хранилища. Таким образом, основным фактором является скорость создания и уничтожения объектов, и это может быть неоценимо в некоторых ситуациях. Однако при этом приходится жертво¬вать гибкостью, так как количество объектов, время их жизни и типы должны быть точно известны на стадии разработки программы. При решении задач более широкого профиля — разработки систем автоматизированного проектирования

Создание, использование объектов и время их жизни 37

(CAD), складского учета или управления воздушным движением — этот подход может оказаться чересчур ограниченным.

Второй путь — динамическое создание объектов в области памяти, называе¬мой «кучей» (heap). В таком случае количество объектов, их точные типы и время жизни остаются неизвестными до момента запуска программы. Все это определяется «на ходу» во время работы программы. Если вам понадобится но¬вый объект, вы просто создаете его в «куче» тогда, когда потребуется. Так как управление кучей осуществляется динамически, во время исполнения програм¬мы на выделение памяти из кучи требуется гораздо больше времени, чем при выделении памяти в стеке. (Для выделения памяти в стеке достаточно всего од¬ной машинной инструкции, сдвигающей указатель стека вниз, а освобождение осуществляется перемещением этого указателя вверх. Время, требуемое на вы¬деление памяти в куче, зависит от структуры хранилища.)

При использовании динамического подхода подразумевается, что объекты большие и сложные, таким образом, дополнительные затраты времени на выде¬ление и освобождение памяти не окажут заметного влияния на процесс их соз¬дания. Потом, дополнительная гибкость очень важна для решения основных за¬дач программирования.

В Java используется исключительно второй подход . Каждый раз при созда¬нии объекта используется ключевое слово new для построения динамического экземпляра.

Впрочем, есть и другой фактор, а именно время жизни объекта. В языках, поддерживающих создание объектов в стеке, компилятор определяет, как долго используется объект, и может автоматически уничтожить его. Однако при соз¬дании объекта в куче компилятор не имеет представления о сроках жизни объ¬екта. В языках, подобных С++, уничтожение объекта должно быть явно оформ¬лено в программе; если этого не сделать, возникает утечка памяти (обычная проблема в программах С++). В Java существует механизм, называемый сборкой мусора; он автоматически определяет, когда объект перестает использоваться, и уничтожает его. Сборщик мусора очень удобен, потому что он избавляет про¬граммиста от лишних хлопот. Что еще важнее, сборщик мусора дает гораздо большую уверенность в том, что в вашу программу не закралась коварная про¬блема утечки памяти (которая «поставила на колени» не один проект на языке С++).

В Java сборщик мусора спроектирован так, чтобы он мог самостоятельно ре¬шать проблему освобождения памяти (это не касается других аспектов завер¬шения жизни объекта). Сборщик мусора «знает», когда объект перестает ис¬пользоваться, и применяет свои знания для автоматического освобождения памяти. Благодаря этому факту (вместе с тем, что все объекты наследуются от единого базового класса Object и создаются только в куче) программирова¬ние на Java гораздо проще, чем программирование на С++. Разработчику при¬ходится принимать меньше решений и преодолевать меньше препятствий.

Обработка исключений: борьба с ошибками

С первых дней существования языков программирования обработка ошибок была одним из самых каверзных вопросов. Разработать хороший механизм об¬работки ошибок очень трудно, поэтому многие языки попросту игнорируют эту проблему, оставляя ее разработчикам программных библиотек. Последние пре¬доставляют половинчатые решения, которые работают во многих ситуациях, но которые часто можно попросту обойти (как правило, просто не обращая на них внимания). Главная проблема многих механизмов обработки исключений состоит в том, что они полагаются на добросовестное соблюдение программи¬стом правил, выполнение которых не обеспечивается языком. Если програм¬мист проявит невнимательность — а это часто происходит при спешке в рабо¬те — он может легко забыть об этих механизмах.

Механизм обработки исключений встраивает обработку ошибок прямо в язык программирования или даже в операционную систему. Исключе¬ние представляет собой объект, генерируемый на месте возникновении ошибки, который затем может быть «перехвачен» подходящим обработчиком исключе¬ний, предназначенным для ошибок определенного типа. Обработка исключе¬ний словно определяет параллельный путь выполнения программы, вступаю¬щий в силу, когда что-то идет не по плану. И так как она определяет отдельный путь исполнения, код обработки ошибок не смешивается с обычным кодом. Это упрощает написание программ, поскольку вам не приходится постоянно прове¬рять возможные ошибки. Вдобавок исключение не похоже на числовой код ошибки, возвращаемый методом, или на флаг, устанавливаемый в случае про¬блемной ситуации, — последние могут быть проигнорированы. Исключение же нельзя пропустить, оно обязательно будет где-то обработано. Наконец, исклю¬чения дают возможность восстановить нормальную работу программы после неверной операции. Вместо того, чтобы просто завершить программу, можно исправить ситуацию и продолжить ее выполнение; тем самым повышается на¬дежность программы.

Механизм обработки исключений Java выделяется среди остальных, потому что он был встроен в язык с самого начала, и разработчик обязан его использо¬вать. Если он не напишет кода для подобаюгцей обработки исключений, компи¬лятор выдаст ошибку. Подобный последовательный подход иногда заметно уп¬рощает обработку ошибок.

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

Параллельное выполнение

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

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

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

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

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

Поддержка параллельного выполнения встроена в язык Java, а с выходом Java SE5 к ней добавилась значительная поддержка на уровне библиотек.

Java и Интернет

Если Java представляет собой очередной язык программирования, возникает вопрос: чем же он так важен и почему он преподносится как революционный шаг в разработке программ? С точки зрения традиционных задач программиро¬вания ответ очевиден не сразу. Хотя язык Java пригодится и при построении автономных приложений, самым важным его применением было и остается программирование для сети World Wide Web.

Что такое Веб?

На первый взгляд Веб выглядит довольно загадочно из-за обилия новомод¬ных терминов вроде «серфинга», «присутствия» и «домашних страниц». Чтобы понять, что же это такое, полезно представить себе картину в целом — но сначала необходимо разобраться во взаимодействии клиент/серверных систем, которые представляют собой одну из самых сложных задач компьютерных вычислений.

Вычисления «клиент/сервер»

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

Таким образом, основная концепция клиент/серверных вычислений не так уж сложна. Проблемы возникают из-за того, что получить доступ к серверу пы¬таются сразу несколько клиентов одновременно. Обычно для решения привле¬кается система управления базой данных, и разработчик пытается «оптимизи¬ровать» структуру данных, распределяя их по таблицам. Дополнительно система часто дает возможность клиенту добавлять новую информацию на сер¬вер. А это значит, что новая информация клиента должна быть защищена от по¬тери во время сохранения в базе данных, а также от возможности ее перезаписи данными другого клиента. (Это называется обработкой транзакций.) При изме¬нении клиентского программного обеспечения необходимо не только скомпи¬лировать и протестировать его, но и установить на клиентских машинах, что может обойтись гораздо дороже, чем можно представить. Особенно сложно ор¬ганизовать поддержку множества различных операционных систем и компью¬терных архитектур. Наконец, необходимо учитывать важнейший фактор произ¬водительности: к серверу одновременно могут поступать сотни запросов, и малейшая задержка грозит серьезными последствиями. Для уменьшения за¬держки программисты стараются распределить вычисления, зачастую даже проводя их на клиентской машине, а иногда и переводя на дополнительные сер¬верные машины, используя так называемое связующее программное обеспечение (middleware). (Программы-посредники также упрощают сопровождение про¬грамм.)

Простая идея распространения информации между людьми имеет столько уровней сложности в своей реализации, что в целом ее решение кажется недос¬тижимым. И все-таки она жизненно необходима: примерно половина всех задач программирования основана именно на ней. Она задействована в решении раз¬нообразных проблем: от обслуживания заказов и операций по кредитным кар¬точкам до распространения всевозможных данных — научных, правительствен¬ных, котировок акций... список можно продолжать до бесконечности. В про¬шлом для каждой новой задачи приходилось создавать отдельное решение. Эти решения непросто создавать, еще труднее ими пользоваться, и пользователю приходилось изучать новый интерфейс с каждой новой программой. Задача клиент/серверных вычислений нуждается в более широком подходе.

Веб как гигантский сервер

Фактически веб представляет собой одну огромную систему «клиент/сервер». Впрочем, это еще не все: в единой сети одновременно сосуществуют все серве¬ры и клиенты. Впрочем, этот факт вас не должен интересовать, поскольку обычно вы соединяетесь и взаимодействуете только с одним сервером (даже если его приходится разыскивать по всему миру).

На первых порах использовался простой однонаправленный обмен инфор¬мацией. Вы делали запрос к серверу, он отсылал вам файл, который обрабаты¬вала для вас ваша программа просмотра (то есть клиент). Но вскоре простого получения статических страниц с сервера стало недостаточно. Пользователи хотели использовать все возможности системы «клиент/сервер», отсылать ин¬формацию от клиента к серверу, чтобы, например, просматривать базу данных сервера, добавлять новую информацию на сервер или делать заказы (что требо¬вало особых мер безопасности). Эти изменения мы постоянно наблюдаем в процессе развития веб.

Средства просмотра веб (браузеры) стали большим шагом вперед: они ввели понятие информации, которая одинаково отображается на любых типах компь¬ютеров. Впрочем, первые браузеры были все же примитивны и быстро переста¬ли соответствовать предъявляемым требованиям. Они оказались не особенно интерактивны и тормозили работу как серверов, так и Интернета в целом — при любом действии, требующем программирования, приходилось посылать информацию серверу и ждать, когда он ее обработает. Иногда приходилось ждать несколько минут только для того, чтобы узнать, что вы пропустили в за¬просе одну букву. Так как браузер представлял собой только средство просмотра, он не мог выполнить даже простейших программных задач. (С другой стороны, это гарантировало безопасность — пользователь был огражден от запуска про¬грамм, содержащих вирусы или ошибки.)

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

Программирование на стороне клиента

Изначально система взаимодействия «сервер-браузер» разрабатывалась для интерактивного содержимого, но поддержка этой интерактивности была полно¬стью возложена на сервер. Сервер генерировал статические страницы для брау¬зера клиента, который их просто обрабатывал и показывал. Стандарт HTML поддерживает простейшие средства ввода данных: текстовые поля, переключа¬тели, флажки, списки и раскрывающиеся списки, вместе с кнопками, которые могут выполнить только два действия: сброс данных формы и ее отправку сер¬веру. Отправленная информация обрабатывается интерфейсом CGI (Common

Gateway Interface), поддерживаемым всеми веб-серверами. Текст запроса ука¬зывает CGI, как именно следует поступить с данными. Чаще всего по запросу запускается программа из каталога cgi-bin на сервере. (В строке с адресом стра¬ницы в браузере, после отправки данных формы, иногда можно разглядеть в ме¬шанине символов подстроку cgi-bin.) Такие программы можно написать почти на всех языках. Обычно используется Perl, так как он ориентирован на обработ¬ку текста, а также является интерпретируемым языком, соответственно, может быть использован на любом сервере, независимо от типа процессора или опера¬ционной системы. Впрочем, язык Python (мой любимый язык — зайдите на www.Python.org) постепенно отвоевывает у него «территорию» благодаря своей мощи и простоте.

Многие мощные веб-серверы сегодня функционируют целиком на основе CGI; в принципе, эта технология позволяет решать почти любые задачи. Одна¬ко веб-серверы, построенные на CGI-программах, тяжело обслуживать, и на них существуют проблемы со скоростью отклика. Время отклика CGI-программы зависит от количества посылаемой информации, а также от загрузки сервера и сети. (Из-за всего упомянутого запуск CGI-программы может занять продол¬жительное время). Первые проектировщики веб не предвидели, как быстро истощатся ресурсы системы при ее использовании в различных приложени¬ях. Например, выводить графики в реальном времени в ней почти невозмож¬но, так как при любом изменении ситуации необходимо построить новый GIF- файл и передать его клиенту. Без сомнения, у вас есть собственный горький опыт — например, полученный при простой посылке данных формы. Вы нажи¬маете кнопку для отправки информации; сервер запускает CGI-программу, ко¬торая обнаруживает ошибку, формирует HTML-страницу, сообщающую вам об этом, а затем отсылает эту страницу в вашу сторону; вам приходится набирать данные заново и повторять попытку. Это не только медленно, это попросту не¬элегантно.

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

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

Модули расширения

Одним из самых важнейших направлений в клиентском программировании стала разработка модулей расширения (plug-ins). Этот подход позволяет программисту добавить к браузеру новые функции, загрузив небольшую про¬грамму, которая встраивается в браузер. Фактически с этого момента браузер об¬заводится новой функциональностью. (Модуль расширения загружается только один раз.) Подключаемые модули позволили оснастить браузеры рядом быст¬рых и мощных нововведений, но написание такого модуля — совсем непростая задача, и вряд ли каждый раз при создании какого-то нового сайта вы захотите создавать расширения. Ценность модулей расширения для клиентского про¬граммирования состоит в том, что они позволяют опытному программисту до¬полнить браузер новыми возможностями, не спрашивая разрешения у его соз¬дателя. Таким образом, модули расширения предоставляют «черный ход» для интеграции новых языков программирования на стороне клиента (хотя и не все языки реализованы в таких модулях).

Языки сценариев

Разработка модулей расширения привела к появлению множества языков для написания сценариев. Используя язык сценария, вы встраиваете клиентскую программу прямо в HTML-страницу, а модуль, обрабатывающий данный язык, автоматически активизируется при ее просмотре. Языки сценария обычно до¬вольно просты для изучения; в сущности, сценарный код представляет собой текст, входящий в состав HTML-страницы, поэтому он загружается очень быстро, как часть одного запроса к серверу во время получения страницы. Расплачи¬ваться за это приходится тем, что любой в силах просмотреть (и украсть) ваш код. Впрочем, вряд ли вы будете писать что-либо заслуживающее подражания и утонченное на языках сценариев, поэтому проблема копирования кода не так уж страшна.

Языком сценариев, который поддерживается практически любым браузером без установки дополнительных модулей, является JavaScript (имеющий весьма мало общего с Java; имя было использовано в целях «урвать» кусочек успеха Java на рынке). К сожалению, исходные реализации JavaScript в разных браузе¬рах довольно сильно отличались друг от друга и даже между разными версиями одного браузера. Стандартизация JavaScript в форме ECMAScript была полез¬на, но потребовалось время, чтобы ее поддержка появилась во всех брау- зерах (вдобавок компания Microsoft активно продвигала собственный язык VBScript, отдаленно напоминавший JavaScript). В общем случае разработчику приходит¬ся ограничиваться минимумом возможностей JavaScript, чтобы код гарантиро¬ванно работал во всех браузерах. Что касается обработки ошибок и отладки кода JavaScript, то занятие это в лучшем случае непростое. Лишь недавно раз¬работчикам удалось создать действительно сложную систему, написанную на JavaScript (компания Google, служба GMail), и это потребовало высочайшего энтузиазма и опыта.

Это показывает, что языки сценариев, используемые в браузерах, были предназначены для решения круга определенных задач, в основном для созда¬ния более насыщенного и интерактивного графического пользовательского ин¬терфейса (GUI). Однако язык сценариев может быть использован для решения 80 % задач клиентского программирования. Ваша задача может как раз входить в эти 80 %. Поскольку языки сценариев позволяют легко и быстро создавать программный код, вам стоит сначала рассмотреть именно такой язык, перед тем как переходить к более сложным технологическим решениям вроде Java.

Java

Если языки сценариев берут на себя 80 % задач клиентского программирова¬ния, кому же тогда «по зубам» остальные 20 %? Для них наиболее популяр¬ным решением сегодня является Java. Это не только мощный язык програм¬мирования, разработанный с учетом вопросов безопасности, платформен¬ной совместимости и интернационализации, но также постоянно совершен¬ствуемый инструмент, дополняемый новыми возможностями и библиотека¬ми, которые элегантно вписываются в решение традиционно сложных задач программирования: многозадачности, доступа к базам данных, сетевого про¬граммирования и распределенных вычислений. Клиентское программирование на Java сводится к разработке апплетов, а также к использованию пакета Java Web Start.

Апплет — мини-программа, которая может исполняться только внутри брау¬зера. Апплеты автоматически загружаются в составе веб-страницы (так же, как загружается, например, графика). Когда апплет активизируется, он выполняет программу. Это одно из преимуществ апплета — он позволяет автоматически распространять программы для клиентов с сервера именно тогда, когда пользо¬вателю понадобятся эти программы, и не раньше. Пользователь получает са¬мую свежую версию клиентской программы, без всяких проблем и трудностей, связанных с переустановкой. В соответствии с идеологией Java, программист создает только одну программу, которая автоматически работает на всех компь¬ютерах, где имеются браузеры со встроенным интерпретатором Java. (Это вер¬но практически для всех компьютеров.) Так как Java является полноценным языком программирования, как можно большая часть работы должна выпол¬няться на стороне клиента перед обращением к серверу (или после него). На¬пример, вам не понадобится пересылать запрос по Интернету, чтобы узнать, что в полученных данных или каких-то параметрах была ошибка, а компьютер кли¬ента сможет быстро начертить какой-либо график, не ожидая, пока это сделает сервер и отошлет обратно файл с изображением. Такая схема не только обеспе¬чивает мгновенный выигрыш в скорости и отзывчивости, но также снижает за¬грузку основного сетевого транспорта и серверов, предотвращая замедление ра¬боты с Интернетом в целом.

Альтернативы

Честно говоря, апплеты Java не оправдали начальных восторгов. При первом появлении Java все относились к апплетам с большим энтузиазмом, потому что они делали возможным серьезное программирование на стороне клиента, повы¬шали скорость отклика и снижали загрузку канала для Интернет-приложений. Апплетам предрекали большое будущее.

И действительно, в веб можно встретить ряд очень интересных апплетов. И все же массовый переход на апплеты так и не состоялся. Вероятно, главная проблема заключалась в том, что загрузка 10-мегабайтного пакета для установки среды Java Runtime Environment (JRE) слишком пугала рядового пользователя. Тот факт, что компания Microsoft не стала включать JRE в поставку Internet Explorer, окончательно решил судьбу апплетов. Как бы то ни было, апплеты Java так и не получили широкого применения.

• Впрочем, апплеты и приложения Java Web Start в некоторых ситуациях при¬носят большую пользу. Если конфигурация компьютеров конечных пользова¬телей находится под контролем (например, в организациях), применение этих технологий для распространения и обновления клиентских приложений впол¬не оправдано; оно экономит немало времени, труда и денег (особенно при час¬тых обновлениях).

.NET и С#

Некоторое время основным соперником Java-апплетов считались компоненты ActiveX от компании Microsoft, хотя они и требовали для своей работы нали¬чия на машине клиента Windows. Теперь Microsoft противопоставила Java пол¬ноценных конкурентов: это платформа .NET и язык программирования С#. Платформа .NET представляет собой примерно то же самое, что и виртуальная машина Java (JVM) и библиотеки Java, а язык С# имеет явное сходство с язы¬ком Java. Вне всяких сомнений, это лучшее, что создала компания Microsoft в области языков и сред программирования. Конечно, разработчики из Micro¬soft имели некоторое преимущество; они видели, что в Java удалось, а что нет, и могли отталкиваться от этих фактов, но результат получился вполне достой¬ным. Впервые с момента своего рождения у Java появился реальный соперник. Разработчикам из Sun пришлось как следует взглянуть на С#, выяснить, по ка¬ким причинам программисты могут захотеть перейти на этот язык, и прило¬жить максимум усилий для серьезного улучшения Java в Java SE5.

Выданный момент основные сомнения вызывает вопрос о том, разрешит ли Microsoft полностью переносить .NET на другие платформы. В Microsoft утвер¬ждают, что никакой проблемы в этом нет, и проект Mono (www.go-mono.com) пре¬доставляет частичную реализацию .NET для Linux. Впрочем, раз реализация эта неполная, то, пока Microsoft не решит выкинуть из нее какую-либо часть, делать ставку на .NET как на межплатформенную технологию еще рано.

Интернет и интрасеть

Веб предоставляет решение наиболее общего характера для клиент/серверных задач, так что имеет смысл использовать ту же технологию для решения задач в частных случаях; в особенности это касается классического клиент/серверно- го взаимодействия внутри компании. При традиционном подходе «клиент/сер- вер» возникают проблемы с различиями в типах клиентских компьютеров, к ним добавляется трудность установки новых программ для клиентов; обе про¬блемы решаются браузерами и программированием на стороне клиента. Когда технология веб используется для формирования информационной сети внутри компании, такая сеть называется интрасетью. Интрасети предоставля¬ют гораздо большую безопасность в сравнении с Интернетом, потому что вы можете физически контролировать доступ к серверам вашей компании. Что ка¬сается обучения, человеку, понимающему концепцию браузера, гораздо легче разобраться в разных страницах и апплетах, так что время освоения новых сис¬тем сокращается.

Проблема безопасности подводит нас к одному из направлений, которое ав¬томатически возникает в клиентском программировании. Если ваша программа исполняется в Интернете, то вы не знаете, на какой платформе ей предстоит ра¬ботать. Приходится проявлять особую осторожность, чтобы избежать распро¬странения некорректного кода. Здесь нужны межплатформенные и безопасные решения, наподобие Java или языка сценариев.

В интрасетях действуют другие ограничения. Довольно часто все машины сети работают на платформе Intel/Windows. В интрасети вы отвечаете за каче¬ство своего кода и можете устранять ошибки по мере их обнаружения. Вдоба¬вок, у вас уже может накопиться коллекция решений, которыепроверены на прочность в более традиционных клиент/серверных системах, в то время как новые программы придется вручную устанавливать на машину клиента при ка¬ждом обновлении. Время, затрачиваемое на обновления, является самым вес¬ким доводом в пользу браузерных технологий, где обновления осуществляются невидимо и автоматически (то же позволяет сделать Java Web Start). Если вы участвуете в обслуживании интрасети, благоразумнее всего использовать тот путь, который позволит привлечь уже имеющиеся наработки, не переписывая программы на новых языках.

Сталкиваясь с объемом задач клиентского программирования, способным поставить в тупик любого проектировщика, лучше всего оценить их с позиций соотношения «затраты/прибыли». Рассмотрите ограничения вашей задачи и попробуйте представить кратчайший способ ее решения. Так как клиентское программирование все же остается программированием, всегда актуальны тех¬нологии разработки, обещающие наиболее быстрое решение. Такая активная позиция даст вам возможность подготовиться к неизбежным проблемам разра¬ботки программ.

Программирование на стороне сервера

Наше обсуждение обошло стороной тему серверного программирования, кото¬рое, как считают многие, является самой сильной стороной Java. Что происхо¬дит, когда вы посылаете запрос серверу? Чаще всего запрос сводится к просто¬му требованию «отправьте мне этот файл». Браузер затем обрабатывает файл подходящим образом: как HTML-страницу, как изображение, как Java-апплет, как сценарий и т. п.

Более сложный запрос к серверу обычно связан с обращением к базе дан¬ных. В самом распространном случае делается запрос на сложный поиск в базе данных, результаты которого сервер затем преобразует в HTML-страницу и посылает вам. (Конечно, если клиент способен производить какие-то дейст¬вия с помощью Java или языка сценариев, данные могут быть обработаны и у него, что будет быстрее и снизит загрузку сервера.) А может быть, вам пона¬добится зарегистрироваться в базе данных при присоединении к какой-то группе, или оформить заказ, что потребует изменений в базе данных. Подобные запро¬сы должны обрабатываться неким кодом на сервере; в целом это и называется серверным программированием. Традиционно программирование на сервере осуществлялось на Perl, Python, С++ или другом языке, позволяющем созда¬вать программы CGI, но появляются и более интересные варианты. К их числу относятся и основанные на Java веб-серверы, позволяющие заниматься сервер¬ным программированием на Java с помощью так называемых сервлетов. Серв- леты и их детища, JSPs, составляют две основные причины для перехода ком¬паний по разработке веб-содержимого на Java, в главном из-за того, что они ре¬шают проблемы несовместимости различных браузеров.

Несмотря на все разговоры о Java как языке Интернет-программирования, Java в действительности является полноценным языком программирования, способным решать практически все задачи, решаемые на других языках. Пре¬имущества Java не ограничиваются хорошей переносимостью: это и пригод¬ность к решению задач программирования, и устойчивость к ошибкам, и боль¬шая стандартная библиотека, и многочисленные разработки сторонних фирм — как существующие, так и постоянно появляющиеся.

Резюме

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

Так как ООП добавляет много новых понятий к тем, что уже имеются в про¬цедурных языках, естественно будет предположить, что код Java будет гораздо сложнее, чем аналогичный метод на процедурном языке. Но здесь вас ждет при¬ятный сюрприз: хорошо написанную программу на Java обычно гораздо легче понять, чем ее процедурный аналог. Все, что вы видите, — это определения объ¬ектов, представляющих понятия пространства решения (а не понятия компью¬терной реализации), и сообщения, посылаемые этим объектам, которые пред¬ставляют действия в этом пространстве. Одно из преимуществ ООП как раз и состоит в том, что хорошо спроектированную программу можно понять, про¬сто проглядывая исходные тексты. К тому же обычно приходится писать гораз¬до меньше кода, поскольку многие задачи с легкостью решаются уже сущест¬вующими библиотеками классов.

Объектно-ориентированное программирование и язык Java подходят не для всех. Очень важно сначала выяснить свои потребности, чтобы решить, удовле¬творит ли вас переход на Java или лучше остановить свой выбор на другой системе программирования (в том числе и на той, что вы сейчас используете). Если вы знае¬те, что в обозримом будущем вы столкнетесь с весьма специфическими потребно¬стями или в вашей работе будут действовать ограничения, с которыми Java не справляется, лучше рассмотреть другие возможности (в особенности я рекомендую присмотреться к языку Python, www.Python.org). Выбирая Java, необходимо пони¬мать, какие еще доступны варианты и почему вы выбрали именно этот путь.

Все является объектом

Если бы мы говорили на другом языке, то и мир воспринимали бы по-другому.

Людвиг Витгенштейн (1889-1951)

Хотя язык Java основан на С++, он является более «чистокровным» объект- но-ориентированным языком.

Как С++, так и Java относятся к семейству смешанных языков, но для созда¬телей Java эта неоднородность была не так важна, если сравнивать с С++. Сме¬шанный язык позволяет использовать несколько стилей программирования; причиной смешанной природы С++ стало желание сохранить совместимость с языком С. Так как язык С++ является надстройкой языка С, он включает в себя много нежелательных характеристик своего предшественника, что при¬водит к излишнему усложнению некоторых аспектов этого языка.

Язык программирования Java подразумевает, что вы занимаетесь только объектно-ориентированным программированием. А это значит, что прежде, чем начать с ним работать, нужно «переключиться» на понятия объектно-ориенти- рованного мира (если вы уже этого не сделали). Выгода от этого начального усилия — возможность программировать на языке, который по простоте изуче¬ния и использования превосходит все остальные языки ООП. В этой главе мы рассмотрим основные компоненты Java-программы и узнаем, что в Java (почти) все является объектом.

Для работы с объектами используются ссылки

Каждый язык программирования имеет свои средства манипуляции данными. Иногда программисту приходится быть постоянно в курсе, какая именно мани¬пуляция производится в программе. Вы работаете с самим объектом или же с каким-то видом его косвенного представления (указатель в С или в С++), требующим особого синтаксиса?

Все эти различия упрощены в Java. Вы обращаетесь со всем как с объектом, и поэтому повсюду используется единый последовательный синтаксис. Хотя

вы обращаетесь со всем как с объектом, идентификатор, которым вы манипу¬лируете, на самом деле представляет собой ссылку на объект . Представьте себе телевизор (объект) с пультом дистанционного управления (ссылка). Во время владения этой ссылкой у вас имеется связь с телевизором, но при переключе¬нии канала или уменьшении громкости вы распоряжаетесь ссылкой, которая, в свою очередь, манипулирует объектом. А если вам захочется перейти в другое место комнаты, все еще управляя телевизором, вы берете с собой «ссылку», а не сам телевизор.

Также пульт может существовать сам по себе, без телевизора. Таким обра¬зом, сам факт наличия ссылки еще не означает наличия присоединенного к ней объекта. Например, для хранения слова или предложения создается ссылка String:

String s;

Однако здесь определяется только ссылка, но не объект. Если вы решите по¬слать сообщение s, произойдет ошибка, потому что ссылка s на самом деле ни к чему не присоединена (телевизора нет). Значит, безопаснее всегда инициа¬лизировать ссылку при ее создании:

String s = "asdf";

В данном примере используется специальная возможность Java: инициали¬зация строк текстом в кавычках. Обычно вы будете использовать более общий способ инициализации объектов.

Все объекты должны создаваться явно

Когда вы определяете ссылку, желательно присоединить ее к новому объекту. В основном это делается при помощи ключевого слова new. Фактически оно оз¬начает: «Создайте мне новый объект». В предыдущем примере можно написать:

String s = new StringC"asdf"):

Это не только значит «предоставьте мне новый объект String», но также ука¬зывает, как создать строку посредством передачи начального набора символов.

Конечно, кроме String, в Java имеется множество готовых типов. Важнее то, что вы можете создавать свои собственные типы. Вообще говоря, именно созда¬ние новых типов станет вашим основным занятием при программировании на Java, и именно его мы будем рассматривать в книге.

Где хранятся данные

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

1. Регистры. Это самое быстрое хранилище, потому что данные хранятся прямо внутри процессора. Однако количество регистров жестко ограни¬чено, поэтому регистры используются компилятором по мере необходи¬мости. У вас нет прямого доступа к регистрам, вы не сможете найти и ма¬лейших следов их поддержки в языке. (С другой стороны, языки С и С++ позволяют порекомендовать компилятору хранить данные в регистрах.)

2. Стек. Эта область хранения данных находится в общей оперативной па¬мяти (RAM), но процессор предоставляет прямой доступ к ней с исполь¬зованием указателя стека. Указатель стека перемещается вниз для выде¬ления памяти или вверх для ее освобождения. Это чрезвычайно быстрый и эффективный способ размещения данных, по скорости уступающий только регистрам. Во время обработки программы компилятор Java дол¬жен знать жизненный цикл данных, размещаемых в стеке. Это ограниче¬ние уменьшает гибкость ваших программ, поэтому, хотя некоторые дан¬ные Java хранятся в стеке (особенно ссылки на объекты), сами объекты Java не помещаются в стек.

3. Куча. Пул памяти общего назначения (находится также в RAM), в кото¬ром размещаются все объекты Java. Преимущество кучи состоит в том, что компилятору не обязательно знать, как долго просуществуют находя¬щиеся там объекты. Таким образом, работа с кучей дает значительное преимущество в гибкости. Когда вам нужно создать объект, вы пишете код с использованием new, и память выделяется из кучи во время выпол¬нения программы. Конечно, за гибкость приходится расплачиваться: вы¬деление памяти из кучи занимает больше времени, чем в стеке (даже если бы вы могли явно создавать объекты в стеке, как в С++).

4. Постоянная память. Значения констант часто встраиваются прямо в код программы, так как они неизменны. Иногда такие данные могут разме¬щаться в постоянной памяти (ROM), если речь идет о «встроенных» сис¬темах.

5. Не-оперативная память. Если данные располагаются вне программы, они могут существовать и тогда, когда она не выполняется. Два основных примера: потоковые объекты (streamed objects), в которых объекты пред¬ставлены в виде потока байтов, обычно используются для посылки на другие машины, и долгоживущие (persistent) объекты, которые запомина¬ются на диске и сохраняют свое состояние даже после окончания работы программы. Особенностью этих видов хранения данных является воз¬можность перевода объектов в нечто, что может быть сохранено на дру¬гом носителе информации, а потом восстановлено в виде обычного объ¬екта, хранящегося в оперативной памяти. В Java организована поддержка легковесного (lightweight) сохранения состояния, а такие механизмы, как JDBC и Hibernate, предоставляют более совершенную поддержку сохра¬нения и выборки информации об объектах из баз данных.

Особый случай: примитивные типы

Одна из групп типов, часто применяемых при программировании, требует осо¬бого обращения. Их можно назвать «примитивными» типами (табл. 2.1). При¬чина для особого обращения состоит в том, что создание объекта с помощью new — особенно маленькой простой переменной — недостаточно эффективно, так как new помещает объекты в кучу. В таких случаях Java следует примеру языков С и С++. То есть вместо создания переменной с помощью new создается «автоматическая» переменная, не являющаяся ссылкой. Переменная напрямую хранит значение и располагается в стеке, так что операции с ней гораздо произ¬водительнее.

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

Таблица 2.1. Примитивные типы

Примитивный тип Размер, бит Минимум Максимум Тип упаковки

boolean (логические значения) — — — Boolean

char (символьные значения) 16 . Unicode 0 Unicode 216- ■1 Character

byte (байт) 8 -128 +127 Byte

short (короткое целое) 16 -215 +215-1 Short

int (целое) 32 -231 +231-1 Integer

long (длинное целое) 64 -263 +2б3-1 Long

float (число.с плавающей запятой) 32 IEEE754 IEEE754 Float

double (число с повышенной 64 IEEE754 IEEE754 Double

точностью)    

Void («пустое» значение) — — — Void

Все числовые значения являются знаковыми, так что не ищите слова un¬signed.

Размер типа boolean явно не определяется; указывается лишь то, что этот тип может принимать значения true и false.

«Классы-обертки» позволяют создать в куче не-примитивный объект для представления примитивного типа. Например:

char с = 'х*,

Character ch = new Character(c),

Также можно использовать такой синтаксис:

Character ch = new CharacterC'x');

Механизм автоматической упаковки Java SE5 автоматически преобразует примитивный тип в объектную «обертку»:

Character ch = 'х'; и обратно:

char с = ch;

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

Числа повышенной точности

В Java существует два класса для проведения арифметических операций повы¬шенной точности: Biglnteger и BigDecimal. Хотя эти классы примерно подходят под определение «классов-оберток», ни один из них не имеет аналога среди примитивных типов.

Оба класса содержат методы, производящие операции, аналогичные тем, что проводятся над примитивными типами. Иначе говоря, с классами Biglnteger и BigDecimal можно делать то же, что с int или float, просто для этого использу¬ются вызовы методов, а не встроенные операции. Также из-за использования увеличенного объема данных операции занимают больше времени. Приходится жертвовать скоростью ради точности.

Класс Biglnteger поддерживает целые числа произвольной точности. Это значит, что вы можете использовать целочисленные значения любой величины без потери данных во время операций.

Класс BigDecimal представляет числа с фиксированной запятой произволь¬ной точности; например, они могут применяться для финансовых вычислений.

За подробностями о конструкторах и методах этих классов обращайтесь к документации JDK.

Массивы в Java

Фактически все языки программирования поддерживают массивы. Использо¬вание массивов в С и С++ небезопасно, потому что массивы в этих язы¬ках представляют собой обычные блоки памяти. Если программа попытается получить доступ к массиву за пределами его блока памяти или использовать память без предварительной инициализации (типичные ошибки при програм¬мировании), последствия могут быть непредсказуемы.

Одной из основных целей Java является безопасность, поэтому многие про¬блемы, досаждавшие программистам на С и С++, не существуют в Java. Массив в Java гарантированно инициализируется, к нему невозможен доступ за преде¬лами его границ. Проверка границ массива обходится относительно дорого, как и проверка индекса во время выполнения, но предполагается, что повышение безопасности и подъем производительности стоят того (к тому же Java иногда может оптимизировать эти операции).

Объекты никогда не приходится удалять

При объявлении массива объектов на самом деле создается массив ссылок, и каждая из этих ссылок автоматически инициализируется специальным значе¬нием, представленным ключевым словом null. Оно означает, что ссылка на са¬мом деле не указывает на объект. Вам необходимо присоединять объект к каж¬дой ссылке перед тем, как ее использовать, или при попытке обращения по ссылке null во время исполнения программы произойдет ошибка. Таким об¬разом, типичные ошибки при работе с массивами в Java предотвращаются за¬благовременно.

Также можно создавать массивы простейших типов. И снова компилятор га¬рантирует инициализацию — выделенная для нового массива память заполня¬ется нулями.

Массивы будут подробнее описаны в последующих главах.

Объекты никогда не приходится удалять

В большинстве языков программирования концепция жизненного цикла пере¬менной требует относительно заметных усилий со стороны программиста. Сколько «живет» переменная? Если ее необходимо удалить, когда это следует делать? Путаница со сроками существования переменных может привести ко многим ошибкам, и этот раздел показывает, насколько Java упрощает реше¬ние затронутого вопроса, выполняя всю работу по удалению за вас.

Ограничение области действия

В большинстве процедурных языков существует понятие области действия (scope). Область действия определяет как видимость, так и срок жизни имен, определенных внутри нее. В С, С++ и Java область действия устанавливается

положением фигурных скобок { }. Например:

{

int х = 12;

// доступно только х {

int q = 96;

// доступны как х, так и q

}

// доступно ТОЛЬКО X

// q находится "за пределами видимости"

}

Переменная, определенная внутри области действия, доступна только в пре¬делах этой области.

Весь текст после символов // и до конца строки является комментарием. Отступы упрощают чтение программы на Java. Так как Java относится к языкам со свободным форматом, дополнительные пробелы, табуляция и пере¬воды строк не влияют на результирующую программу.

53

Учтите, что следующая конструкция не разрешена, хотя в С и С++ она воз¬можна:

{

int х = 12, {

int х = 96. // неверно

}

}

Компилятор объявит, что переменная х уже была определена. Таким обра¬зом, возможность языков С и С++ «прятать» переменные во внешней области действия не поддерживается. Создатели Java посчитали, что она приводит к из¬лишнему усложнению программ.

Область действия объектов

Объекты Java имеют другое время жизни в сравнении с примитивами. Объект, созданный оператором Java new, будет доступен вплоть до конца области дейст¬вия. Если вы напишете:

{

String s = new Stnng("строка"); } // конец области действия

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

Благодаря тому, что объекты, созданные new, существуют ровно столько, сколько вам нужно, в Java исчезает целый пласт проблем, присущих С++. В С++ приходится не только следить за тем, чтобы объекты продолжали суще¬ствовать на протяжении своего жизненного цикла, но и удалять объекты после завершения работы с ними.

Возникает интересный вопрос. Если в Java объекты остаются в памяти, что же мешает им постепенно занять всю память и остановить выполнение про¬граммы? Именно это произошло бы в данном случае в С++. Однако в Java су¬ществует сборщик мусора (garbage collector), который наблюдает за объектами, созданными оператором new, и определяет, на какие из них больше нет ссылок. Тогда он освобождает память от этих объектов, которая становится доступной для дальнейшего использования. Таким образом, вам никогда не придется «очи¬щать» память вручную. Вы просто создаете объекты, и как только надобность в них отпадет, эти объекты исчезают сами по себе. При таком подходе исчезает целый класс проблем программирования: так называемые «утечки памяти», когда программист забывает освобождать занятую память.

Создание новых типов данных

Если все является объектом, что определяет строение и поведение класса объ¬ектов? Другими словами, как устанавливается тип объекта? Наверное, для этой цели можно было бы использовать ключевое слово type («тип»); это было бы

Создание новых типов данных

вполне разумно. Впрочем, с давних времен повелось, что большинство объект¬но-ориентированных языков использовали ключевое слово class в смысле «Я собираюсь описать новый тип объектов». За ключевым словом class следует имя нового типа. Например:

class ATypeName { /* Тело класса */ }

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

ATypeName а = new ATypeNameO;

Впрочем, объекту нельзя «приказать» что-то сделать (то есть послать ему не¬обходимые сообщения) до тех пор, пока для него не будут определены методы.

Поля и методы

При определении класса (строго говоря, вся ваша работа на Java сводится к оп¬ределению классов, созданию объектов этих классов и посылке сообщений этим объектам) в него можно включить две разновидности элементов: поля (fields) (иногда называемые переменными класса) и методы (methods) (еще на¬зываемые функциями класса). Поле представляет собой объект любого типа, с которым можно работать по ссылке, или объект примитивного типа. Если ис¬пользуется ссылка, ее необходимо инициализировать, чтобы связать с реаль¬ным объектом (ключевым словом new, как было показано ранее).

Каждый объект использует собственный блок памяти для своих полей дан¬ных; совместное использование обычных полей разными объектами класса не¬возможно. Пример класса с полями:

class DataOnly { int i, double d; boolean b;

}

Такой класс ничего не делает, кроме хранения данных, но вы можете соз¬дать объект этого класса:

DataOnly data = new DataOnlyO;

Полям класса можно присваивать значения, но для начала необходимо уз¬нать, как обращаться к членам объекта. Для этого сначала указывается имя ссыл¬ки на объект, затем следует точка, а далее — имя члена, принадлежащего объекту:

ссылка.член Например:

data i = 47;

data.d =1.1,

data.b = false;

Также ваш объект может содержать другие объекты, данные которых вы хоте¬ли бы изменить. Для этого просто продолжите «цепочку из точек». Например:

55

myPlane.leftTank.capacity = 100;

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

Значения по умолчанию для полей примитивных типов

Если поле данных относится к примитивному типу, ему гарантированно при¬сваивается значение по умолчанию, даже если оно не было инициализировано явно (табл. 2.2).

Таблица 2.2. Значения по умолчанию для полей примитивных типов

Примитивный тип Значение по умолчанию

boolean false

char ЛиОООО' (null)

byte (byte)O

short (short)O

int 0

long OL

float O.Of

double O.Od

Значения по умолчанию гарантируются Java только в том случае, если пере¬менная используется как член класса. Тем самым обеспечивается обязательная инициализация элементарных типов (что не делается в С++), которая умень¬шает вероятность ошибок. Однако значение по умолчанию может быть невер¬ным или даже недопустимым для вашей программы. Переменные всегда лучше инициализировать явно.

Такая гарантия не относится к локальным переменным, которые не являются полями класса. Допустим, в определении метода встречается объявление пере¬менной

int х;

Переменной х будет присвоено случайное значение (как в С и С++); она не будет автоматически инициализирована нулем. Вы отвечаете за присвоение правильного значения перед использованием х. Если же вы забудете это сде¬лать, в Java существует очевидное преимущество в сравнении с С++: компиля¬тор выдает ошибку, в которой указано, что переменная не была инициализиро¬вана. (Многие компиляторы С++ предупреждают о таких переменных, но в Java это считается ошибкой.)

Методы, аргументы и возвращаемые значения

Во многих языках (таких как С и С++) для обозначения именованной подпро¬граммы употребляется термин функция. В Java чаще предпочитают термин метод, как бы подразумевающий «способ что-то сделать». Если вам хочется, вы можете продолжать пользоваться термином «функция». Разница только

57

Методы, аргументы и возвращаемые значения

в написании, но в дальнейшем в книге будет употребляться преимущественно термин «метод».

Методы в Java определяют сообщения, принимаемые объектом. Основные части метода — имя, аргументы, возвращаемый тип и тело. Вот примерная форма:

возвращаемыйТип ИмяМетодаС /* список аргументов */ ) { /* тело метода */

}

Возвращаемый тип — это тип объекта, «выдаваемого» методом после его вы¬зова. Список аргументов определяет типы и имена для информации, которую вы хотите передать в метод. Имя метода и его список аргументов (объединяе¬мые термином сигнатура) обеспечивают однозначную идентификацию метода.

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

имяОбъекта.имяМетода(арг1. арг2, аргЗ)

Например, представьте, что у вас есть метод f(), вызываемый без аргументов, который возвращает значение типа int. Если у вас имеется в наличии объект а, для которого может быть вызван метод f(), в вашей власти использовать сле¬дующую конструкцию:

int х = a.f(),

Тип возвращаемого значения должен быть совместим с типом х.

Такое действие вызова метода часто называется посылкой сообщения объекту. В примере выше сообщением является вызов f(), а объектом — а. Объект¬но-ориентированное программирование нередко характеризуется обобщающей формулой «посылка сообщений объектам».

Список аргументов

Список аргументов определяет, какая информация передается методу. Как лег¬ко догадаться, эта информация — как и все в Java — воплощается в форме объ¬ектов, поэтому в списке должны быть указаны как типы передаваемых объек¬тов, так и их имена. Как и в любой другой ситуации в Java, где мы вроде бы работаем с объектами, на самом деле используются ссылки2. Впрочем, тип ссыл¬ки должен соответствовать типу передаваемых данных. Если предполагается,

что аргумент является строкой (то есть объектом String), вы должны передать именно строку, или ожидайте сообщения об ошибке.

Рассмотрим метод, получающий в качестве аргумента строку (String). Сле¬дующее определение должно размещаться внутри определения класса, для ко¬торого создается метод:

int storage(String s) {

return s.lengthO * 2;

}

Метод указывает, сколько байтов потребуется для хранения данных опреде¬ленной строки. (Строки состоят из символов char, размер которых — 16 бит, или 2 байта; это сделано для поддержки набора символов Unicode.) Аргумент имеет тип String и называется s. Получив объект s, метод может работать с ним точно так же, как и с любым другим объектом (то есть посылать ему сообще¬ния). В данном случае вызывается метод length(), один из методов класса String; он возвращает количество символов в строке.

Также обратите внимание на ключевое слово return, выполняющее два дей¬ствия. Во-первых, оно означает: «выйти из метода, все сделано». Во-вторых, если метод возвращает значение, это значение указывается сразу же за коман¬дой return. В нашем случае возвращаемое значение — это результат вычисления s.length() * 2.

Метод может возвращать любой тип, но, если вы не хотите пользоваться этой возможностью, следует указать, что метод возвращает void. Ниже приведе¬но несколько примеров:

boolean flagO { return true: }

float naturalLogBaseO { return 2.718, }

void nothingO { return; }

void nothing2() {}

Когда выходным типом является void, ключевое слово return нужно лишь для завершения метода, поэтому при достижении конца метода его присутствие необязательно. Вы можете покинуть метод в любой момент, но если при этом указывается возвращаемый тип, отличный от void, то компилятор заставит вас (сообщениями об ошибках) вернуть подходящий тип независимо от того, в ка¬ком месте метода было прервано выполнение.

К этому моменту может сложиться впечатление, что программа — это просто «свалка» объектов со своими методами, которые принимают другие объекты в качестве аргументов и посылают им сообщения. По большому счету так оно и есть, но в следующей главе вы узнаете, как производить кропотливую низко¬уровневую работу с принятием решений внутри метода. В этой главе достаточ¬но рассмотрения на уровне посылки сообщений.

Создание программы на Java

Есть еще несколько вопросов, которые необходимо понять перед созданием первой программы на Java.

Создание программы на Java

Видимость имен

Проблема управления именами присуща любому языку программирования. Если имя используется в одном из модулей программы и оно случайно совпало с именем в другом модуле у другого программиста, то как отличить одно имя от другого и предотвратить их конфликт? В С это определенно является про¬блемой, потому что программа с трудом поддается контролю в условиях «моря» имен. Классы С-и- (на которых основаны классы Java) скрывают функции внутри классов, поэтому их имена не пересекаются с именами функций других классов. Однако в С++ дозволяется использование глобальных данных и гло¬бальных функций, соответственно, конфликты полностью не исключены. Для решения означенной проблемы в С++ введены пространства имен (namespa¬ces), которые используют дополнительные ключевые слова.

В языке Java для решения этой проблемы было использовано свежее реше¬ние. Для создания уникальных имен библиотек разработчики Java предлагают использовать доменное имя, записанное «наоборот», так как эти имена всегда уникальны. Мое доменное имя — MindView.net, и утилиты моей программной библиотеки могли бы называться net.mindview.utility.foibles. За перевернутым доменным именем следует перечень каталогов, разделенных точками.

В версиях Java 1.0 и 1.1 доменные суффиксы com, edu, org, net по умолчанию записывались заглавными буквами, таким образом, имя библиотеки выглядело так: NET.mindview.utility.foibles. В процессе разработки Java 2 было обнаружено, что принятый подход создает проблемы, и с тех пор имя пакета записывается строчными буквами.

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

Использование внешних компонентов

Когда вам понадобится использовать уже определенный класс в вашей про¬грамме, компилятор должен знать, как этот класс обнаружить. Конечно, класс может уже находиться в том же самом исходном файле, откуда он вызывается. В таком случае вы просто его используете — даже если определение класса сле¬дует где-то дальше в файле (В Java не существует проблемы «опережающих ссылок».)

Но что, если класс находится в каком-то внешнем файле? Казалось бы, ком¬пилятор должен запросто найти его, но здесь существует проблема. Представьте, что вам необходим класс с неким именем, для которого имеется более одного определения (вероятно, отличающихся друг от друга). Или, что еще хуже, пред¬ставьте, что вы пишете программу и при ее создании в библиотеку добавляется новый класс, конфликтующий с именем уже существующего класса.

59

Для решения проблемы вам необходимо устранить все возможные неодно¬значности. Задача решается при помощи ключевого слова import, которое гово¬рит компилятору Java, какие точно классы вам нужны. Слово import приказыва¬ет компилятору загрузить пакет (package), представляющий собой библиотеку

классов. (В других языках библиотека может состоять как из классов, так и из функций и данных, но в Java весь код принадлежит классам.)

Большую часть времени вы будете работать с компонентами из стандартных библиотек Java, поставляющихся с компилятором. Для них не нужны длинные обращенные доменные имена; вы просто записываете

import java.util ArrayList;

чтобы сказать компилятору, что вы хотите использовать класс ArrayList. Впро¬чем, пакет util содержит множество классов, и вам могут понадобиться несколь¬ко из них. Чтобы избежать последовательного перечисления классов, исполь¬зуйте подстановочный символ *:

import java util.*.

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

Ключевое слово static

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

Но есть две ситуации, в которых такой подход недостаточен. Первая — это когда некотороые данные должны храниться «в единственном числе» независи¬мо от того, сколько было создано объектов класса. Вторая — когда вам потребу¬ется метод, не привязанный ни к какому конкретному объекту класса (то есть метод, который можно вызвать даже при полном отсутствии объектов класса). Такой эффект достигается использованием ключевого слова static, делающего элемент класса статическим. Когда вы объявляете что-либо как static, это озна¬чает, что данные или метод не привязаны к определенному экземпляру этого класса. Поэтому, даже если вы никогда не создавали объектов класса, вы може¬те вызвать статический метод или получить доступ к статическим данным. С обычным объектом вам необходимо сначала создать его и использовать для вызова метода или доступа к информации, так как нестатические данные и ме¬тоды должны точно знать объект, с которым работают.

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

Чтобы сделать данные или метод статическими, просто поместите ключевое слово static перед их определением. Например, следующий код создает статиче¬ское поле класса и инициализирует его:

class StaticTest {

static int i =47;

}

Теперь, даже при создании двух объектов StaticTest, для элемента StaticTest.i выделяется единственный блок памяти. Оба объекта совместно используют одно значение i. Пример:

StaticTest stl = new StaticTestО;

StaticTest st2 = new StaticTestO;

В данном примере как stl.i, так и st2.i имеют одинаковые значения, равные 47, потому что расположены они в одном блоке памяти.

Существует два способа обратиться к статической переменной. Как было видно выше, вы можете указать ее с помощью объекта, например st2.i. Также можно обратиться к ней прямо по имени класса (для нестатических членов класса такая возможность отсутствует):

StaticTest i++,

Оператор ++ увеличивает значение на единицу (инкремент). После выполне¬ния этой команды значения stl.i и st2.i будут равны 48.

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

Та же логика верна и для статических методов. Вы можете обратиться к та¬кому методу или через объект, как это делается для всех методов, или в специ¬альном синтаксисе имяКласса.метод(). Статические методы определяются по ана¬логии со статическими данными:

class Incrementable {

static void increment ) { StaticTest i++; }

}

Нетрудно заметить, что метод increment() класса Incrementable увеличивает значение статического поля i. Метод можно вызвать стандартно, через объект:

Incrementable sf = new IncrementableO.

sf incrementO;

Или, поскольку increment() является статическим, можно вызвать его с пря¬мым указанием класса:

Incrementable.incrementC);

Применительно к полям ключевое слово static радикально меняет способ оп¬ределения данных: статические данные существуют на уровне класса, в то вре¬мя как нестатические данные существуют на уровне объектов, но в отношении изменения не столь принципиальны. Одним из важных применений static явля¬ется определение методов, которые могут вызываться без объектов. В частно¬сти, это абсолютно необходимо для метода main(), который представляет собой точку входа в приложение.

Наша первая программа на Java

Наконец, долгожданная программа. Она запускается, выводит на экран строку, а затем текущую дату, используя стандартный класс Date из стандартной биб¬лиотеки Java:

// HelloDate.java

import java util.*;

public class HelloDate {

public static void main(String[] args) {

System.out.printlnC"Привет, сегодня- "); System out println(new DateO):

}

}

В начале каждого файла с программой должны находиться директивы import, в которых перечисляются все дополнительные классы, необходимые ва¬шей программе. Обратите внимание на слово «дополнительные» — существует целая библиотека классов, присоединяющаяся автоматически к каждому файлу Java: java.lang. Запустите ваш браузер и просмотрите документацию фирмы Sun. (Если вы не загрузили документацию JDK с сайта http://java.sun. com или не получили ее иным способом, обязательно это сделайте .) Учтите, что докумен¬тация не входит в комплект JDK; ее необходимо загрузить отдельно. Взглянув на список пакетов, вы найдете в нем различные библиотеки классов, поставляе¬мые с Java. Выберите java.lang. Здесь вы увидите список всех классов, состав¬ляющих эту библиотеку. Так как пакет java.lang. автоматически включается в каждую программу на Java, эти классы всегда доступны для использования. Класса Date в нем нет, а это значит, что для его использования придется импор¬тировать другую библиотеку. Если вы не знаете, в какой библиотеке находится нужный класс, или если вам понадобится увидеть все классы, выберите Tree (дерево классов) в документации. В нем можно обнаружить любой из доступ¬ных классов Java. Функция поиска текста в браузере поможет найти класс Date. Результат поиска показывает, что класс называется java. util.Date, то есть нахо¬дится в библиотеке util, и для получения доступа к классу Date необходимо бу¬дет использовать директиву import для загрузки пакета java.util.*.

Если вы вернетесь к началу, выберете пакет java.lang, а затем класс System, то увидите, что он имеет несколько полей. При выборе поля out обнаруживается, что оно представляет собой статический объект PrintStream. Так как поле описа¬но с ключевым словом static, вам не понадобится создавать объекты. Действия, которые можно выполнять с объектом out, определяются его типом: PrintStream. Для удобства в описание этого типа включена гиперссылка, и, если щелкнуть на ней, вы обнаружите список всех доступных методов. Этих методов довольно много, и они будут позже рассмотрены в книге. Сейчас нас интересует только метод println(), вызов которого фактически означает: «вывести то, что передано методу, на консоль и перейти на новую строку». Таким образом, в любую про¬грамму на Java можно включить вызов вида System.out.println ("что-то"), чтобы вывести сообщение на консоль.

Имя класса совпадает с именем файла. Когда вы создаете отдельную про¬грамму, подобную этой, один из классов, описанных в файле, должен иметь совпадающее с ним название. (Если это условие нарушено, компилятор сооб¬щит об ошибке.) Одноименный класс должен содержать метод с именем main() со следующей сигнатурой и возвращаемым типом:

public static void main(String[] args) {

Ключевое слово public обозначает, что метод доступен для внешнего мира (об этом подробно рассказывает глава 5). Аргументом метода main() является массив строк. В данной программе массив args не используется, но компилятор Java настаивает на его присутствии, так как массив содержит параметры, пере¬данные программе в командной строке.

Строка, в которой распечатывается число, довольно интересна:

System, out. print 1 л (new DateO);

Аргумент представляет собой объект Date, который создается лишь затем, чтобы передать свое значение (автоматически преобразуемое в String) методу println(). Как только команда будет выполнена, объект Date становится ненуж¬ным, сборщик мусора заметит это, и в конце концов сам удалит его. Нам не нужно беспокоиться о его удалении самим.

Компиляция и выполнение

Чтобы скомпилировать и выполнить эту программу, а также все остальные про¬граммы в книге, вам понадобится среда разработки Java. Существует множест¬во различных сред разработок от сторонних производителей, но в этой книге мы предполагаем, что вы избрали бесплатную среду JDK Qava Developer's Kit) от фирмы Sun. Если же вы используете другие системы разработки программ , вам придется просмотреть их документацию, чтобы узнать, как компилировать и запускать программы.

Подключитесь к Интернету и посетите сайт http://java.sun.com. Там вы най¬дете информацию и необходимые ссылки, чтобы загрузить и установить JDK для вашей платформы.

Как только вы установите JDK и правильно установите пути запуска, в ре¬зультате чего система сможет найти утилиты javac и java, загрузите и распакуй¬те исходные тексты программ для этой книги (их можно загрузить с сайта www.MindView.net). Там вы обнаружите каталоги (папки) для каждой главы книги. Перейдите в папку objects и выполните команду

javac HelloDate java

Команда не должна выводить каких-либо сообщений. Если вы получили со¬общение об ошибке, значит, вы неверно установили JDK и вам нужно разо¬браться со своими проблемами.

И наоборот, если все прошло успешно, выполните следующую команду:

java HelloDate

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

Эта последовательность действий позволяет откомпилировать и выполнить любую программу-пример из этой книги. Однако также вы увидите, что каждая папка содержит файл build.xml с командами для инструмента ant по автоматиче¬ской сборке файлов для данной главы. После установки ant с сайта http://jakarta. apache.org/ant можно будет просто набрать команду ant в командной строке, чтобы скомпилировать и запустить программу из любого примера. Если ant на вашем компьютере еще не установлен, команды javac и java придется вводить вручную.

Комментарии и встроенная документация

В Java приняты два вида комментариев. Первый — традиционные комментарии в стиле С, также унаследованные языком С++. Такие комментарии начинаются с комбинации /* и распространяются иногда на множество строк, после чего за¬канчиваются символами */. Заметьте, что многие программисты начинают каж¬дую новую строку таких комментариев символом *, соответственно, часто мож¬но увидеть следующее:

/*Это комментарий,

* распространяющийся на

* несколько строк */

Впрочем, все символы между /* и */ игнорируются, и с таким же успехом можно использовать запись

/* Это комментарий, распространяющийся на несколько строк */

Второй вид комментария пришел из языка С++. Однострочный коммента¬рий начинается с комбинации // и продолжается до конца строки. Такой стиль очень удобен и прост, поэтому широко используется на практике. Вам не при¬ходится искать на клавиатуре сначала символ /, а затем * (вместо этого вы два¬жды нажимаете одну и ту же клавишу), и не нужно закрывать комментарий. Поэтому часто можно увидеть такие примеры:

// это комментарий в одну строку

Документация в комментариях

Пожалуй, основные проблемы с документированием кода связаны с его сопро¬вождением. Если код и его документация существуют раздельно, корректиро¬вать описание программы при каждом ее изменении становится задачей не из лег¬ких. Решение выглядит очень просто: совместить код и документацию. Проще всего объединить их в одном файле. Но для полноты картины понадобится спе¬циальный синтаксис комментариев, чтобы помечать документацию, и инстру¬мент, который извлекал бы эти комментарии и оформлял их в подходящем виде. Именно это было сделано в Java.

Инструмент для извлечения комментариев называется javadoc, он является частью пакета JDK. Некоторые возможности компилятора Java используются в нем для поиска пометок в комментариях, включенных в ваши программы. Он не только извлекает помеченную информацию, но также узнает имя класса или метода, к которому относится данный фрагмент документации. Таким образом, с минимумом затраченных усилий можно создать вполне приличную сопрово¬дительную документацию для вашей программы.

Результатом работы программы javadoc является HTML-файл, который можно просмотреть в браузере. Таким образом, утилита javadoc позволяет соз¬давать и поддерживать единый файл с исходным текстом и автоматически строить полезную документацию. В результае получается простой и практич¬ный стандарт по созданию документации, поэтому мы можем ожидать (и даже требовать) наличия документации для всех библиотек Java.

Вдобавок, вы можете дополнить javadoc своими собственными расширениями, называемыми доклетами (doclets), в которых можно проводить специальные операции над обрабатываемыми данными (например, выводить их в другом формате).

Далее следует лишь краткое введение и обзор основных возможностей java¬doc. Более подробное описание можно найти в документации JDK. Распаковав документацию, загляните в папку tooldocs (или перейдите по ссылке tooldocs).

Синтаксис

Все команды javadoc находятся только внутри комментариев /**. Комментарии, как обычно, завершаются последовательностью */. Существует два основных способа работы с javadoc: встраивание HTML-текста или использование размет¬ки документации (тегов). Самостоятельные теги документации — это команды, которые начинаются символом @ и размещаются с новой строки комментария.

(Начальный символ * игнорируется.) Встроенные теги документации могут располагаться в любом месте комментария javadoc, также начинаются со знака @, но должны заключаться в фигурные скобки.

Существует три вида документации в комментариях для разных элементов кода: класса, переменной и метода. Комментарий к классу записывается прямо перед его определением; комментарий к переменной размещается непосредст¬венно перед ее определением, а комментарий к методу тоже записывается пря¬мо перед его определением. Простой пример:

//. object/Documentationl.java /** Комментарий к классу */ public class Documentationl {

/** Комментарий к переменной */ public int i:

/** Комментарий к методу */ public void f() {} } ///-

Заметьте, что javadoc обрабатывает документацию в комментариях только для членов класса с уровнем доступа public и protected. Комментарии для чле¬нов private и членов с доступом в пределах пакета игнорируются, и документа¬ция по ним не строится. (Впрочем, флаг -private включает обработку и этих членов). Это вполне логично, поскольку только public- и protected-члены дос¬тупны вне файла, и именно они интересуют программиста-клиента.

Результатом работы программы является HTML-файл в том же формате, что и остальная документация для Java, так что пользователям будет привычно и удобно просматривать и вашу документацию. Попробуйте набрать текст пре¬дыдущего примера, «пропустите» его через javadoc и просмотрите полученный HTML-файл, чтобы увидеть результат.

Встроенный HTML

Javadoc вставляет команды HTML в итоговый документ. Это позволяет полно¬стью использовать все возможности HTML; впрочем, данная возможность пре¬жде всего ориентирована на форматирование кода:

II: object/Documentation2.java

* <pre>

* System out print!n(new DateO);

* </pre>

III:-

Вы можете использовать HTML точно так же, как в обычных страницах, чтобы привести описание к нужному формату:

II: object/Documentation3.java /**

* Можно <ет>даже</ет> вставить список:

* <ol>

* <li> Пункт первый

* <li> Пункт второй

* <li> Пункт третий

* </ol>

///:-

Javadoc игнорирует звездочки в начале строк, а также начальные пробелы. Текст переформатируется таким образом, чтобы он отвечал виду стандартной документации. Не используйте заголовки вида <hl> или <h2> во встроенном HTML, потому что javadoc вставляет свои собственные заголовки и ваши могут с ними «пересечься».

Встроенный HTML-код поддерживается всеми типами документации в комментариях — для классов, переменных или методов.

Примеры тегов

Далее описаны некоторые из тегов javadoc, используемых при документирова¬нии программы. Прежде чем применять javadoc для каких-либо серьезных це¬лей, просмотрите руководство по нему в документации пакета JDK, чтобы по¬лучить полную информацию о его использовании.

@see: ссылка на другие классы

Тег позволяет ссылаться на документацию к другим классам. Там, где были за¬писаны теги @see, Javadoc создает HTML-ссылки на другие документы. Основ¬ные формы использования тега:

@see имя класса

@see полное-имя-класса

@see полное-имя-класса#имя-метода

Каждая из этих форм включает в генерируемую документацию замечание See Also («см. также») со ссылкой на указанные классы. Javadoc не проверяет пе¬редаваемые ему гиперссылки.

{@link пакет.класс#член_класса метка}

Тег очень похож на @see, не считая того, что он может использоваться как встроенный, а вместо стандартного текста See Also в ссылке размещается текст, указанный в поле метка.

{@docRoot}

Позволяет получить относительный путь к корневой папке, в которой находит¬ся документация. Полезен при явном задании ссылок на страницы из дерева документации.

{@inheritDoc}

Наследует документацию базового класса, ближайшего к документируемому классу, в текущий файл с документацией.

@version

Имеет следующую форму:

(Pversion информация-о-версии

Поле информации о версии содержит ту информацию, которую вы сочли нуж¬ным включить. Когда в командной строке javadoc указывается опция -version, в созданной документации специально отводится место, заполняемое информа¬цией о версиях.

@author

Записывается в виде

©author информация-об-авторе

Предполагается, что поле информация-об-авторе представляет собой имя ав¬тора, хотя в него также можно включить адрес электронной почты и любую другую информацию. Когда в командной строке javadoc указывается опция -author, в созданной документации сохраняется информация об авторе.

Для создания списка авторов можно записать сразу несколько таких тегов, но они должны размещаться последовательно. Вся информация об авторах объ¬единяется в один раздел в сгенерированном коде HTML.

@since

Тег позволяет задать версию кода, с которой началось использование некото¬рой возможности. В частности, он присутствует в HTML-документации по Java, где служит для указания версии JDK.

@param

Полезен при документировании методов. Форма использования:

@param имя-параметра описание

где имя-параметра — это идентификатор в списке параметров метода, а описа¬ние — текст описания, который можно продолжить на несколько строк. Описа¬ние считается завершенным, когда встретится новый тег. Можно записывать любое количество тегов @param, по одному для каждого параметра метода.

©return

Форма использования:

©return описание

где описание объясняет, что именно возвращает метод. Описание может состо¬ять из нескольких строк.

@throws

Исключения будут рассматриваться в главе 9. В двух словах это объекты, кото¬рые можно «возбудить» (throw) в методе, если его выполнение потерпит неудачу. Хотя при вызове метода создается всегда один объект исключения, определен¬ный метод может вырабатывать произвольное количество исключений, и все они требуют описания. Соответственно, форма тега исключения такова:

©throws полное-имя-класса описание

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

@deprecated

Тег используется для пометки устаревших возможностей, замещенных новыми и улучшенными. Он сообщает о том, что определенные средства программы не следует использовать, так как в будущем они, скорее всего, будут убраны. В Java SE5 тег @deprecated был заменен директивой @Deprecated (см. далее).

Пример документации

Вернемся к нашей первой программе на Java, но на этот раз добавим в нее ком¬ментарии со встроенной документацией:

//: object/Hel1oDate.java import java util.*;

/** Первая программа-пример книги.

* Выводит строку и текущее число.

* ^author Брюс Эккель

* ^author www.MindView net

* (Aversion 4.0 */

public class HelloDate {

/** Точка входа в класс и приложение

* @param args Массив строковых аргументов

* @throws exceptions Исключения не выдаются */

public static void main(String[] args) {

System out.printlnCTIpMBeT. сегодня: "); System.out.println(new DateO);

}

} /* Output. (55* match) Привет, сегодня. Wed Oct 05 14:39:36 MDT 2005 */// ~

В первой строке файла использована моя личная методика помещения спе¬циального маркера //: в комментарий как признака того, что в этой строке ком¬ментария содержится имя файла с исходным текстом. Здесь указывается путь к файлу (object означает эту главу) с последующим именем файла . Последняя строка также завершается комментарием (///:~), обозначающим конец исход¬ного текста программы. Он помогает автоматически извлекать из текста книги программы для проверки компилятором и выполнения.

Тег /* Output: обозначает начало выходных данных, сгенерированных дан¬ным файлом. В этой форме их можно автоматически проверить на точность.

В данном случае значение (55% match) сообщает системе тестирования, что ре¬зультаты будут заметно отличаться при разных запусках программы. В боль¬шинстве примеров книги результаты приводятся в комментариях такого вида, чтобы вы могли проверить их на правильность.

Стиль оформления программ

Согласно правилам стиля, описанным в руководстве Code Conventions for the Java Programming Languageимена классов должны записываться с прописной буквы. Если имя состоит из нескольких слов, они объединяются (то есть симво¬лы подчеркивания не используются для разделения), и каждое слово в имени начинается с большой буквы:

class А11TheColorsOfTheRainbow { // ..

Практически для всего остального: методов, полей и ссылок на объекты — используется такой же способ записи, за одним исключением — первая буква идентификатора записывается строчной. Например:

class AllTheColorsOfTheRainbow {

int anlntegerRepresentingColors; void changeTheHueOfTheColor(int newHue) { II ...

}

// .

}

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

В исходных текстах Java, которые можно увидеть в библиотеках фирмы Sun, также используется схема размещения открывающих и закрывающих фигур¬ных скобок, которая встречается в примерах данной книги.

Резюме

В этой главе я постарался привести информацию о программировании на Java, достаточную для написания самой простой программы. Также был представлен обзор языка и некоторых его основных свойств. Однако примеры до сих пор имели форму «сначала это, потом это, а после что-то еще». В следующих двух главах будут представлены основные операторы, используемые при программи¬ровании на Java, а также способы передачи управления в вашей программе

Операторы

На нижнем уровне операции с данными в Java осуществляются посредством операторов.

Язык Java создавался на основе С++, поэтому большинство этих операторов и конструкций знакомы программистам на С и С++. Также в Java были добав¬лены некоторые улучшения и упрощения.

Если вы .знакомы с синтаксисом С или С++, бегло просмотрите эту и сле¬дующую главу, останавливаясь на тех местах, в которых Java отличается от этих языков. Если чтение дается вам с трудом, попробуйте обратиться к мультиме¬дийному семинару Thinking in С, свободно загружаемому с сайта www.Mind- View.net. Он содержит аудиолекции, слайды, упражнения и решения, специаль¬но разработанные для быстрого ознакомления с синтаксисом С, необходимым для успешного овладения языком Java.

Простые команды печати

В предыдущей главе была представлена команда печати Java

System.out.println("Какая длинная команда...");

Вероятно, вы заметили, что команда не только получается слишком длин¬ной, но и плохо читается. Во многих языках до и после Java используется более простой подход к выполнению столь распространенной операции.

В главе 6 представлена концепция статического импорта, появившаяся в Java SE5, а также крошечная библиотека, упрощающая написание команд пе¬чати. Тем не менее для использования библиотеки не обязательно знать все подробности. Программу из предыдущей главы можно переписать в следующем виде:

// operators/HelloDate java import java util *.

import static net mindview util Print.*,

public class HelloDate {

public static void main(String[] args) { print("Привет, сегодня- "); print(new DateO),

}

} /* Output- (55% match)

Привет, сегодня

Wed Oct 05 14-39 36 MDT 2005

*///:-

Результат смотрится гораздо приятнее. Обратите внимание на ключевое слово static во второй команде import.

Чтобы использовать эту библиотеку, необходимо загрузить архив с приме¬рами кода. Распакуйте его и включите корневой каталог дерева в переменную окружения CLASSPATH вашего компьютера. Хотя использование net.mindview. util. Print упрощает программный код, оно оправданно не везде. Если программа содержит небольшое количество команд печати, я отказываюсь от import и за¬писываю полный вызов System.out.println().

Операторы Java

Оператор получает один или несколько аргументов и создает на их основе но¬вое значение. Форма передачи аргументов несколько иная, чем при вызове ме¬тода, но эффект тот же самый. Сложение (+), вычитание и унарный минус (-), умножение (*), деление (/) и присвоение (=) работают одинаково фактически во всех языках программирования.

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

Почти все операторы работают только с примитивами. Исключениями явля¬ются =, = = и !=, которые могут быть применены к объектам (и создают немало затруднений). Кроме того, класс String поддерживает операции + и +=.

Приоритет

Приоритет операций определяет порядок вычисления выражений с нескольки¬ми операторами. В Java существуют конкретные правила для определения оче¬редности вычислений. Легче всего запомнить, что деление и умножение выпол¬няются раньше сложения и вычитания. Программисты часто забывают правила предшествования, поэтому для явного задания порядка вычислений следует ис¬пользовать круглые скобки. Например, взгляните на команды (1) и (2):

// operators/Precedence java

public class Precedence {

public static void main(String[] args) {

int x = 1, у = 2, z = 3; // (1)

int b = x + (y - 2)/(2 + z), // (2) System out.printlnC'a = " + a + " b = " + b;

}

} /* Output a = 5 b = 1 *///.-

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

Обратите внимание на оператор + в команде System.out.println. В данном кон¬тексте + означает конкатенацию строк, а не суммирование. Когда компилятор встречает объект String, за которым следует + и объект, отличный от String, он пытается преобразовать последний объект в String. Как видно из выходных дан¬ных, для а и b тип int был успешно преобразован в String.

Присвоение

Присвоение выполняется оператором =. Трактуется он так: «взять значение из правой части выражения (часто называемое просто значением) и скопировать его в левую часть (часто называемую именующим выражением)». Значением может быть любая константа, переменная или выражение, но в качестве име¬нующего выражения обязательно должна использоваться именованная пере¬менная (то есть для хранения значения должна выделяться физическая па¬мять). Например, вы можете присвоить постоянное значение переменной:

а = 4

но нельзя присвоить что-либо константе — она не может использоваться в каче¬стве именующего выражения (например, запись 4 = а недопустима).

Для примитивов присвоение выполняется тривиально. Так как примитив¬ный тип хранит данные, а не ссылку на объект, то присвоение сводится к про¬стому копированию данных из одного места в другое. Например, если команда а = b выполняется для примитивных типов, то содержимое b просто копируется в а. Естественно, последующие изменения а никак не отражаются на Ь. Для про¬граммиста именно такое поведение выглядит наиболее логично.

При присвоении объектов все меняется. При выполнении операций с объек¬том вы в действительности работаете со ссылкой, поэтому присвоение «одного объекта другому» на самом деле означает копирование ссылки из одного места в другое. Это значит, что при выполнении команды с = d для объектов в конеч¬ном итоге end указывают на один объект, которому изначально соответствова¬ла только ссылка d. Сказанное демонстрирует следующий пример:

//: operators/Assignment java // Присвоение объектов имеет ряд хитростей import static net.mindview.util Print.*,

class Tank {

int level,

}

public class Assignment {

public static void main(String[] args) { Tank tl = new TankO. Tank t2 = new TankO, tl level = 9; t2 level = 47,

printC'l tl level " + tl level + \ t2 level " + t2 level);

tl = t2;

print("2- tl level- " + tl level +

t2.level• " + t2 level), tl.level = 27.

print("3 tl.level- " + tl level + t2.level. " + t2 level).

}

} /* Output

1 tl level. 9. t2.level. 47

2 tl level- 47. t2 level. 47

3: tl.level. 27. t2 level: 27

*/// ~

Класс Tank предельно прост, и два его экземпляра (tl и t2) создаются внутри метода main(). Переменной level для каждого экземпляра придаются различные значения, а затем ссылка t2 присваивается tl, в результате чего tl изменяется. Во многих языках программирования можно было ожидать, что tl и t2 будут независимы все время, но из-за присвоения ссылок изменение объекта tl отра¬жается на объекте t2! Это происходит из-за того, что tl и t2 содержат одинако¬вые ссылки, указывающие на один объект. (Исходная ссылка, которая содержа¬лась в tl и указывала на объект со значением 9, была перезаписана во время присвоения и фактически потеряна; ее объект будет вскоре удален сборщиком мусора.)

Этот феномен совмещения имен часто называют синонимией (aliasing), и именно она является основным способом работы с объектами в Java. Но что делать, если совмещение имен нежелательно? Тогда можно пропустить при¬своение и записать

tl.level = t2 level;

При этом программа сохранит два разных объекта, а не «выбросит» один из них, «привязав» ссылки tl и t2 к единственному объекту. Вскоре вы поймете, что прямая работа с полями данных внутри объектов противоречит принципам объектно-ориентированной разработки. Впрочем, это непростой вопрос, так что пока вам достаточно запомнить, что присвоение объектов может таить в себе немало сюрпризов.

Совмещение имен во время вызова методов

Совмещение имен также может происходить при передаче объекта методу:

// operators/PassObject java

// Передача объектов методам может работать

// не так. как вы привыкли.

import static net.mindview.util.Print.*;

class Letter { char c;

}

public class PassObject {

static void f(Letter y) { y.c = 'z';

}

public static void main(String[] args) { Letter x = new LetterO; x.c = 'a';

printCl; x.c; " + x.c); f(x);

print("2: x.c: " + x.c);

}

} /* Output 1: x.c: a 2: x.c: z */ ///

Во многих языках программирования метод f() создал бы копию своего па¬раметра Letter у внутри своей области действия. Но из-за передачи ссылки строка

у.с = 'z';

на самом деле изменяет объект за пределами метода f().

Совмещение имен и решение этой проблемы — сложные темы. Будьте очень внимательными в таких случаях во избежание ловушек.

Арифметические операторы

Основные математические операторы остаются неизменными почти во всех языках программирования: сложение (+), вычитание (-), деление (/), умноже¬ние (*) и остаток от деления нацело (%). Деление нацело обрезает, а не округ¬ляет результат.

В Java также используется укороченная форма записи для того, чтобы одно¬временно произвести операцию и присвоение. Она обозначается оператором с последующим знаком равенства и работает одинаково для всех операторов языка (когда в этом есть смысл). Например, чтобы прибавить 4 к переменной х и присвоить результат х, используйте команду х += 4.

Следующий пример демонстрирует использование арифметических опе¬раций:

//: operators/MathOps.java // Демонстрация математических операций, import java.util.*;

import static net.mindview.util.Print.*;

public class MathOps {

public static void main(String[] args) {

// Создание и раскрутка генератора случайных чисел

Random rand = new Random(47); int i, j, k;

// Выбор значения от 1 до 100: j = rand.nextlnt(lOO) + 1: printC'j : " + j): к = rand.nextlnt(lOO) + 1. printC'k : " + k): i = J + k;

printC'j + к : " + i); 1 - J - k:

printC'j - к :" + i); i = к / j,

printC'k / j : " + i): i = к * j;

printC'k * j • " + i): i = к % j;

printC'k % j . " + i). j X= k:

printC'j %/ к • " + j); // Тесты для вещественных чисел float u.v.w; // также можно использовать double v = rand.nextFloatO; printC'v . " + v); w = rand.nextFloatO; print("w : " + w), u = v + w;

printC'v + w : " + u); u = v - w;

printC'v - w : " + u). u = v * w;

printC'v * w : " + u); u = v / w;

printC'v / w : " + u): // следующее также относится к типам // char, byte, short, int, long и double: u += v:

printC'u += v . " + u): u -= v;

printC'u -= v : " + u); u *= v:

printC'u *= v : " + u): u /= v;

printC'u /= v : " + u).

}

} /* Output: j • 59 k 56 j + k • 115 j - k • 3 k / j : 0 k * j : 3304 k % j : 56 j %= k : 3 v • 0.5309454 w : 0.0534122 v + w • 0 5843576 v - w : 0.47753322 v * w : 0.028358962

v / w 9 940527 u += v : 10.471473 u -= v 9 940527 u *= v 5 2778773 u /= v : 9 940527 */// ~

Для получения случайных чисел создается объект Random. Если он создается без параметров, Java использует текущее время для раскрутки генератора, что¬бы при каждом запуске программы выдавались разные числа.

Программа генерирует различные типы случайных чисел, вызывая соответ¬ствующие методы объекта Random: nextlnt() и nextFloat() (также можно исполь¬зовать nextLong() и nextDouble()). Аргумент nextlnt() задает верхнюю границу ге¬нерируемых чисел. Нижняя граница равна 0, но для предотвращения возмож¬ного деления на 0 результат смещается на 1.

Унарные операторы плюс и минус

Унарные минус (-) и плюс (+) внешне не отличаются от аналогичнхы бинар¬ных операторов. Компилятор выбирает нужный оператор в соответствии с кон¬текстом использования. Например, команда

х = -а;

имеет очевидный смысл. Компилятор без труда разберется, что значит

х = а * -Ь;

но читающий код может запутаться, так что яснее будет написать так:

х = а * (-Ь):

Унарный минус меняет знак числа на противоположный. Унарный плюс су¬ществует «для симметрии», хотя и не производит никаких действий.

Автоувеличение и автоуменьшение

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

Два наиболее полезных сокращения — это операторы увеличения (инкре¬мента) и уменьшения (декремента) (также часто называемые операторами ав¬томатического приращения и уменьшения). Оператор декремента записывается в виде — и означает «уменьшить на единицу». Оператор инкремента обознача¬ется символами ++ и позволяет «увеличить на единицу». Например, если пере¬менная а является целым числом, то выражение ++а будет эквивалентно (а = а + 1). Операторы инкремента и декремента не только изменяют перемен¬ную, но и устанавливают ей в качестве результата новое значение.

Каждый из этих операторов существует в двух версиях — префиксной и постфиксной. Префиксный инкремент значит, что оператор ++ записывается перед переменной или выражением, а при постфиксном инкременте оператор следует после переменной или выражения. Аналогично, при префиксном дек¬ременте оператор — указывается перед переменной или выражением, а при

постфиксном — после переменной или выражения. Для префиксного инкре¬мента и декремента (то есть ++а и —а) сначала выполняется операция, а затем выдается результат. Для постфиксной записи (а++ и а—) сначала выдается зна¬чение, и лишь затем выполняется операция. Например:

// operators/AutoInc java

import static net mindview util Print *.

public class Autolnc {

i); + ++i) + i++) i). + --i) + i-) i),

// Префиксный инкремент

// Постфиксный инкремент

// Префиксный декремент

// Постфиксный декремент

public static void main(String[] args) { int i = 1; printC'i : print("++i print("i++ printC'i • print C'--i printC'i-- printC'i

} /* Output- i . 1 ++i • 2 i++ . 2 i . 3 -i . 2 1-- 2

i • 1 *///.-

Вы видите, что при использовании префиксной формы результат получает¬ся после выполнения операции, тогда как с постфиксной формой он доступен до выполнения операции. Это единственные операторы (кроме операторов при¬сваивания), которые имеют побочный эффект. (Иначе говоря, они изменяют свой операнд вместо простого использования его значения.)

Оператор инкремента объясняет происхождение названия языка С++; под¬разумевается «шаг вперед по сравнению с С». В одной из первых речей, посвя¬щенных Java, Билл Джой (один из его создателей) сказал, что «Java=C++—» («Си плюс плюс минус минус»). Он имел в виду, что Java — это С++, из кото¬рого убрано все, что затрудняет программирование, и поэтому язык стал гораз¬до проще. Продвигаясь вперед, вы увидите, что отдельные аспекты языка, ко¬нечно, проще, и все же Java не настолько проще С++.

Операторы сравнения

Операторы сравнения выдают логический (boolean) результат. Они проверяют, в каком отношении находятся значения их операндов. Если условие проверки истинно, оператор выдает true, а если ложно — false. К операторам сравнения относятся следующие: «меньше чем» (<), «больше чем» (>), «меньше чем или равно» (<=), «больше чем или равно» (>=), «равно» (==) и «не равно» (!=). «Рав¬но» и «не равно» работают для всех примитивных типов данных, однако ос¬тальные сравнения не применимы к типу boolean.

Проверка объектов на равенство

Операции отношений == и != также работают с любыми объектами, но их смысл нередко сбивает с толку начинающих программистов на Java. Пример:

//: operators/AutoInc.java

public class Equivalence {

public static void main(String[] args) { Integer nl = new Integer(47); Integer n2 = new Integer(47); System.out.println(nl == n2); System out println(nl != n2);

}

} /* Output.

false

true

*///:-

Выражение System.out.println(nl == n2) выведет результат логического срав¬нения, содержащегося в скобках. Казалось бы, в первом случае результат дол¬жен быть истинным (true), а во втором — ложным (false), так как оба объекта типа Integer имеют одинаковые значения. Но в то время как содержимое объек¬тов одинаково, ссылки на них разные, а операторы != и == сравнивают именно ссылки. Поэтому результатом первого выражения будет false, а второго — true. Естественно, такие результаты поначалу ошеломляют.

А если понадобится сравнить действительное содержимое объектов? При¬дется использовать специальный метод equals(), поддерживаемый всеми объек¬тами (но не примитивами, для которых более чем достаточно операторов == и !=). Вот как это делается:

//: operators/EqualsMethod.java

public class EqualsMethod {

public static void main(String[] args) { Integer nl = new Integer(47); Integer n2 = new Integer(47); System.out.println(nl.equal s(n2));

}

} /* Output:

true

*///:-

На этот раз результат окажется «истиной» (true), как и предполагалось. Но все не так просто, как кажется. Если вы создадите свой собственный класс вроде такого:

//: operators/EqualsMethod2 java

// Метод equals() по умолчанию не сравнивает содержимое

class Value { int i;

}

public class EqualsMethod2 {

public static void main(String[] args) {

Value vl = new ValueO.

Value v2 = new ValueO.

vl.i = v2 i = 100;

System out println(vl equals(v2));

}

} /* Output false *///.-

мы вернемся к тому, с чего начали: результатом будет false. Дело в том, что ме¬тод equals() по умолчанию сравнивает ссылки. Следовательно, пока вы не пере¬определите этот метод в вашем новом классе, не получите желаемого результа¬та. К сожалению, переопределение будет рассматриваться только в главе 8, а пока осторожность и общее понимание принципа работы equals() позволит из¬бежать некоторых неприятностей.

Большинство классов библиотек Java реализуют метод equals() по-своему, сравнивая содержимое объектов, а не ссылки на них.

Логические операторы

Логические операторы И (&&), ИЛИ (||) и НЕ (!) производят логические значе¬ния true и false, основанные на логических отношениях своих аргументов. В следующем примере используются как операторы сравнения, так логические операторы:

//: operators/Bool Java

// Операторы сравнений и логические операторы.

import java.util.*;

import static net.mindview.util.Print.*;

public class Bool {

public static void main(String[] args) { Random rand = new Random(47); int i = rand.nextlnt(lOO): int j = rand.nextlnt(lOO); printC'i = " + i); printC'j = " + J): printC'i > j is " + (i > j)); printC'i < j is " + (i < j)); printC'i >= j is " + (i >= j)); printC'i <= j is " + (i <= j)); printC'i == j is " + (i == j)); printC'i != j is " + (i != j)); // В Java целое число (int) не может // интерпретироваться как логический тип (boolean) //! printC'i && j is " + (i && j)); //! printC'i || j is " + (i || j)); //! printC!i is " + !i); printed < 10) && (j < 10) is "

+ (d < 10) && (j < 10)) ); printed < 10) || (j < 10) is "

+ (d < 10) || (J < 10)) );

}

} /* Output: i = 58

J = 55

i > j is true i < j is false i >= j is true i <= j is false i == j is false i != j is true

(i < 10) && (j < 10) is false (i <10) || (j « 10) is false */// ~

Операции И, ИЛИ и НЕ применяются только к логическим (boolean) значе¬ниям. Нельзя использовать в логических выражениях не-Ьоо1еап-типы в качест¬ве булевых, как это разрешается в С и С++. Неудачные попытки такого рода видны в строках, помеченных особым комментарием //! (этот синтаксис позво¬ляет автоматически удалять комментарии для удобства тестирования). После¬дующие выражения вырабатывают логические результаты, используя операто¬ры сравнений, после чего к полученным значениям примененяются логические операции.

Заметьте, что значение boolean автоматически переделывается в подходящее строковое представление там, где предполагается использование строкового типа String.

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

Ускоренное вычисление

При работе с логическими операторами можно столкнуться с феноменом, назы¬ваемым «ускоренным вычислением». Это значит, что выражение вычисляется только до тех пор, пока не станет очевидно, что оно принимает значение «исти¬на» или «ложь». В результате, некоторые части логического выражения могут быть проигнорированы в процессе сравнения. Следующий пример демонстри¬рует ускоренное вычисление:

//. operators/ShortCircuit.java // Демонстрация ускоренного вычисления // при использовании логических операторов, import static net mindview util Print *;

public class ShortCircuit {

static boolean testl(int val) {

print ("testlC + val + ")"); print("результат- " + (val < 1)); return val <1,

}

static boolean test2(int val) {

print("test2(" + val + ")"); print("результат- " + (val < 2)); return val <2,

}

static boolean test3(int val) {

pnnt("test3(" + val + ")"); print("результат: " + (val < 3)). return val <3;

}

public static void main(String[] args) {

boolean b = testl(O) && test2(2) && test3(2); print ("выражение: " + b);

}

} /* Output: testl(O) результат: true test2(2)

результат: false выражение: false *///:-

Каждый из методов test() проводит сравнение своего аргумента и возвраща¬ет либо true, либо false. Также они выводят информацию о факте своего вызова. Эти методы используются в выражении

testl(O) && test2(2) && test3(2)

Естественно было бы ожидать, что все три метода должны выполняться, но результат программы показывает другое. Первый метод возвращает резуль¬тат true, поэтому вычисление выражения продолжается. Однако второй метод выдает результат false. Так как это автоматически означает, что все выражение будет равно false, зачем продолжать вычисления? Только лишняя трата вре¬мени. Именно это и стало причиной введения в язык ускоренного вычисления; отказ от лишних вычислений обеспечивает потенциальный выигрыш в произ¬водительности.

Литералы

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

//: operators/Literals.java

import static net.mindview.util.Print.*:

public class Literals {

public static void main(String[] args) {

int il = 0x2f; // Шестнадцатеричное (нижний регистр)

printC'ii: " + Integer.toBinaryString(il));

int i2 = 0X2F; // Шестнадцатеричное (верхний регистр)

print("i2: " + Integer.toBinaryString(i2));

int i3 = 0177: // Восьмеричное (начинается с нуля)

print("i3: " + Integer.toBinaryString(i3)):

char с = Oxffff; // макс, шестнадцатеричное знач. char

printC'c: " + Integer.toBinaryString(c));

byte b = 0x7f. // макс шестнадцатеричное знач. byte

printC'b " + Integer toBinaryString(b));

short s = 0x7fff. // макс шестнадцатеричное знач. short

printC's " + Integer.toBinaryString(s));

long nl = 200L; // Суффикс, обозначающий long

long n2 = 2001, // Суффикс, обозначающий long (можно запутаться)

long n3 = 200,

float fl = 1,

float f2 = IF; // Суффикс, обозначающий float float f3 = If, // Суффикс, обозначающий float double dl = Id, // Суффикс, обозначающий double double d2 = ID; // Суффикс, обозначающий double

}

} /* Output- il 101111 12 101111 13: 1111111 c: 1111111111111111 b: 1111111 s- 111111111111111 *///:-

Последний символ обозначает тип записанного литерала. Прописная или строчная буква L определяет тип long (впрочем, строчная I может создать про¬блемы, потому что она похожа на цифру 1); прописная или строчная F соответ¬ствует типу float, а заглавная или строчная D подразумевает тип double.

Шестнадцатеричное представление (основание 16) работает со всеми встро¬енными типами данных и обозначается префиксом Ох или ОХ с последующим числовым значением из цифр 0-9 и букв a-f, прописных или строчных. Если при определении переменной задается значение, превосходящее максимально для нее возможное (независимо от числовой формы), компилятор сообщит вам об ошибке. В программе указаны максимальные значения для типов char, byte и short. При выходе за эти границы компилятор автоматически сделает значе¬ние типом int и сообщит вам, что для присвоения понадобится сужающее при¬ведение.

Восьмеричное представление (по основанию 8) обозначается начальным ну¬лем в записи числа, состоящего из цифр от 0 до 7. Для литеральной записи чи¬сел в двоичном представлении в Java, С и С++ поддержки нет. Впрочем, при ра¬боте с шестнадцатеричныыми и восьмеричными числами часто требуется по¬лучить двоичное представление результата. Задача легко решается методами static toBinaryString() классов Integer и Long.

Экспоненциальная запись

Экспоненциальные значения записываются, по-моему, очень неудачно: 1.39e-47f. В науке и инженерном деле символом е обозначается основание натурального логарифма, равное примерно 2,718. (Более точное значение этой величины можно получить из свойства Math.E.) Оно используется в экспоненциальных выражениях, таких как 1,39хе-47, что фактически значит 1,39х2,718-47. Одна¬ко во время изобретения языка FORTRAN было решено, что е будет обозначать «десять в степени», что достаточно странно, поскольку FORTRAN разрабатывался для науки и техники и можно было предположить, что его создатели обратят внимание на подобную неоднозначность1. Так или иначе, этот обычай был пе¬ренят в С, С++, а затем перешел в Java. Таким образом, если вы привыкли ви¬деть в е основание натурального логарифма, вам придется каждый раз делать преобразование в уме: если вы увидели в Java выражение 1.39e-43f, на самом деле оно значит 1,39х10~43.

Если компилятор может определить тип автоматически, наличие завершаю¬щего суффикса типа не обязательно. В записи

long пЗ = 200;

не существует никаких неясностей, и поэтому использование символа L после значения 200 было бы излишним. Однако в записи

float f4 = le-43f; // десять в степени

компилятор обычно трактует экспоненциальные числа как double. Без завер¬шающего символа f он сообщит вам об ошибке и необходимости использования приведения для преобразования double к типу float.

Поразрядные операторы

Поразрядные операторы манипулируют отдельными битами в целочисленных примитивных типах данных. Результат определяется действиями булевой ал¬гебры с соответствующими битами двух операндов.

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

Поразрядный оператор И (&) заносит 1 в выходной бит, если оба входных бита были равны 1; в противном случае результат равен 0. Поразрядный опера¬тор ИЛИ (|) заносит 1 в выходной бит, если хотя бы один из битов операндов был равен 1; результат равен 0 только в том случае, если оба бита операндов были нулевыми. Оператор ИСКЛЮЧАЮЩЕЕ ИЛИ (XOR, л) имеет результатом единицу тогда, когда один из входных битов был единицей, но не оба вместе. По¬разрядный оператор НЕ (~, также называемый оператором двоичного дополне¬ния) является унарным оператором, то есть имеет только один операнд. Пораз¬рядное НЕ производит бит, «противоположный» исходному — если входящий бит является нулем, то в результирующем бите окажется единица, если входя¬щий бит — единица, получится ноль.

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

Поразрядные операторы могут комбинироваться со знаком равенства =, что¬бы совместить операцию и присвоение: &=, |= и л= являются допустимыми соче¬таниями. (Так как ~ является унарным оператором, он не может использовать¬ся вместе со знаком =.)

Тип boolean трактуется как однобитовый, поэтому операции с ним выглядят по-другому. Вы вправе выполнить поразрядные И, ИЛИ и ИСКЛЮЧАЮЩЕЕ ИЛИ, но НЕ использовать запрещено (видимо, чтобы предотвратить путаницу с логическим НЕ). Для типа boolean поразрядные операторы производят тот же эффект, что и логические, за одним исключением — они не поддерживают уско¬ренного вычисления. Кроме того, в число поразрядных операторов для boolean входит оператор ИСКЛЮЧАЮЩЕЕ ИЛИ, отсутствующий в списке логиче¬ских операторов. Для булевых типов не разрешается использование операторов сдвига, описанных в следующем разделе.

Операторы сдвига

Операторы сдвига также манипулируют битами и используются только с при¬митивными целочисленными типами. Оператор сдвига влево («) сдвигает вле¬во операнд, находящийся слева от оператора, на количество битов, указанное после оператора. Оператор сдвига вправо (») сдвигает вправо операнд, находя¬щийся слева от оператора, на количество битов, указанное после оператора. При сдвиге вправо используется заполнение знаком: при положительном значе¬нии новые биты заполняются нулями, а при отрицательном — единицами. В Java также поддерживается беззнаковый сдвиг вправо »>, использующий за¬полнение нулями: независимо от знака старшие биты заполняются нулями. Та¬кой оператор не имеет аналогов в С и С++.

Если сдвигаемое значение относится к типу char, byte или short, эти типы приводятся к int перед выполнением сдвига, и результат также получится int. При этом используется только пять младших битов с «правой» стороны. Таким образом, нельзя сдвинуть битов больше, чем вообще существует для целого числа int. Если вы проводите операции с числами long, то получите результаты типа long. При этом будет задействовано только шесть младших битов с «пра¬вой» стороны, что предотвращает использование излишнего числа битов.

Сдвиги можно совмещать со знаком равенства («=, или »=, или »>=). Име¬нующее выражение заменяется им же, но с проведенными над ним операциями сдвига. Однако при этом возникает проблема с оператором беззнакового право¬го сдвига, совмещенного с присвоением. При использовании его с типом byte или short вы не получите правильных результатов. Вместо этого они сначала будут преобразованы к типу int и сдвинуты вправо, а затем обрезаны при воз¬вращении к исходному типу, и результатом станет -1. Следующий пример де¬монстрирует это:

//: operators/URShi ft java // Проверка беззнакового сдвига вправо, import static net.mindview.util Print *;

public class URShift {

public static void main(String[] args) { int i = -1;

print(Integer.toBinaryString(i)); i »>= 10;

print(Integer.toBinaryString(i)), long 1 = -1;

print(Long.toBinaryString(l)); 1 »>= 10;

print(Long.toBinaryString(l)); short s = -1;

printdnteger toBinaryString(s)); s »>= 10;

pri nt(Integer.toBi na ryStri ng(s)), byte b = -1;

printdnteger toBinaryString(b)); b »>= 10;

pri nt(Integer.toBi na ryString(b)); b = -1;

pri nt(Integer.toBi na rySt ring(b)), pri nt (I nteger. toBi narySt ri ng( b»>10));

}

} /* Output; 11111111111111111111111111111111 1111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111 11111111111111111111111111111111 11111111111111111111111111111111 11111111111111111111111111111111 11111111111111111111111111111111 11111111111111111111111111111111 1111111111111111111111

В последней команде программы полученное значение не приводится обрат¬но к Ь, поэтому получается верное действие.

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

//; operators/BitManipulation.java // Использование поразрядных операторов, import java.util.*;

import static net.mindview.util Print.*;

public class BitManipulation {

public static void main(String[] args) { Random rand = new Random(47);

int i = rand nextlntO, int j = rand.nextlntO. printBinarylntC'-l", -1); printBinarylntC'+l", +1); int maxpos = 2147483647; printBinaryInt("макс положит.", maxpos); int maxneg = -2147483648; printBinarylntC'MaKc отрицат.". maxneg); printBinarylntC'i". i); printBinaryInt("~i", ~i); printBinaryInt("-i", -i); printBinarylntC'j", j), printBinarylntC'i & j". i & j), printBinarylntC'i | j", i | j); printBinarylntC'i A j". i A j); printBinarylntC'i « 5", i «5); printBinarylntC'i » 5", i » 5): printBinarylntC'M) » 5", (~i) » 5); printBinarylntC'i »> 5", i »> 5); printBinarylntC'M) »> 5", (~i) »> 5);

long 1 = rand.nextLongO; long m = rand.nextLongO; printBinaryLong("-lL", -1L); printBinaryLong("+lL", +1L): long 11 = 9223372036854775807L, printBinaryLongC'MaKC. положит.", 11); long 1 In = -9223372036854775808L; printBinaryLongC'MaKC. отрицат ", lln); printBinaryLongC'l", 1); printBinaryLong("~l", -1), printBinaryLong("-l", -1), printBi naryLongC'm", m), printBinaryLongC'l & m", 1 & m); printBinaryLongC'l | m", 1 | m); printBinaryLongC'l A m", 1 A m); printBinaryLongC'l « 5", 1 «5); printBinaryLongC'l » 5". 1 » 5); printBinaryLong("(~l) » 5", (~1) » 5). printBinaryLongC'l »> 5". 1 »> 5); printBi naryLongC'H) »> 5", (~1) »> 5); moni tor.expect("Bi tMani pulati on.out");

}

static void printBinaryInt(String s, int i) {

print(s + ". int: " + i + двоичное: \n " + Integer toBinaryString(i));

}

static void printBinaryLong(String s, long 1) {

print(s + \ long: " + 1 + ", двоичное:\п " + Long.toBinaryStringd));

}

} /* Output-

-1, int- -1, двоичное.

11111111111111111111111111111111 +1, int. 1, двоичное. 1

макс, положит . int- 2147483647. двоичное:1111111111111111111111111111111

макс, отрицат., int: -2147483648, двоичное- 10000000000000000000000000000000 i, int- -1172028779. двоичное: 10111010001001000100001010010101 ~i, int. 1172028778, двоичное. 1000101110110111011110101101010 -i, int. 1172028779. двоичное: 1000101110110111011110101101011 j. int: 1717241110, двоичное: 1100110010110110000010100010110 i & j, int- 570425364, двоичное: 100010000000000000000000010100 i | j, int. -25213033, двоичное. 11111110011111110100011110010111 i A j. int: -595638397, двоичное. 11011100011111110100011110000011 i «5, int: 1149784736, двоичное- 1000100100010000101001010100000 i » 5, int -36625900, двоичное. 11111101110100010010001000010100 (~i) » 5, int 36625899, двоичное. 10001011101101110111101011 i »> 5, int. 97591828, двоичное. 101110100010010001000010100 (~i) »> 5, int- 36625899, двоичное. 10001011101101110111101011

*///.-

Два метода в конце, printBinaryInt() и printBinaryl_ong(), получают в качестве параметров, соответственно, числа int и long и выводят их в двоичном формате вместе с сопроводительным текстом. Вместе с демонстрацией поразрядных опе¬раций для типов int и long этот пример также выводит минимальное и макси¬мальное значение, +1 и -1 для этих типов, чтобы вы лучше понимали, как они выглядят в двоичном представлении. Заметьте, что старший бит обозначает знак: 0 соответствует положительному и 1 — отрицательному числам. Резуль¬тат работы для типа int приведен в конце листинга

Тернарный оператор «если-иначе»

Тернарный оператор необычен тем, что он использует три операнда. И все же это действительно оператор, так как он производит значение, в отличие от обычной конструкции выбора if-else, описанной в следующем разделе. Выра¬жение записывается в такой форме:

логическое-условие ? выражениеО : выражение1

Если логическое-условие истинно (true), то затем вычисляется выражениеО, и именно его результат становится результатом выполнения всего оператора. Если же логическое-условие ложно (false), то вычисляется выражение1, и его зна¬чение становится результатом работы оператора.

Конечно, здесь можно было бы использовать стандартную конструкцию if-else (описываемую чуть позже), но тернарный оператор гораздо компактнее. Хотя С (где этот оператор впервые появился) претендует на звание лаконичного языка, и тернарный оператор вводился отчасти для достижения этой цели, будьте благоразумны и не используйте его всюду и постоянно — он может ухуд¬шить читаемость программы.

Операторы + и += для String

В Java существует особый случай использования оператора: операторы + и += могут применяться для конкатенации (объединения) строк, и вы уже это видели. Такое действие для этих операторов выглядит вполне естественно, хотя оно и не соответствует традиционным принципам их использования.

При создании С++ в язык была добавлена возможность перегрузки операто¬ров, позволяющей программистам С++ изменять и расширять смысл почти лю¬бого оператора. К сожалению, перегрузка операторов, в сочетании с некоторы¬ми ограничениями С++, создала немало проблем при проектировании классов. Хотя реализацию перегрузки операторов в Java можно было осуществить проще, чем в С++ (это доказывает язык С#, где существует простой механиз перегруз¬ки), эту возможность все же посчитали излишне сложной, и поэтому програм¬мистам на Java не дано реализовать свои собственные перегруженные опера¬торы, как это делают программисты на С++.

Использование + и += для строк (String) имеет интересные особенности. Если выражение начинается строкой, то все последующие операнды также должны быть строками (помните, что компилятор превращает символы в ка¬вычках в объект String).

int х = 0. у = 1. z = 2;

String s = "х. у, z

System.out.println(s + x + у + z),

В данном случае компилятор Java приводит переменные х, у и z к их строко¬вому представлению, вместо того чтобы сначала арифметически сложить их. А если вы запишете

System.out.println(x + s); то и здесь Java преобразует х в строку.

Типичные ошибки при использовании операторов

Многие программисты склонны второпях записывать выражение без скобок, даже когда они не уверены в последовательности вычисления выражения. Это верно и для Java.

Еще одна распространенная ошибка в С и С++ выглядит следующим об¬разом:

while(x = у) { // .

}

Программист хотел выполнить сравнение (==), а не присвоение. В С и С++ результат этого выражения всегда будет истинным, если только у не окажется нулем; вероятно, возникнет бесконечный цикл. В языке Java результат такого выражения не будет являться логическим типом (boolean), а компилятор ожи¬дает в этом выражении именно boolean и не разрешает использовать целочис¬ленный тип int, поэтому вовремя сообщит вам об ошибке времени компиляции, упредив проблему еще перед запуском программы. Поэтому подобная ошибка в Java никогда не происходит. (Программа откомпилируется только в одном случае: если х и у одновременно являются типами boolean, и тогда выражение х = у будет допустимо, что может привести к ошибке.)

Похожая проблема возникает в С и С++ при использовании поразрядных операторов И и ИЛИ вместо их логических аналогов. Поразрядные И и ИЛИ записываются одним символом (& и |), в то время как логические И и ИЛИ тре¬буют в написании двух символов (&& и ||). Так же, как и в случае с операторами = и ==, легко ошибиться и набрать один символ вместо двух. В Java компилятор предотвращает такие ошибки, так как он не позволяет использовать тип данных в неподходящем контексте.

Операторы приведения

Слово приведение используется в смысле «приведение к другому типу». В опре¬деленных ситуациях Java самостоятельно преобразует данные к другим типам. Например, если вещественной переменной присваивается целое значение, ком¬пилятор автоматически выполняет соответствующее преобразование (int пре¬образуется во float). Приведение позволяет сделать замену типа более очевид¬ной или выполнить ее принудительно в случаях, где это не происходит в обыч¬ном порядке.

Чтобы выполнить приведение явно, запишите необходимый тип данных (включая все модификаторы) в круглых скобках слева от преобразуемого зна¬чения. Пример:

//: operators/Casting.java

public class Casting {

public static void main(String[] args) { int i = 200; long lng = (long)i;

Ing = i; // "Расширение", явное преобразование не обязательно long lng2 = (long)200; lng2 = 200;

// "Сужающее" преобразование i = (int)lng2; // Преобразование необходимо

}

} ///:-

Как видите, приведение может выполняться и для чисел, и для переменных. Впрочем, в указанных примерах приведение является излишним, поскольку компилятор при необходимости автоматически преобразует целое int к типу long. Однако это не мешает вам выполнять необязательные приведения — на¬пример, чтобы подчеркнуть какое-то обстоятельство или просто для того, что¬бы сделать программу более понятной. В других ситуациях приведение может быть необходимо для нормальной компиляции программы.

В С и С++ приведение могло стать источником ошибок и неоднозначности. В Java приведение безопасно, за одним исключением: при выполнении так на¬зываемого сужающего приведения (то есть от типа данных, способного хранить больше информации, к менее содержательному типу данных), то есть при опас¬ности потери данных. В таком случае компилятор заставляет вас выполнить яв¬ное приведение; фактически он говорит: «это может быть опасно, но, если вы уверены в своей правоте, опишите действие явно». В случае с расширяющим приведением явное описание не понадобится, так как новый тип данных спосо¬бен хранить больше информации, чем прежний, и поэтому потеря данных ис¬ключена.

В Java разрешается приводить любой простейший тип данных к любому другому простейшему типу, но это не относится к типу boolean, который вооб¬ще не подлежит приведению. Классы также не поддерживают произвольное приведение. Чтобы преобразовать один класс в другой, требуются специальные методы. (Как будет показано позднее, объекты можно преобразовывать в рам¬ках семейства типов; объект Дуб можно преобразовать в Дерево и наоборот, но не к постороннему типу вроде Камня.)

Округление и усечение

При выполнении сужающих преобразований необходимо обращать внимание на усечение и округление данных. Например, как должен действовать компиля¬тор Java при преобразовании вещественного числа в целое? Скажем, если зна¬чение 29,7 приводится к типу int, что получится — 29 или 30? Ответ на этот во¬прос может дать следующий пример:

//: operators/CastingNumbers.java // Что происходит при приведении типов // float или double к целочисленным значениям? import static net.mindview.util.Print *;

public class CastingNumbers {

public static void main(String[] args) { double above = 0.7, below = 0.4; float fabove = 0.7f, fbelow = 0 4f; print("(int)above: " + (int)above); print("(int)below: " + (int)below), printC(int)fabove- " + (int)fabove); print("(int)fbelow. " + (int)fbelow),

}

} /* Output: (int)above: 0 (int)below. 0 (int)fabove: 0 (int)fbelow: 0 *///:-

Отсюда и ответ на наш вопрос — приведение от типов с повышенной точно¬стью double и float к целочисленным значениям всегда осуществляется с усечени¬ем целой части. Если вы предпочитаете, чтобы результат округлялся, используйте метод round() из java.lang.Math. Так как этот метод является частью java.lang, до¬полнительное импортирование не потребуется.

Повышение

Вы можете обнаружить, что при проведении любых математических и пораз¬рядных операций примитивные типы данных, меньшие int (то есть char, byte и short), приводятся к типу int перед проведением операций, и получаемый ре¬зультат имеет тип int. Поэтому, если вам снова понадобится присвоить его меньшему типу, придется использовать приведение. (И тогда возможна потеря информации.) В основном самый емкий тип данных, присутствующий в выра¬жении, и определяет величину результата этого выражения; так, при перемно¬жении float и double результатом станет double, а при сложении long и int вы по¬лучите в результате long.

В Java отсутствует sizeof()

В С и С++ оператор sizeof() выдает количество байтов, выделенных для хране¬ния данных. Главная причина для использования sizeof() — переносимость про¬граммы. Различным типам данных может отводиться различное количество па¬мяти на разных компьютерах, поэтому для программиста важно определить размер этих типов перед проведением операций, зависящих от этих величин. Например, один компьютер выделяет под целые числа 32 бита, а другой — всего лишь 16 бит. В результате на первой машине программа может хранить в цело¬численном представлении числа из большего диапазона. Конечно, аппаратная совместимость создает немало хлодот для программистов на С и С++.

В Java оператор sizeof() не нужен, так как все типы данных имеют одинако¬вые размеры на всех машинах. Вам не нужно заботиться о переносимости на низком уровне — она встроена в язык.

Сводка операторов

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

// operators/AHOps java

// Проверяет все операторы со всеми

// примитивными типами данных, чтобы показать,

// какие операции допускаются компилятором Java

public class AT 1 Ops {

// для получения результатов тестов типа boolean: void f(boolean b) {} void boolTest(boolean x, boolean y) { // Арифметические операции- //' x = x * у; //! x = x / у;

//! х = х % у; III х = х + у; III х = х - у; III х++; //! х--; //! х = +у; //! х = -у;

// Операции сравнения и логические операции:

III f(х > у),

//! f(х >= у);

III f(х < у).

Ill f(х <= у);

f(x == у),

f(х != у);

f(!y);

х = х && у: х = х || у.

III х =

X = X =

II II II // // // // // // // // // X &= у: х А= у: х |= у.

// Приведение-

// Поразрядные операторы:

-у; & у.

у:

У:

х « 1; х » 1, х »> 1; Совмещенное присваивание: х += у: х у. *= У; /= у; := У. «= 1; »= 1. »>= 1;

II char с = (char)x,

II byte В = (byte)x:

II short s : = (short)x;

II int i = (int)x:

П long 1 = (long)x:

п float f ; = (float)x;

II double d = (double)x;

void charTest(char х, char у) {

х = х

х++, х- -,

X = X =

// Арифметические операции- х = (char)(x * у): х = (char)(x / у). х = (char)(x % у), (char)Сх + у), (char)(x - у),

(char)+y; (char)-y:

// Операции сравнения и логические операции:

f(x > у);

f(x >= у);

f(x < у);

f(x <= у);

f(x == у);

fCx != у);

//! f(!x);

//! f(x && у);

//! f(x || у).

// Поразрядные операции:

х= (charby;

х = (char)(x & у).

х = (char)(x | у):

х = (char)(x А у):

х = (char)(x « 1):

х = (char)(x » 1):

х = (char)(x »> 1):

// Совмещенное присваивание:

х += у,

х -= у:

х *= у;

х /= у:

х Х- у:

х «= 1.

X »= 1,

х »>= 1: х &= у; х А= у; х |= У.

// Приведение-

//! boolean b = (boolean)x:

byte В = (byte)x:

short s = (short)x;

int i = (int)x;

long 1 = (long)x:

float f = (float)x;

double d = (double)x,

}

void byteTest(byte x. byte y) {

// Арифметические операции- x = (byte)(x* у): x = (byte)(x / y): x = (byte)(x % y), x = (byte)Cx + y); x = (byte)(x - y), x++: x--:

x = (byte)+ y: x = (byte)- y:

// Операции сравнения и логические операции:

f(x > у);

f(x >= у):

f(x < у);

f(x <= у):

f(x == у):

f(x != у):

//! f(!x):

//! f(x && у),

//! f(x || у); // Поразрядные операции: х = (byte)-y; х = (byte)(х & у): х = (byte)(x | у); х = (byte)(x А у); х = (byte)(x « 1); х = (byte)(x » 1); х = (byte) (х »> 1). // Совмещенное присваивание: х += у: х -= у: х *= у: х /= у: х у. х «= 1; х »= 1, х »>= 1, х &= у; х у. х |= У,

// Приведение:

//! boolean b = (boolean)x,

char с = (char)x;

short s = (short)x;

int i = (int)x:

long 1 = (long)x:

float f = (float)x.

double d = (double)x,

}

void shortTest(short x. short y) { // Арифметические операции: x = (shortKx * y): x = (shortKx / y), x = (shortKx % y): x = (shortKx + y); x = (shortKx - y): x++; x--:

x = (short)+y, x = (short)-y;

// Операции сравнения и логические

f(x > у);

f(x >= у):

f(x < у):

f(x <= у);

f(x == у);

f(x != у);

//! f(!x);

//! f(x && у);

//! f(x || у):

// Поразрядные операции:

х = (short)~у,

х = (shortKx & у);

х = (shortKx | у):

х = (short)(х А у):

х = (shortKx « 1);

операции:

х = (shortKx » 1);

х = (short)(х »> 1); // Совмещенное присваивание: х += у. х -= у. х *= у. х /= у: х %= у: х «= 1.

X »= 1. X »>= 1.

X &= у: х А= у. х |= у:

// Преобразование

//> boolean b = (boolean)x.

char с = (char)x.

byte В = (byte)x,

int i = (int)x.

long 1 = (long)x,

float f = (float)x;

double d = (double)x.

}

void intTest(int x, int y) {

// Арифметические операции:

x = x * у:

x = x / у.

х = х % у,

х = х + у,

х = х - у,

х++;

х- -:

х = +у;

х = -у.

// Операции сравнения и логические операции:

f(х > у).

f(х >= у).

f(х < у):

f(x <= у):

f(х == у).

f(х у).

//! f(!x):

//' f(x && у).

//! f(x || у),

// Поразрядные операции:

х = -у.

X = X & у,

X = X I у,

х = х А у:

х = х « 1;

х = х » 1:

х = х »> 1.

// Совмещенное присваивание- х += у; х -= у. х *= у. х /= у. х Х- у, х «= 1;

X »= 1.

х »>= 1; х &= у; х А= у. х |= у:

// Приведение-

//' boolean b = (boolean)x;

char с = (char)x,

byte В = (byte)x;

short s = (short)x;

long 1 = (long)x;

float f = (float)x,

double d = (double)x;

}

void longTestdong x, long y) {

// Арифметические операции:

x = x * у:

x = x / у;

x = x % у.

х = х + у:

х = х - у,

х++,

х- -;

х = +у;

х = -у:

// Операции сравнения и логические

f(х > у):

f(х >= у):

f(х < у),

f(х <= у):

f (х == у).

f(х != у).

//! f(!x).

//! f(x && у),

//! f(x || у):

// Поразрядные операции.

х = ~у.

х = х & у:

х = х | у:

х = х А у.

х = х « 1:

х = х » 1;

х = х »> 1:

// Совмещенное присваивание: х += у: х -= у. х *= у: х /= у: х у. х «= 1. х »= 1: х »>= 1: х &= у: х А= у: х |= у.

// Приведение-

операции:

//! boolean b = (boolean)x: . char с = (char)x.

byte В = (byte)x; short s = (short)x; int i = (int)x; float f = (float)x; double d = (double)x;

}

void floatTest(float x, float y) { // Арифметические операции: x = x * у, x = x / у. х = х % у; х = х + у: х = х - у; х++; х- -; х = +у; х = -у;

// Операции сравнения и логические операции:

f(x > у);

f(x >= у).

f(x < у);

f(x <= у),

f(х == у):

f(х != у),

//! f(!x):

//! f(х && у):

//! f(x || у):

// Поразрядные операции:

//! х = ~у;

//! х - х & у;

//! х = х | у;

//! х = х х у:

//! х = х « 1:

//! х = х » 1:

//! х = х »> 1;

// Совмещенное присваивание:

х += у:

х -= у;

х *= у:

х /= у;

х у;

//! х «= 1;

//! х »= 1:

//! х »>= 1:

//! х &= у;

//! х А= у;

//! х |= у;

// Приведение:

//! boolean b = (boolean)x;

char с = (char)x;

byte В = (byte)x;

short s = (short)x,

int i = (int)x;

long 1 = (long)x;

double d = (double)x:

}

void doubleTest(double x. double y) { // Арифметические операции:

х = х * у; х = х / у. х = х % у, х = х + у; х = х - у. х++, х- -; х = +у. х = -у;

// Операции сравнения и логические операции:

f(x > у).

f(x >= у):

f(x < у),

f(x <= у).

f(x == у);

f(x '= у):

//! f(!x).

//! f(x && у).

//! f(x || у):

// Поразрядные операции

//! х = ~у:

//! х = х & у,

//! х = х | у:

//! х = хАу;

//! х = х « 1:

//! х = х » 1;

//! х = х »> 1;

// Совмещенное присваивание:

х += у.

х у,

х *= у,

х /= у;

х %= у:

//! х «= 1;

//! х »= 1.

//! х »>= 1,

//! х &= у.

//! х ж= у:

//! х |= у:

// Приведение-

//! boolean b = (boolean)x.

char с = (char)x:

byte В = (byte)x:

short s = (short)x,

int i = (int)x;

long 1 = (long)x;

float f = (float)x:

}

} /// ~

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

В случае с типами char, byte и short можно заметить эффект повышения при использовании арифметических операторов. Любая арифметическая операция с этими типами дает результат типа int, который затем нужно явно приводить к изначальному типу (сужающее приведение, при котором возможна потеря информации). При использовании значений типа int приведение осуществлять не придется, потому что все значения уже имеют этот тип. Однако не заблуж¬дайтесь относительно безопасности происходящего. При перемножении двух достаточно больших целых чисел int произойдет переполнение. Следующий пример демонстрирует сказанное:

// operators/Overflow java

// Сюрприз! В Java можно получить переполнение.

public class Overflow {

public static void main(String[] args) { int big = Integer MAX_VALUE; System, out. рппЫпСболыиое = " + big); int bigger = big * 4;

System.out.printlnCeiue больше = " + bigger);

}

} /* Output большое = 2147483647 еще больше = -4 *///.-

Компилятор не выдает никаких ошибок или предупреждений, и во время ис¬полнения не возникнет исключений. Язык Java хорош, но хорош не настолько.

Совмещенное присваивание не требует приведения для типов char, byte и short, хотя для них и производится повышение, как и в случае с арифметиче¬скими операциями. С другой стороны, отсутствие приведения в таких случаях, несомненно, упрощает программу.

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

Резюме

Читатели с опытом работы на любом языке семейства С могли убедиться, что операторы Java почти нйчем не отличаются от классических. Если же материал этой главы показался трудным, обращайтесь к мультимедийной презентации «Thinking in С» (www.MindView.net).

Управляющие конструкции

Подобно любому живому существу, программа должна управлять своим миром и принимать решения во время исполнения. В языке Java для принятия решений используются управляющие конструкции.

В Java задействованы все управляющие конструкции языка С, поэтому чита¬телям с опытом программирования на языке С или С++ основная часть мате¬риала будет знакома. Почти во всех процедурных языках поддерживаются стандартные команды управления, и во многих языках они совпадают. В Java к их числу относятся ключевые слова if-else, while, do-while, for, а также команда выбора switch. Однако в Java не поддерживается часто критикуемый оператор goto (который, впрочем, все же является самым компактным решением в неко¬торых ситуациях). Безусловные переходы «в стиле» goto возможны, но гораздо более ограничены по сравнению с классическими переходами goto.

true и false

Все конструкции с условием вычисляют истинность или ложность условного выражения, чтобы определить способ выполнения. Пример условного выраже¬ния — А — В. Оператор сравнения = проверяет, равно ли значение А значению В. Результат проверки может быть истинным (true) или ложным (false). Любой из описанных в этой главе операторов сравнения может применяться в условном выражении. Заметьте, что Java не разрешает использовать числа в качестве ло¬гических значений, хотя это позволено в С и С++ (где не-ноль считается «ис¬тинным», а ноль — «ложным»). Если вам потребуется использовать числовой тип там, где требуется boolean (скажем, в условии if(a)), сначала придется его преобразовать к логическому типу оператором сравнения в условном выраже¬нии — например, if (а != 0).

if-else

Команда if-else является, наверное, наиболее распространенным способом пере¬дачи управления в программе. Присутствие ключевого слова else не обязатель¬но, поэтому конструкция if существует в двух формах:

if(логическое выражение) команда

и

if(логическое выражение) команда

else

команда

Условие должно дать результат типа boolean. В секции команда располагает¬ся либо простая команда, завершенная точкой с запятой, либо составная конст¬рукция из команд, заключенная в фигурные скобки.

В качестве примера применения if-else представлен метод test(), который вы¬дает информацию об отношениях между двумя числами — «больше», «меньше» или «равно»:

//. control/IfElse.java

import static net.mindview.util.Print.*;

public class IfElse {

static int result = 0; static void test(int testval. int target) { if(testval > target) result = +1; else if(testval < target) result = -1:

else

result = 0; // равные числа

}

public static void main(String[] args) { test(10. 5); print(result); test(5. 10); print(result); test(5. 5); print(result);

}

} /* Output:

1

-1

0

Внутри метода test() встречается конструкция else if; это не новое ключевое слово, a else, за которым следует начало другой команды — if.

Java, как и С с С++, относится к языкам со свободным форматом. Тем не ме¬нее в командах управления рекомендуется делать отступы, благодаря чему чи¬тателю программы будет легче понять, где начинается и заканчивается управ¬ляющая конструкция.

Управляющие конструкции

Циклы

Конструкции while, do-while и for управляют циклами и иногда называются цик¬лическими командами. Команда повторяется до тех пор, пока управляющее логи¬ческое выражение не станет ложным. Форма цикла while следующая:

\л/ИПе(логическое выражение) команда

логическое выражение вычисляется перед началом цикла, а затем каждый раз пе¬ред выполнением очередного повторения оператора.

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

//: control/WhileTest java // Пример использования цикла while

public class WhileTest {

static boolean conditionO {

boolean result = Math.randomO < 0.99; System.out.print(result + "); return result;

}

public static void main(String[] args) { while(conditionO)

System out printlnC"Inside 'while"'), System.out.println("Exited 'while'");

}

} /* (Выполните, чтобы просмотреть результат) *///•-

В примере используется статический метод random() из библиотеки Math, ко¬торый генерирует значение double, находящееся между 0 и 1 (включая 0, но не 1). Условие while означает: «повторять, пока condition() возвращает true». При каж¬дом запуске программы будет выводиться различное количество чисел.

do-while

Форма конструкции do-while такова:

do

команда

и/1гЛе(логическое выражение);

Единственное отличие цикла do-while от while состоит в том, что цикл do- while выполняется по крайней мере единожды, даже если условие изначально ложно. В цикле while, если условие изначально ложно, тело цикла никогда не от¬рабатывает. На практике конструкция do-while употребляется реже, чем while.

for

103

Пожалуй, конструкции for составляют наиболее распространенную разновид¬ность циклов. Цикл for проводит инициализацию перед первым шагом цикла. Затем выполняется проверка условия цикла, и в конце каждой итерации

осуществляется некое «приращение» (обычно изменение управляющей пере¬менной). Цикл for записывается следующим образом:

^(инициализация; логическое выражение; шаг)

команда

Любое из трех выражений цикла (инициализация, логическое выражение или шаг) можно пропустить. Перед выполнением каждого шага цикла проверяется условие цикла; если оно окажется ложно, выполнение продолжается с инструк¬ции, следующей за конструкцией for. В конце каждой итерации выполняется секция шаг.

Цикл for обычно используется для «счетных» задач:

// control/ListCharacters.java

// Пример использования цикла "for": перебор

// всех ASCII-символов нижнего регистра

public class ListCharacters {

public static void main(String[] args) { for(char с = 0, с < 128, С++)

i f(Character.i sLowerCase(c))

System out рппШСзначение- " + (int)c + " символ. " + с).

}

} /* Output- значение 97 символ a значение 98 символ b" значение 99 символ с" значение 100 символ d" значение- 101 символ: е" значение 102 символ, f" значение 103 символ, д" значение 104 символ: h" значение- 105 символ- i значение 106 символ- j

*///:-

Обратите внимание, что переменная i определяется в точке ее использова¬ния, в управляющем выражении цикла for, а не в начале блока, обозначенного фигурными скобками. Область действия для i — все выражения, принадлежа¬щие циклу.

В программе также используется класс-«обертка» java.Lang.Character, кото¬рый не только позволяет представить простейший тип char в виде объекта, но и содержит ряд дополнительных возможностей. В нашем примере используется статический метод этого класса isLowerCase(), который проверяет, является ли некоторая буква строчной.

Традиционные процедурные языки (такие, как С) требовали, чтобы все пе¬ременные определялись в начале блока цикла, чтобы компилятор при создании блока мог выделить память под эти переменные. В Java и С++ переменные раз¬решено объявлять в том месте блока цикла, где это необходимо. Это позволяет программировать в более удобном стиле и упрощает понимание кода.

Оператор-запятая

Ранее в этой главе уже упоминалось о том, что оператор «запятая» (но не запя- тая-разделитель, которая разграничивает определения и аргументы функций) может использоваться в Java только в управляющем выражении цикла for. И в секции инициализации цикла, и в его управляющем выражении можно за¬писать несколько команд, разделенных запятыми; они будут обработаны после¬довательно.

Оператор «запятая» позволяет определить несколько переменных в цикле for, но все эти переменные должны принадлежать к одному типу:

//. control/CommaOperator.java

public class CommaOperator {

public static void main(String[] args) {

for(int i = 1. j = i + 10, i < 5. i++, j = i * 2) {

System out.printlnC'i = " + i + " j = " + j);

}

}

} /* Output: i = 1 j = 11 i = 2 j = 4 i = 3 j = 6 i = 4 j = 8 *///:-

Определение int в заголовке for относится как к i, так и к j. Инициализацон- ная часть может содержать любое количество определений переменных одного типа. Определение переменных в управляющих выражениях возможно только в цикле for. На другие команды выбора или циклов этот подход не распростра¬няется.

Синтаксис foreach

В Java SE5 появилась новая, более компактная форма for для перебора элемен¬тов массивов и контейнеров (см. далее). Эта упрощенная форма, называемая синтаксисом foreach, не требует ручного изменения служебной переменной для перебора последовательности объектов — цикл автоматически представляет очередной элемент.

Следующая программа создает массив float, после чего перебирает все его элементы:

//• control/ForEachFloat.java import java util.*,

public class ForEachFloat {

public static void main(String[] args) { Random rand = new Random(47), float f[] = new float[10], for(int i = 0; i < 10. i++)

f[i] = rand.nextFloatO, for(float x f)

System out println(x).

}

} /* Output

0.72711575

0.39982635

0.5309454

0.0534122

0.16020656

0.57799757

0.18847865

0.4170137

0.51660204

0.73734957 *///.-

Массив заполняется уже знакомым циклом for, потому что для его заполне¬ния должны использоваться индексы. Упрощенный синтаксис используется в следующей команде:

for(float X f)

Эта конструкция определяет переменную х типа float, после чего последова¬тельно присваивает ей элементы f.

Любой метод, возвращающий массив, может использоваться с данной разно¬видностью for. Например, класс String содержит метод toCharArray(), возвращаю¬щий массив char; следовательно, перебор символов строки может осуществлять¬ся так:

//: control/ForEachString.java

public class ForEachString {

public static void main(String[] args) {

for(char с : "An African Swallow".toCharArray() ) System.out.print(c + " ");

}

} /* Output:

An African Swallow *///.-

Как будет показано далее, «синтаксис foreach» также работает для любого объекта, поддерживающего интерфейс Iterable.

Многие команды for основаны на переборе серии целочисленных значений:

for (int i = 0; i < 100; i++)

В таких случаях «синтаксис foreach» работать не будет, если только вы пред¬варительно не создадите массив int. Для упрощения этой задачи я включил в библиотеку net.mindview.util.Range метод range(), который автоматически гене¬рирует соответствующий массив:

//: control/ForEachlnt.java

import static net.mindview.util.Range.*,

import static net.mindview.util Print.*;

public class ForEachlnt {

public static void main(String[] args) { for(int i : range(10)) // 0..9

 printnbCi + „ v).

printO;  

for(int i : range(5, 10)) // 5..9

 printnb(i + 

printO;  

for(int i : range(5. 20. 3)) // 5

 printnbCi + 

printO:  

}

} /* Output: 0 12 3 4 5 6 7 8 9 5 6 7 8 9 5 8 11 14 17 *///:-

Обратите внимание на использование printnb() вместо print(). Метод printnb() не выводит символ новой строки, что позовляет построить строку по фраг¬ментам.

return

Следующая группа ключевых слов обеспечивает безусловный переход, то есть передачу управления без проверки каких-либо условий. К их числу относятся команды return, break и continue, а также конструкция перехода по метке, анало¬гичная goto в других языках.

У ключевого слова return имеется два предназначения: оно указывает, какое значение возвращается методом (если только он не возвращает тип void), а так¬же используется для немедленного выхода из метода. Метод test() из предыду¬щего примера можно переписать так, чтобы он воспользовался новыми возмож¬ностями:

//: control/IfElse2.java

import static net.mindview.util.Print.*:

public class IfElse2 {

static int test(int testval. int target) { if(testval <@062> target)

return +1; else if(testval < target) return -1;

else

return 0; // Одинаковые значения

}

public static void main(String[] args) { prmt(test(10. 5)); print(test(5. 10)): print(test(5. 5));

}

} /* Output: 1 -1 0

В данном случае секция else не нужна, поскольку работа метода не продол¬жается после выполнения инструкции return.

Если метод, возвращающий void, не содержит команды return, такая команда неявно выполняется в конце метода. Тем не менее, если метод возвращает лю¬бой тип, кроме void, проследите за тем, чтобы каждая логическая ветвь возвра¬щала конкретное значение.

break и continue

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

Следующая программа показывает пример использования команд break и con¬tinue внутри циклов for и while:

//: control/BreakAndContinue.java // Применение ключевых слов break и continue import static net.mindview.util.Range.*;

public class BreakAndContinue {

public static void main(String[] args) { for(int i = 0: i < 100; i++) {

if(i == 74) break; // Выход из цикла

if(i % 9 != 0) continue; // Следующая итерация

System.out print(i + " ");

}

System out.printlnO; // Использование foreach: for(int i : range(lOO)) {

if(i == 74) break; // Выход из цикла

if(i % 9 != 0) continue; // Следующая итерация

System.out.print(i + " ");

}

System.out.println(); int i = 0;

// "Бесконечный цикл": while(true) { i++;

int j = i * 27,

if(j == 1269) break; // Выход из цикла

if(i % 10 != 0) continue; 11 Возврат в начало цикла

System.out.print(i + " ");

}

}

} /* Output:

0 9 18 27 36 45 54 63 72 0 9 18 27 36 45 54 63 72 10 20 30 40 *///:-

В цикле for переменная i никогда не достигает значения 100 — команда break прерывает цикл, когда значение переменной становится равным 74. Обычно break используется только тогда, когда вы точно знаете, что условие выхода из цикла действительно достигнуто. Команда continue переводит исполнение в на¬чало цикла (и таким образом увеличивает значение i), когда i не делится без ос¬татка на 9. Если деление производится без остатка, значение выводится на эк¬ран.

Второй цикл for демонстрирует использование «синтаксиса foreach» с тем же результатом.

Последняя часть программы демонстрирует «бесконечный цикл», который теоретически должен исполняться вечно. Однако в теле цикла вызывается ко¬манда break, которая и завершает цикл. Команда continue переводит исполнение к началу цикла, и при этом остаток цикла не выполняется. (Таким образом, вы¬вод на экран в последнем цикле происходит только в том случае, если значе¬ние i делится на 10 без остатка.) Значение 0 выводится, так как 0 % 9 дает в ре¬зультате 0.

Вторая форма бесконечного цикла — for(;;). Компилятор реализует конст¬рукции while(true) и for(;;) одинаково, так что выбор является делом вкуса.

Нехорошая команда goto

Ключевое слово goto появилось одновременно с языками программирования. Действительно, безусловный переход заложил основы принятия решений в языке ассемблера: «если условие А, перейти туда, а иначе перейти сюда». Если вам доводилось читать код на ассемблере, который генерируют фактически все компиляторы, наверняка вы замечали многочисленные переходы, управ¬ляющие выполнением программы (компилятор Java производит свой собствен¬ный «ассемблерный» код, но последний выполняется виртуальной-машиной Java, а не аппаратным процессором).

Команда goto реализует безусловный переход на уровне исходного текста программы, и именно это обстоятельство принесло ей дурную славу. Если программа постоянно «прыгает» из одного места в другое, нет ли способа реор¬ганизовать ее код так, чтобы управление программой перестало быть таким «прыгучим»? Команда goto впала в настоящую немилость с опубликованием знаменитой статьи Эдгара Дейкстры «Команда GOTO вредна» (Goto considered harmful), их тех пор порицание команды goto стало чуть ли не спортом, а за¬щитники репутации многострадального оператора разбежались по укромным углам.

Как всегда в ситуациях такого рода, существует «золотая середина». Про¬блема состоит не в использовании goto вообще, но в злоупотреблении — все же иногда именно оператор goto позволяет лучше всего организовать управление программой.

1 Оригинал статьи Go То Statement considered harmful имеет постоянный адрес в Интернете: http:// www.acm.org/classics/oct95. — Примеч. ред.

Хотя слово goto зарезервировано в языке Java, оно там не используется; Java не имеет команды goto. Однако существует механизм, чем-то похожий на безус¬ловный переход и осуществляемый командами break и continue. Скорее, это способ прервать итерацию цикла, а не передать управление в другую точку про¬граммы. Причина его обсуждения вместе с goto состоит в том, что он использу¬ет тот же механизм — метки.

Метка представляет собой идентификатор с последующим двоеточием:

label 1•

Единственное место, где в Java метка может оказаться полезной, — прямо пе¬ред телом цикла. Причем никаких дополнительных команд между меткой и те¬лом цикла быть не должно. Причина помещения метки перед телом цикла мо¬жет быть лишь одна — вложение внутри цикла другого цикла или конструкции выбора. Обычные версии break и continue прерывают только текущий цикл, в то время как их версии с метками способны досрочно завершать циклы и пе¬редавать выполнение в точку, адресуемую меткой:

labell:

внешний-цикл {

внутренний-цикл { //.

break; // 1 // .

continue; // 2 //..

continue labell; // 3 //...

break labell; // 4

В первом случае (1) команда break прерывает выполнение внутреннего цикла, и управление переходит к внешнему циклу. Во втором случае (2) опера¬тор continue передает управление к началу внутреннего цикла. Но в третьем ва¬рианте (3) команда continue labell влечет выход из внутреннего и внешнего цик¬лов и возврат к метке labell. Далее выполнение цикла фактически продолжается, но с внешнего цикла. В четвертом случае (4) команда break labell также вызыва¬ет переход к метке labell, но на этот раз повторный вход в итерацию не проис¬ходит. Это действие останавливает выполнение обоих циклов. Пример использования цикла for с метками:

//: control/LabeledFor.java

// Цикл for с метками

import static net.mindview.util.Print.*;

public class LabeledFor {

public static void main(String[] args) { int i = 0;

outer- // Другие команды недопустимы for(; true ,) { // infinite loop

inner: // Другие команды недопустимы for(; i < 10; i++) {

printC'i = " + i);

if(i == 2) {

print("continue"); continue;

}

if(i == 3) {

printC'break");

i++; // В противном случае значение i

// не увеличивается break;

}

if(i - 7) {

printC'continue outer");

i++; // В противном случае значение i

// не увеличивается continue outer;

}

if(i == 8) {

printC'break outer"); break outer;

}

for(int k = 0; k < 5; k++) {• if (k == 3) {

printC'continue inner"); continue inner;

}

}

}

}

// Использовать break или continue // с метками здесь не разрешается

}

} /* Output: i = 0

continue inner i = 1

continue inner i = 2 continue i = 3 break i = 4

continue inner i = 5

continue inner i = 6

continue inner i = 7

continue outer i = 8

break outer *///:-

Заметьте, что оператор break завершает цикл for, вследствие этого выраже¬ние с инкрементом не выполняется до завершения очередного шага. Поэтому из-за пропуска операции инкремента в цикле переменная непосредственно уве¬личивается на единицу, когда i — 3. При выполнении условия i == 7 команда continue outer переводит выполнение на начало цикла; инкремент опять пропус¬кается, поэтому и в этом случае переменная увеличивается явно.

Без команды break outer программе не удалось бы покинуть внешний цикл из внутреннего цикла, так как команда break сама по себе завершает выполнение только текущего цикла (это справедливо и для continue).

Конечно, если завершение цикла также приводит к завершению работы ме¬тода, можно просто применить команду return.

Теперь рассмотрим пример, в котором используются команды break и con¬tinue с метками в цикле while:

//: control/LabeledWhile java

// Цикл while с метками

import static net mindview.util.Print.*;

public class LabeledWhile {

public static void main(String[] args) { int i = 0; outer:

while(true) {

print("Внешний цикл while"); while(true) { i++;

printC'i = " + i); if(i == 1) {

print("continue"); continue;

}

if(i == 3) {

print("continue outer"); continue outer;

}

if(i == 5) {

printC'break"); break,

}

if(i == 7) {

printC'break outer"); break outer;

}

}

}

}

} /* Output: Внешний цикл while i = 1 continue i = 2 i = 3

continue outer Внешний цикл while i = 4 i = 5 break

Внешний цикл while i = 6

i = 7

break outer

*///-

Те же правила верны и для цикла while:

• Обычная команда continue переводит исполнение к началу текущего внутреннего цикла, программа продолжает работу.

• Команда continue с меткой вызывает переход к метке и повторный вход в цикл, следующий прямо за этой меткой.

• Команда break завершает выполнение текущего цикла.

• Команда break с меткой завершает выполнение внутреннего цикла и цик¬ла, который находится после указанной метки.

Важно помнить, что единственная причина для существования меток в Ja¬va — наличие вложенных циклов и необходимость выхода по break и продолже¬ния по continue не только для внутренних, но и для внешних циклов.

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

switch

Команду switch часто называют командой выбора. С помощью конструкции switch осуществляется выбор из нескольких альтернатив, в зависимости от зна¬чения целочисленного выражения. Форма команды выглядит так:

switch(целочисленное-выражение) {

case целое-значение1 команда; break; case целое-значение2 : команда; break, case целое-значениеЗ : команда; break; case целое-значение4 • команда; break; case целое-значениеб : команда; break; // ..

default: оператор;

}

Целочисленное-выражение — выражение, в результате вычисления которого по¬лучается целое число. Команда switch сравнивает результат целочисленного-вы- ражения с каждым последующим целым-значением. Если обнаруживается совпа¬дение, исполняется соответствующая команда (простая или составная). Если же совпадения не находится, исполняется команда после ключевого слова default.

Нетрудно заметить, что каждая секция case заканчивается командой break, которая передает управление к концу команды switch. Такой синтаксис по¬строения конструкции switch считается стандартным, но команда break не явля¬ется строго обязательной. Если она отсутствует, при выходе из секции будет вы¬полняться код следующих секций case, пока в программе не встретится очеред¬ная команда break. Необходимость в подобном поведении возникает довольно редко, но опытному программисту оно может пригодиться. Заметьте, что по¬следняя секция default не содержит команды break; выполнение продолжается в конце конструкции switch, то есть там, где оно оказалось бы после вызова break. Впрочем, вы можете использовать break и в предложении default, без практической пользы, просто ради «единства стиля».

Команда switch обеспечивает компактный синтаксис реализации множест¬венного выбора (то есть выбора из нескольких путей выполнения программы), но для нее необходимо управляющее выражение, результатом которого являет¬ся целочисленное значение, такое как int или char. Если, например, критерием выбора является строка или вещественное число, то команда switch не подой¬дет. Придется использовать серию команд if-else.

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

//: control/VowelsAndConsonants.java // Демонстрация конструкции switch, import java.util.*,

import static net.mindview.util.Print *;

public class VowelsAndConsonants {

public static void main(String[] args) { Random rand = new Random(47); for(int i = 0: i < 100; i++) {

int с = rand.nextInt(26) + 'a'; printnb((char)c + ", " + с + ": "); switch(c) {

case 'a': case 'e': case * i": case 'о':

case 'u': рппи"гласная"); break;

case 'y':

case V: print ("Условно гласная"); break;

default: рппи"согласная");

}

}

}

} /* Output: y, 121: Условно гласная n, 110: согласная z, 122: согласная

b, 98: согласная

г, 114: согласная n, 110: согласная

у. 121: Условно гласная

д. 103: согласная

c. 99: согласная f, 102: согласная о, 111: гласная

w, 119: Условно гласная z. 122: согласная

*///:-

Так как метод Random.nextlnt(26) генерирует значение между 0 и 26, для по¬лучения символа нижнего регистра остается прибавить смещение 'а'. Символы в апострофах в секциях case также представляют собой целочисленные значе¬ния, используемые для сравнения.

Обратите внимание на «стопки» секций case, обеспечивающие возможность множественного сравнения для одной части кода. Будьте начеку и не забывайте добавлять команду break после каждой секции case, иначе программа просто пе¬рейдет к выполнению следующей секции case. В команде

int с = rand.nextInt(26) + 'а',

метод rand.nextlnt() выдает случайное число int от 0 до 25, к которому затем прибавляется значение 'а'. Это означает, что символ а автоматически преобразу¬ется к типу int для выполнения сложения.

Чтобы вывести с в символьном виде, его необходимо преобразовать к типу char; в противном случае значение будет выведено в числовом виде.

Резюме

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

Инициализация и завершение

В ходе компьютерной революции выяснилось, что основной причиной чрезмерных затрат в программировании является «небезопасное» программирование.

Основные проблемы с безопасностью относятся к инициализации и заверше¬нию. Очень многие ошибки при программировании на языке С обусловлены не¬верной инициализацией переменных. Это особенно часто происходит при рабо¬те с библиотеками, когда пользователи не знают, как нужно инициализировать компонент библиотеки, или забывают это сделать. Завершение — очень акту¬альная проблема;слишком легко забыть об элементе, когда вы закончили с ним работу и его дальнейшая судьба вас не волнует. В этом случае ресурсы, зани¬маемые элементом, не освобождаются, и в программе может возникнуть нехват¬ка ресурсов (прежде всего памяти).

В С++ появилось понятие конструктора — специального метода, который вызывается при создании нового объекта. Конструкторы используются и в Java; к тому же в Java есть сборщик мусора, который автоматически освобождает ре¬сурсы, когда объект перестает использоваться. В этой главе рассматриваются вопросы инициализации и завершения, а также их поддержка в Java.

Конструктор гарантирует инициализацию

Конечно, можно создать особый метод, назвать его initialize() и включить во все ваши классы. Имя метода подсказывает пользователю, что он должен вызвать этот метод, прежде чем работать с объектом. К сожалению, это означает, что пользователь должен постоянно помнить о необходимости вызова данного ме¬тода. В Java разработчик класса может в обязательном порядке выполнить инициализацию каждого объекта при помощи специального метода, называе¬мого конструктором. Если у класса имеется конструктор, Java автоматически

вызывает его при создании объекта, перед тем как пользователи смогут обра¬титься к этому объекту. Таким образом, инициализация объекта гарантирована.

Как должен называться конструктор? Здесь есть две тонкости. Во-первых, любое имя, которое вы используете, может быть задействовано при определе¬нии членов класса; так возникает потенциальный конфликт имен. Во-вторых, за вызов конструктора отвечает компилятор, поэтому он всегда должен знать, какой именно метод следует вызвать. Реализация конструктора в С++ кажется наиболее простым и логичным решением, поэтому оно использовано и в Java: имя конструктора совпадает с именем класса. Смысл такого решения очеви¬ден — именно такой метод способен автоматически вызываться при инициали¬зации.

Рассмотрим определение простого класса с конструктором:

//. initialization/SimpleConstructor.java

// Демонстрация простого конструктора

class Rock {

RockO { // Это и есть конструктор System.out print("Rock ");

}

}

public class SimpleConstructor {

public static void mainCString[] args) { for(int i = 0; i < 10. i++) new RockO,

}

}

} /* Output:

Rock Rock Rock Rock Rock Rock Rock Rock Rock Rock

*/// ~

Теперь при создании объекта:

new Rock( ),

выделяется память и вызывается конструктор. Тем самым гарантируется, tfro объект будет инициализирован, прежде чем программа сможет работать с ним.

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

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

// initialization/SimpleConstructor2 java

// Конструкторы могут получать аргументы

class Rock2 {

Rock2(int i) {

System.out.println("Rock " + i + " ");

}

}

public class SimpleConstructor2 {

public static void main(String[] args) { for(int i = 0; i < 8; i++) new Rock2(i).

}

} /* Output:

Rock 0 Rock 1 Rock 2 Rock 3 Rock 4 Rock 5 Rock 6 Rock 7

*///:-

В аргументах конструктора передаются параметры для инициализации объ¬екта. Например, если у класса Tree (дерево) имеется конструктор, который по¬лучает в качестве аргумента целое число, обозначающее высоту дерева, то объ¬екты Tree будут создаваться следующим образом:

Tree t = new Tree(12), // 12-метровое дерево

Если Tree(int) является единственным конструктором класса, то компилятор не позволит создавать объекты Tree каким-либо другим способом.

Конструкторы устраняют большой пласт проблем и упрощают чтение кода. В предыдущем фрагменте кода не встречаются явные вызовы метода, подобно¬го initialize(), который концептуально отделен от создания. В Java создание и инициализация являются неразделимыми понятиями — одно без другого не¬возможно.

Конструктор — не совсем обычный метод, так как у него отсутствует возвра¬щаемое значение. Это ощутимо отличается даже от случая с возвратом значе¬ния void, когда метод ничего не возвращает, но при этом все же можно заста¬вить его вернуть что-нибудь другое. Конструкторы не возвращают никогда и ничего (оператор new возвращает ссылку на вновь созданный объект, но сами конструкторы не имеют выходного значения). Если бы у них существовало воз¬вращаемое значение и его можно было бы выбирать, то компилятору пришлось бы как-то объяснять, что же делать с этим значением.

Перегрузка методов

Одним из важнейших аспектов любого языка программирования является ис¬пользование имен. Создавая объект, вы фактически присваиваете имя области памяти. Метод — имя для действия. Использование имен при описании систе¬мы упрощает ее понимание и модификацию. Работа программиста сродни ра¬боте писателя; в обоих случаях задача состоит в том, чтобы донести свою мысль до читателя.

Проблемы возникают при перенесении нюансов человеческого языка в язы¬ки программирования. Часто одно и то же слово имеет несколько разных значе¬ний — оно перегружено. Это полезно, особенно в отношении простых различий. Вы говорите «вымыть посуду», «вымыть машину» и «вымыть собаку». Было бы глупо вместо этого говорить «посудоМыть посуду», «машиноМыть машину» и «собакоМыть собаку» только для того, чтобы слушатель не утруждал себя выявлением разницы между этими действиями. Большинство человеческих языков несет избыточность, и даже при пропуске некоторых слов определить смысл не так сложно. Уникальные имена не обязательны — сказанное можно понять из контекста.

Большинство языков программирования (и в особенности С) требовали ис¬пользования уникальных имен для всех функций. Иначе говоря, программа не могла содержать функцию print() для распечатки целых чисел и одноимен¬ную функцию для вывода вещественных чисел — каждая функция должна была иметь уникальное имя.

В Java (и в С++) также существует другой фактор, который заставляет ис¬пользовать перегрузку имен методов: наличие конструкторов. Так как имя кон¬структора предопределено именем класса, оно может быть только единствен¬ным. Но что, если вы захотите создавать объекты разными способами? Допус¬тим, вы создаете класс с двумя вариантами инициализации: либо стандартно, либо на основании из некоторого файла. В этом случае необходимость двух конструкторов очевидна: один из них не имеет аргументов (конструктор по умолчаниюх, также называемый конструктором без аргументов (no-arg)), а другой получает в качестве аргумента строку с именем файла. Оба они явля¬ются полноценными конструкторами, и поэтому должны называться одинако¬во — именем класса. Здесь перегрузка методов (overloading) однозначно необхо¬дима, чтобы мы могли использовать методы с одинаковыми именами, но с раз¬ными аргументами . И хотя перегрузка методов обязательна только для конст¬рукторов, она удобна в принципе и может быть применена к любому методу.

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

//: initialization/Overloading.java // Демонстрация перегрузки конструкторов наряду // с перегрузкой обычных методов, import static net.mindview util Print *;

class Tree {

int height:

Tree О {

print("Сажаем росток"): height = 0;

}

Tree(int initialHeight) {

height = i niti alHeight: print("Создание нового дерева высотой " + height + " м."):

}

void infoO {

print("Дерево высотой " + height + " м."):

}

void info(String s) {

продолжение &

print(s + ": Дерево высотой " + height + " м.");

}

}

public class Overloading {

public static void main(String[] args) { for(int i = 0; i < 5; i++) { Tree t = new Tree(i); t.infoO:

t.info("Перегруженный метод");

}

// Перегруженный конструктор: new TreeO;

}

} /* Output:

Создание нового дерева высотой 0 м.

Дерево высотой 0 м.

Перегруженный метод: Дерево высотой 0 м.

Создание нового дерева высотой 1 м.

Дерево высотой 1 м.

Перегруженный метод: Дерево высотой 1 м.

Создание нового дерева высотой 2 м.

Дерево высотой 2 м.

Перегруженный метод: Дерево высотой 2 м.

Создание нового дерева высотой 3 м.

Дерево высотой 3 м.

Перегруженный метод: Дерево высотой 3 м.

Создание нового дерева высотой 4 м.

Дерево высотой 4 м.

Перегруженный метод: Дерево высотой 4 м.

Сажаем росток

*///:-

Объект Tree (дерево) может быть создан или в форме ростка (без аргумен¬тов), или в виде «взрослого растения» с некоторой высотой. Для этого в классе определяются два конструктора; один используется по умолчанию, а другой по¬лучает аргумент с высотой дерева.

Возможно, вы захотите вызывать метод info() несколькими способами. На¬пример, вызов с аргументом-строкой info(String) используется при необходимо¬сти вывода дополнительной информации, а вызов без аргументов info() — когда дополнений к сообщению метода не требуется. Было бы странно давать два раз¬ных имени методам, когда их схожесть столь очевидна. К счастью, перегрузка методов позволяет использовать одно и то же имя для обоих методов.

Различение перегруженных методов

Если у методов одинаковые имена, как Java узнает, какой именно из них вызы¬вается? Ответ прост: каждый перегруженный метод должен иметь уникальный список типов аргументов.

Если немного подумать, такой подход оказывается вполне логичным. Как еще различить два одноименных метода, если не по типу аргументов?

Даже разного порядка аргументов достаточно для того, чтобы методы счита¬лись разными (хотя описанный далее подход почти не используется, так как он усложняет сопровождение программного кода):

// initialization/OverloadingOrder.java // Перегрузка, основанная на порядке // следования аргументов import static net.mindview util Print.*;

public class OverloadingOrder {

static void f(String s, int i) {

print("String- " + s + ". int: " + i).

}

static void f(int i. String s) {

printCint. " + i + String: " + s):

}

public static void main(String[] args) { f("Сначала строка", 11); f(99. "Сначала число").

}

} /* Output

String Сначала строка, int: 11 int 99. String. Сначала число *///.-

Два метода f() имеют одинаковые аргументы с разным порядком следования, и это различие позволяет идентифицировать метод.

Перегрузка с примитивами

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

//: ini ti alizati on/Pri mi ti veOverloadi ng.java // Повышение примитивных типов и перегрузка, import static net mindview.util.Print.*;

public class PrimitiveOverloading {

void fl(char x) { printnb("fl(char)"); }'

void fKbyte x) { printnbCf l(byte)"). }

void fKshort x) { printnb("fl(short)"); }

void fl(int x) { printnbCfKint)"): }

void fKlong x) { printnD("fl(long)"); }

void fl(float x) { printnb("fl(float)"); }

void f1(double x) { printnb("fl(double)"); }

void f2(byte x) { printnb("f2(byte)"); }

void f2(short x) { printnb("f2(short)"'); }

void f2(int x) { printnb("f2(int)"); }

void f2(long x) { printnb("f2(long)"); }

void f2(float x) { printnb("f2(float)"); }

void f2(double x) { printnb("f2(double)"); }

void f3(short x) { printnb("f3(short)"); }

void f3(int x) { printnb("f3(int)")} void f3(long x) { printnb("f3(long)M); } void f3(float x) { printnb("f3(float)"); } void f3(double x) { printnb("f3(double)"); }

void f4(int x) { printnb("f4(int)"); } void f4(long x) { printnb("f4(long)"); } void f4(float x) { printnb("f4(float)"); } void f4(double x) { printnb("f4(double)"); }

void f5(long x) { printnb("f5(long)"); } void f5(float x) { printnb("f5(float)"); } void f5(double x) { printnb("f5(double)"); }

void f6(float x) { printnb("f6(float)"); } void f6(double x) { printnb("f6(double)"); }

void f7(double x) { printnb("f7(double)"); }

void testConstValО {

printnb("5: ");

fl(5);f2(5);f3(5);f4(5);f5(5).f6(5);f7(5);print();

}

void testCharO {

char x = 'x'; printnbC'char: ");

fl(x) ;f2(x) ;f3(x) ;f4(x) ;f5(x) ;f6(x) ;f7(x); print ();

}

void testByteO {

byte x = 0;

System.out.println("параметр типа byte:"); fl(x):f2(x);f3(x);f4(x);f5(x);f6(x);f7(x);

}

void testShortO {

short x = 0; printnb("short: ");

fl(x):f2(x):f3(x):f4(x);f5(x):f6(x);f7(x);print():

}

void testlntO {

int x = 0: printnbC'int: "):

fl(x) ;f2(x) ;f3(x) :f4(x) :f5(x) ;f6(x) ;f7(x); print ():

}

void testLongO {

long x = 0; printnbC'long:");

fl(x):f2(x):f3(x):f4(x):f5(x):f6(x):f7(x);print();

}

void testFloatO {

float x = 0:

System.out.pri nt1n("f1 oat:");

fl(x);f2(x);f3(x);f4(x);f5(x);f6(x);f7(x);print();

}

void testDoubleO {

double x = 0: printnb("double:"):

fl(x) ;f2(x) ;f3(x) ;f4(x) ;f5(x) ;f6(x) ;f7(x) ;print();

}

public static void main(String[] args) { PrimitiveOverloading p =

/new PrimitiveOverloadingO; p.testConstValО. p.testCharO; p.testByteО; p testShortO; p.testlntO; p.testLongO; p testFloatO; p.testDoubleO;

}

} /* Output:

5: fl(int) f2(int) f3(int) f4(int) f5(long) f6(float) f7(double) char: fl(char) f2(int) f3(int) f4(int) f5(long) f6(float) f7(double) byte: fl(byte) f2(byte) f3(short) f4(int) f5(long) f6(float) f7(double) short: fl(short) f2(short) f3(short) f4(int) f5(long) f6(float) f7(double) int: fl(int) f2(int) f3(int) f4(int) f5(long) f6(float) f7(double) long: fl(long) f2(long) f3(long) f4(long) f5(long) f6(float) f7(double) float: fl(float) f2(float) f3(float) f4(float) f5(float) f6(float) f7(double) double- fl(double) f2(double) f3(double) f4(double) f5(double) f6(double) f7(double) *///:-

Если вы рассмотрите результат работы программы, то увидите, что констан¬та 5 трактуется как int, поэтому если есть перегруженный метод, принимающий аргумент типа int, то он и используется. Во всех остальных случаях, если име¬ется тип данных, «меньший», чем требуется для существующего метода, то этот тип данных повышается соответственным образом. Только тип char ве¬дет себя несколько иначе по той причине, что, если метода с параметром char нет, этот тип приводится сразу к типу int, а не к промежуточным типам byte или short.

Что же произойдет, если ваш аргумент «больше», чем аргумент, требующий¬ся в перегруженном методе? Ответ можно найти в модификации рассмотрен¬ной программы:

//: с04:Demotion.java

// Понижение примитивов и перегрузка.

import com.bruceeckel.simpletest.*;

public class Demotion {

static Test monitor = new TestO;

void fl(char x) { System.out.println("fl(char)"); }

void fKbyte x) { System out.println("fl(byte)"), }

void f 1(short x) { System.out.printlnC'fKshort)"); }

void fl(int x) { System.out.printlnC'fKint)"); }

void fKlong x) { System.out.printlnC'f 1(long)"); }

void fKfloat x) { System.out.println("fl(float)"); }

void f 1(double x) { System.out printlnC'fKdouble)"); }

void f2(char x) { System.out.println("f2(char)"); } void f2(byte x) { System.out.println("f2(byte)"); } void f2(short x) { System.out.println("f2(short)"). } void f2(int x) { System.out println("f2(int)"): } void f2(long x) ♦{ System.out.println("f2( 1 ong)"); }

void f2(float x) { System.out.println("f2(float)"); } продолжение &

124 Глава 5 • Инициализация и завершение

System out println("f3(char)"), System out.pri nt1n("f3(byte)"); { System.out.pri ntln("f3(short)") System out.println("f3(int)"), } System.out.pri nt1n("f3(1ong)");

System.out.println("f4(char)"); System.out.println("f4(byte)M). { System.out println("f4(short)") System.out.println("f4(int)"); }

System.out println("f5(char)"); System out println("f5(byte)"); { System.out.pri ntln("f5(short)")

void f3(char х) void f3(byte х) void f3(short x) void f3(int x) { void f3(long x)

void f4(char x) void f4(byte x) void f4(short x) void f4(int x) {

void f5(char x) void f5(byte x) void f5(short x)

void f6(char x) void f6(byte x)

void f7(char x)

void testDouble(

System out.pri nt1n("f6(char)"). System.out.pri ntln("f6(byte)"),

System.out.println("f7(char)"), }

{

double x = 0;

System.out printlnC'napaMeip типа double:"); fl(x);f2((float)x);f3((long)x).f4((int)x), f5((short)x);f6((byte)x);f7((char)x);

}

public static void main(String[] args) { Demotion p = new DemotionO; p.testDoubleO; monitor.expect(new StringC] {

"параметр типа double: "fl(double)", "f2(float)", "f3(long)", "f4(int)\ "f5(short)", "f6(byte)", "f7(char)M

} ///:-

Здесь методы требуют сужения типов данных. Если ваш аргумент «шире», необходимо явно привести его к нужному типу. В противном случае компиля¬тор выведет сообщение об ошибке.

Перегрузка по возвращаемым значениям

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

void f() {} int f() {}

Такой подход прекрасно сработает в ситуации, в которой компилятор может однозначно выбрать нужную версию метода, например: int х = f(). Однако воз¬вращаемое значение при вызове метода может быть проигнорировано; это часто называется вызовом метода для получения побочного эффекта, так как метод вызывается не для естественного результата, а для каких-то других целей. До¬пустим, метод вызывается следующим способом:

f():

Как здесь Java определит, какая из версий метода f() должна выполняться? И поймет ли читатель программы, что происходит при этом вызове? Именно из-за подобных проблем перегруженные методы не разрешается различать по возвращаемым значениям.

Конструкторы по умолчанию

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

//• initialization/DefaultConstructor.java class Bird {}

public class DefaultConstructor {

public static void main(String[] args) {

Bird b = new BirdO. // по умолчанию!

}

} ///- Строка

new BirdO;

создает новый объект и вызывает конструктор по умолчанию, хотя последний и не был явно определен в классе. Без него не существовало бы метода для по¬строения объекта класса из данного примера. Но если вы уже определили неко¬торый конструктор (или несколько конструкторов, с аргументами или без), компилятор не будет генерировать конструктор по умолчанию:

//: initi alizati on/NoSynthesi s.java

class Bird2 {

Bird2(int i) {} Bird2(double d) {}

}

public class NoSynthesis {

public static void main(String[] args) {

//! Bird2 b = new Bird2(); // Нет конструктора по умолчанию! Bird2 Ь2 = new Bird2(l); Bird2 ЬЗ = new Bird2(1.0);

}

Теперь при попытке выполнения new Bird2() компилятор заявит, что не мо¬жет найти конструктор, подходящий по описанию. Получается так: если опре¬деления конструкторов отсутствуют, компилятор скажет: «Хотя бы один конст¬руктор необходим, позвольте создать его за вас». Если же вы записываете конструктор явно, компилятор говорит: «Вы написали конструктор, а следова¬тельно, знаете, что вам нужно; й если вы создали конструктор по умолчанию, значит, он вам и не нужен».

Ключевое слово this

Если у вас есть два объекта одинакового типа с именами а и Ь, вы, возможно, за¬интересуетесь, каким образом производится вызов метода peel() для обоих объ¬ектов:

//: initialization/BananaPeel.java

class Banana { voi'd peel (int i ){/*...*/} }

public class BananaPeel {

public static void main(String[] args) {

Banana a = new BananaO, b = new BananaO;

a. peel(l);

b. peel(2);

}

} ///:-

Если существует только один метод с именем peel(), как этот метод узнает, для какого объекта он вызывается — а или Ь?

Чтобы программа могла записываться в объектно-ориентированном стиле, основанном на «отправке сообщений объектам», компилятор выполняет для вас некоторую тайную работу. При вызове метода peel() передается скрытый первый аргумент — не что иное, как ссылка на используемый объект. Таким об¬разом, вызовы указанного метода на самом деле можно представитьткак:

Banana.рееКаЛ);

Banana.peel(b,2);

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

Предположим, во время выполнения метода вы хотели бы получить ссылку на текущий объект. Так как эта ссылка передается компилятором скрытно, идентификатора для нее не существует. Но для решения этой задачи существу¬ет ключевое слово — this. Юночевое слово this может использоваться только внутри не-статического метода и предоставляет ссылку на объект, для которого был вызван метод. Обращаться с ней можно точно так же, как и с любой другой ссылкой на объект. Помните, что при вызове метода вашего класса из другого метода этого класса this вам не нужно; просто укажите имя метода. Текущая ссылка this будет автоматически использована в другом методе. Таким образом, продолжая сказанное:

//: initialization/Apricot.java public class Apricot {

void pickO { /* .. */ } void pit() { pickO; /*..*/} } ///:-

Внутри метода pit() можно использовать запись this.pick(), но в этом нет не¬обходимости . Компилятор сделает это автоматически. Ключевое слово this употребляется только в особых случаях, когда вам необходимо явно сослаться на текущий объект. Например, оно часто применяется для возврата ссылки на текущий объект в команде return:

//: initialization/Leaf.java // Simple use of the "this" keyword.

public class Leaf { int i = 0; Leaf increment О { i++;

return this;

}

void printO {

System, out. printlnC'i = " + i).

}

public static void main(String[] args) { Leaf x = new LeafO;

x.i ncrement().i ncrement() i ncrement().pri nt О;

}

} /* Output: i = 3 *///:-

Так как метод increment() возвращает ссылку на текущий объект посредст¬вом ключевого слова this, над одним и тем же объектом легко можно провести множество операций.

Ключевое слово this также может пригодиться для передачи текущего объек¬та другому методу:

//. initialization/PassingThis java

class Person {

public void eat(Apple apple) {

Apple peeled = apple.getPeeledО; System.out.println("Yummy");

}

}

class Peeler {

static Apple peel(Apple apple) {

продолжение &

// .. Снимаем кожуру

return apple; // Очищенное яблоко

}

}

class Apple {

Apple getPeeledO { return Peeler.peel(this); }

}

public class PassingThis {

public static void main(String[] args) { new Person О eat (new AppleO);

}

} /* Output: Yummy *///.-

Класс Apple вызывает Peeler.peel() — вспомогательный метод, который по ка¬кой-то причине должен быть оформлен как внешний по отношению к Apple (мо¬жет быть, он должен обслуживать несколько разных классов, и вы хотите избе¬жать дублирования кода). Для передачи текущего объекта внешнему методу используется ключевое слово this.

Вызов конструкторов из конструкторов

Если вы пишете для класса несколько конструкторов, иногда бывает удобно вызвать один конструктор из другого, чтобы избежать дублирования кода. Та¬кая операция проводится с использованием ключевого слова this.

Обычно при употреблении this подразумевается «этот объект» или «теку¬щий объект», и само слово является ссылкой на текущий объект. В конструкто¬ре ключевое слово this имеет другой смысл: при использовании его со списком аргументов вызывается конструктор, соответствующий данному списку. Таким образом, появляется возможность прямого вызова других конструкторов:

// initialization/Flower.java // Calling constructors with "this" import static net.mindview.util.Print.*;

public class Flower { int petal Count = 0; String s = "initial value"; Flower(int petals) {

petal Count = petals;

print("Конструктор с параметром int, petalCount= " + petal Count),

}

Flower(String ss) {

print("Конструктор с параметром String, s = " + ss); s = ss;

}

Flower(String s, int petals) { this(petals),

//! this(s); // Вызов другого конструктора запрещен! this.s = s; // Другое использование "this" print("Аргументы String и int");

}

FlowerО { thisC'hi". 47).

printC'KOHCTpyKTop по умолчанию (без аргументов)"),

}

void printPetalCountO { //! this(11), // Разрешается только в конструкторах! print("petal Count = " + petal Count + " s = "+ s);

}

public static void main(String[] args) { Flower x = new Flower(); x printPetalCountO,

}

} /* Output-

Конструктор с параметром int, petalCount= 47 Аргументы String и int Конструктор по умолчанию (без аргументов) petal Count = 47 s = hi */// ~

Конструктор Flower(String s, int petals) показывает, что при вызове одного конструктора через this вызывать второй запрещается. Вдобавок вызов другого конструктора должен быть первой выполняемой операцией, иначе компилятор выдаст сообщение об ошибке.

Пример демонстрирует еще один способ использования this. Так как имена аргумента s и поля данных класса s совпадают, возникает неоднозначность. Раз¬решить это затруднение можно при помощи конструкции this.s, однозначно оп¬ределяющей поле данных класса. Вы еще не раз встретите такой подход в раз¬личных Java-nporpaMMax, да и в этой книге он практикуется довольно часто.

Метод printPetalCountO показывает, что компилятор не разрешает вызывать конструктор из обычного метода; это разрешено только в конструкторах.

Значение ключевого слова static

Ключевое слово this поможет лучше понять, что же фактически означает объяв¬ление статического (static) метода. У таких методов не существует ссылки this. Вы не в состоянии вызывать нестатические методы из статических  (хотя об¬ратное позволено), и статические методы можно вызывать для имени класса, без каких-либо объектов. Статические методы отчасти напоминают глобальные функции языка С, но с некоторыми исключениями: глобальные функции не разрешены в Java, и создание статического метода внутри класса дает ему право на доступ к другим статическим методам и полям.

Некоторые люди утверждают, что статические методы со своей семантикой глобальной функции противоречат объектно-ориентированной парадигме; в слу¬чае использования статического метода вы не посылаете сообщение объекту, поскольку отсутствует ссылка this. Возможно, что это справедливый упрек, и если вы обнаружите, что используете слишком много статических методов, то стоит пересмотреть вашу стратегию разработки программ. Однако ключевое слово static полезно на практике, и в некоторых ситуациях они определенно не¬обходимы. Споры же о «чистоте ООП» лучше оставить теоретикам.

Очистка: финализация и сборка мусора

Программисты помнят и знают о важности инициализации, но часто забывают о значимости «приборки». Да и зачем, например, «прибирать» после использо¬вания обычной переменной int? Но при использовании программных библио¬тек «просто забыть» об объекте после завершения его работы не всегда безопасно. Конечно, в Java существует сборщик мусора, освобождающий память от не¬нужных объектов. Но представим себе необычную ситуацию. Предположим, что объект выделяет «специальную» память без использования оператора new. Сборщик мусора умеет освобождать память, выделенную new, но ему неизвестно, как следует очищать специфическую память объекта. Для таких ситуаций в Java предусмотрен метод finalize(), который вы можете определить в вашем классе. Вот как он должен работать: когда сборщик мусора готов освободить па¬мять, использованную вашим объектом, он для начала вызывает метод finali- ze(),H только после этого освобождает занимаемую объектом память. Таким об¬разом, метод finalize() позволяет выполнять завершающие действия во время работы сборщика мусора.

Все это может создать немало проблем для программистов, особенно для программистов на языке С++, так как они могут спутать метод finalize() с дест¬руктором языка С++ — функцией, всегда вызываемой перед разрушением объ¬екта. Но здесь очень важно понять разницу между Java и С++, поскольку в С++ объекты разрушаются всегда (в правильно написанной программе), в то время как в Java объекты удаляются сборщиком мусора не во всех случаях. Другими словами:

ВНИМАНИЕ : 

1. Ваши объекты могут быть и не переданы сборщику мусора.

2. Сборка мусора не является удалением.

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

Для чего нужен метод finalize()?

Итак, если метод finalize() не стоит использовать для проведения стандартных операций завершения, то для чего же он нужен? Запомните третье правило:

ВНИМАНИЕ  

3. Процесс сборки мусора относится только к памяти.

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

Но значит ли это, что если ваш объект содержит другие объекты, то в finalize() они должны явно удаляться? Нет — сборщик мусора займется ос¬вобождением памяти и удалением объектов вне зависимости от способа их соз¬дания. Получается, что использование метода finalize() ограничено особыми случаями, в которых ваш объект размещается в памяти необычным способом, не связанным с прямым созданием экземпляра. Но, если в Java все является объектом, как же тогда такие особые случаи происходят?

Похоже, что поддержка метода finalize() была введена в язык, чтобы сделать возможными операции с памятью в стиле С, с привлечением нестандартных ме¬ханизмов выделения памяти. Это может произойти в основном при использо¬вании методов, предоставляющих способ вызова He-Java-кода из программы на Java. С и С++ пока являются единственными поддерживаемыми языками, но, так как для них таких ограничений нет, в действительности программа Java может вызвать любую процедуру или функцию на любом языке. Во внешнем коде можно выделить память вызовом функций С, относящихся к семейству malloc(). Если не воспользоваться затем функцией free(), произойдет «утечка» памяти. Конечно, функция free() тоже принадлежит к С и С++, поэтому придет¬ся в методе finalize() провести вызов еще одного «внешнего» метода.

После прочтения этого абзаца у вас, скорее всего, сложилось мнение, что ме¬тод finalize() используется нечасто1. И правда, это не то место, где следует про¬водить рутинные операции очистки. Но где же тогда эти обычные операции бу¬дут уместны?

Очистка — ваш долг

Для очистки объекта его пользователю нужно вызвать соответствующий метод в той точке, где эти завершающие действия по откреплению и должны осущест¬вляться. Звучит просто, но немного протйворечит традиционным представле¬ниям о деструкторах С++. В этом языке все объекты должны уничтожаться. Ес¬ли объект С++ создается локально (то есть в стеке, что невозможно в Java), то удаление и вызов деструктора происходит у закрывающей фигурной скобки, ограничивающей область действия такого объекта. Если же объект создается оператором new (как в Java), то деструктор вызывается при выполнении про¬граммистом оператора С++ delete (не имеющего аналога в Java). А когда про¬граммист на С++ забывает вызвать оператор delete, деструктор не вызывается и происходит «утечка» памяти, к тому же остальные части объекта не проходят необходимой очистки. Такого рода ошибки очень сложно найти и устранить, и они являются веским доводом в пользу перехода с С++ на Java.

Java не позволяет создавать локальные объекты — все объекты должны быть результатом действия оператора new. Но в Java отсутствует аналог оператора delete, вызываемого для разрушения объекта, так как сборщик мусора и без того выполнит освобождение памяти. Значит, в несколько упрощенном изложении можно утверждать, что деструктор в Java отсутствует из-за присутствия сбор¬щика мусора. Но в процессе чтения книги вы еще не раз убедитесь, что наличие сборщика мусора не устраняет необходимости в деструкторах или их аналогах. (И никогда не стоит вызывать метод finalize() непосредственно, так как этот подход не решает проблему.) Если же потребуется провести какие-то завер¬шающие действия, отличные от освобождения памяти, все же придется явно вызвать подходящий метод, выполняющий функцию деструктора С++, но это уже не так удобно, как встроенный деструктор.

Помните, что ни сборка мусора, ни финализация не гарантированы. Если виртуальная машина Java (Java Virtual Machine, JVM) далека от критической точки расходования ресурсов, она не станет тратить время на освобождение па¬мяти с использованием сборки мусора.

Условие «готовности»

В общем, вы не должны полагаться на вызов метода finalize() — создавайте от¬дельные «функции очистки» и вызывайте их явно. Скорее всего, finalize() при¬годится только в особых ситуациях нестандартного освобождения памяти, с ко¬торыми большинство программистов никогда не сталкивается. Тем не менее существует очень интересное применение метода finalize(), не зависящее от того, вызывается ли он каждый раз или нет. Это проверка условия готовности объекта.

В той точке, где объект становится ненужным — там, где он готов к проведе¬нию очистки, — этот объект должен находиться в состоянии, когда освобождение закрепленной за ним памяти безопасно. Например, если объект представляет открытый файл, то он должен быть соответствующим образом закрыт, перед тем как его «приберет» сборщик мусора. Если какая-то часть объекта не будет готова к уничтожению, результатом станет ошибка в программе, которую затем очень сложно обнаружить. Ценность finalize() в том и состоит, что он позволяет вам обнаружить такие ошибки, даже если и не всегда вызывается. Единожды проведенная финализация явным образом укажет на ошибку, а это все, что вам нужно.

Простой пример использования данного подхода:

//• i ni ti ali zati on/Termi nati onCondi ti on java

// Использование finalize() для выявления объекта,

// не осуществившего необходимой финализации

class Book {

boolean checkedOut = false,

Book(boolean checkout) {

checkedOut = checkout,

}

void checklnO {

checkedOut = false;

}

public void finalizeO { if(checkedOut)

System out println("Ошибка. checkedOut"); // Обычно это делается так-

// Super.finalize(), // Вызов версии базового класса

}

}

public class TerminationCondition {

public static void main(String[] args) { Book novel = new Book(true); // Правильная очистка- novel.checkln(),

// Теряем ссылку, забыли про очистку new Book(true);

// Принудительная сборка мусора и финализация System gc().

}

} /* Output

Ошибка checkedOut

* ///•-

«Условие готовности» состоит в том, что все объекты Book должны быть «сняты с учета» перед предоставлением их в распоряжение сборщика мусора, но в методе main() программист ошибся и не отметил один из объектов Book. Если бы в методе finalize() не было проверки на условие «готовности», такую оплошность было бы очень сложно обнаружить.

Заметьте, что для проведения принудительной финализации был использо¬ван метод System.gc(). Но даже если бы его не было, с высокой степенью вероят¬ности можно сказать, что «утерянный» объект Book рано или поздно будет об¬наружен в процессе исполнения программы (в этом случае предполагается, что программе будет выделено столько памяти, сколько нужно, чтобы сборщик мусора приступил к своим обязанностям).

Обычно следует считать, что версия finalize() базового класса делает что-то важное, и вызывать ее в синтаксисе super, как показано в Book.finalize(). В дан¬ном примере вызов закомментирован, потому что он требует обработки исклю¬чений, а эта тема нами еще не рассматривалась.

Как работает сборщик мусора

Если ранее вы работали на языке программирования, в котором выделение мес¬та для объектов в куче было связано с большими издержками, то вы можете предположить, что и в Java механизм выделения памяти из кучи для всех дан¬ных (за исключением примитивов) также обходится слишком дорого. Однако в действительности использование сборщика мусора дает немалый эффект по ускорению создания объектов. Сначала это может звучать немного странно — освобождение памяти сказывается на ее выделении — но именно так работают некоторые JVM, и это значит, что резервирование места для объектов в куче Java не уступает по скорости выделению пространства в стеке в других языках.

Представтьте кучу языка С++ в виде лужайки, где каждый объект «застол¬бил» свой собственный участок. Позднее площадка освобождается для повтор¬ного использования. В некоторых виртуальных машинах Java куча выглядит совсем иначе; она скорее похоже на ленту конвейера, которая передвигается вперед при создании нового объекта. А это значит, что скорость выделения хра¬нилища для объекта оказывается весьма высокой. «Указатель кучи» просто пе¬редвигается вперед в «невозделанную» территорию, и по эффективности этот процесс близок к выделению памяти в стеке С++. (Конечно, учет выделенного пространства сопряжен с небольшими издержками, но их никоим образом нельзя сравнить с затратами, возникающими при поиске свободного блока в па¬мяти.)

Конечно, использование кучи в режиме «ленты конвейера» не может про¬должаться бесконечно, и рано или поздно память станет сильно фрагментиро- вана (что заметно снижает производительность), а затем и вовсе исчерпается. Как раз здесь в действие вступает сборщик мусора; во время своей работы он компактно размещает объекты кучи, как бы смещая «указатель кучи» ближе к началу «ленты», тем самым предотвращая фрагментацию памяти. Сборщик мусора реструктуризует внутреннее расположение объектов в памяти и по¬зволит получить высокоскоростную модель кучи для резервирования памяти.

Чтобы понять, как работает сборка мусора в Java, необходимо узнать, как устроены реализации сборщиков мусора (СМ) в других системах. Простой, но медленный механизм СМ называется подсчетом ссылок. С каждым объектом хранится счетчик ссылок на него, и всякий раз при присоединении новой ссыл¬ки к объекту этот счетчик увеличивается. Каждый раз при выходе ссылки из области действия или установке ее значения в null счетчик ссылок уменьша¬ется. Таким образом, подсчет ссылок создает небольшие, но постоянные из¬держки во время работы вашей программы. Сборщик мусора перебирает объект за объектом списка; обнаружив объект с нулевым счетчиком, он освобождает ресурсы, занимаемые этим объектом. Но существует одна проблема — если объ¬екты содержат циклические ссылки друг на друга, их счетчики ссылок не обну¬ляются, хотя на самом деле объекты уже являются «мусором». Обнаружение таких «циклических» групп является серьезной работой и отнимает у сборщика мусора достаточно времени. Подсчет ссылок часто используется для объясне¬ния принципов процесса сборки мусора, но, судя по всему, он не используется ни в одной из виртуальных машин Java.

В более быстрых схемах сборка мусора не зависит от подсчета ссылок. Вме¬сто этого она опирается на идею, что любой существующий объект прослежива¬ется до ссылки, находящейся в стеке или в статической памяти. Цепочка про¬верки проходит через несколько уровней объектов. Таким образом, если начать со стека и статического хранилища, мы обязательно доберемся до всех исполь¬зуемых объектов. Для каждой найденной ссылки надо взять объект, на который она указывает, и отследить все ссылки этого объекта; при этом выявляются другие объекты, на которые они указывают, и так далее, пока не будет провере¬на вся инфраструктура ссылок, берущая начало в стеке и статической памяти. Каждый объект, обнаруженный в ходе поиска, все еще используется в системе. Заметьте, что проблемы циклических ссылок не существует — такие ссылки просто не обнаруживаются, и поэтому становятся добычей сборщика мусора ав¬томатически.

В описанном здесь подходе работает адаптивный механизм сбора мусора, при котором JVM обращается с найденными используемыми объектами соглас¬но определенному варианту действий. Один из таких вариантов называется ос- тановить-и-копировать. Смысл термина понятен: работа программы временно приостанавливается (эта схема не поддерживает сборку мусора в фоновом ре¬жиме). Затем все найденные «живые» (используемые) объекты копируются из одной кучи в другую, а «мусор» остается в первой. При копировании объек¬тов в новую кучу они размещаются в виде компактной непрерывной цепочки, высвобождая пространство в куче {и позволяя удовлетворять заказ на новое хранилище простым перемещением указателя).

Конечно, когда объект перемещается из одного места в другое, все ссылки, указывающие на него, должны быть изменены. Ссылки в стеке или в статиче¬ском хранилище переопределяются сразу, но могут быть и другие ссылки на этот объект, которые исправляются позже, во время очередного «прохода». Исправление происходит по мере нахождения ссылок.

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

Второй вопрос — копирование. Как только программа перейдет в фазу ста¬бильной работы, она обычно либо становится «безотходной», либо производит совсем немного «мусора». Несмотря на это, копирующий сборщик все равно не перестанет копировать память из одного места в другое, что расточительно. Не¬которые JVM определяют, что новых «отходов» не появляется, и переключаются на другую схему («адаптивная» часть). Эта схема называется пометить-и-уб¬рать (удалить), и именно на ней работали ранние версии виртуальных машин фирмы Sun. Для повсеместного использования вариант «пометить-и-убрать» чересчур медлителен, но, когда известно, что нового «мусора» мало или вообще нет, он выполняется быстро.

Схема «пометить-и-убрать» использует ту же логику — проверка начинается со стека и статического хранилища, после чего постепенно обнаруживаются все ссылки на «живые» объекты. Однако каждый раз при нахождении объект поме¬чается флагом, но еще продолжает существование. «Уборка» происходит только после завершения процесса проверки и пометки. Все «мертвые» объекты при этом удаляются. Но копирования не происходит, и если сборщик решит «упа¬ковать» фрагментированную кучу, то делается это перемещением объектов внут¬ри нее.

Идея «остановиться-и-копировать» несовместима с фоновым процессом сборки мусора; в начале уборки программа останавливается. В литературе фир¬мы Sun можно найти немало заявлений о том, что сборка мусора является фо¬новым процессом с низким приоритетом, но оказывается, что реализации в та¬ком виде (по крайней мере в первых реализациях виртуальной машины Sun) в действительности не существует. Вместо этого сборщик мусора от Sun начи¬нал выполнение только при нехватке памяти. Схема «пометить-и-убрать» так¬же требует остановки программы.

Как упоминалось ранее, в описываемой здесь виртуальной машине память выделяется большими блоками. При создании большого объекта ему выделяет¬ся собственный блок. Строгая реализация схемы «остановиться-и-копировать» требует, чтобы каждый используемый объект из исходной кучи копировался в новую кучу перед освобождением памяти старой кучи, что сопряжено с боль¬шими перемещениями памяти. При работе с блоками памяти СМ использует незанятые блоки для копирования по мере их накопления. У каждого блока имеется счетчик поколений, следящий за использованием блока. В обычной си¬туации «упаковываются» только те блоки, которые были созданы после послед¬ней сборки мусора; для всех остальных блоков значение счетчика увеличивает¬ся при создании внешних ссылок. Такой подход годится для стандартной ситуации — создания множества временных объектов с коротким сроком жизни. Периодически производится полная очистка — большие блоки не копируются (только наращиваются их счетчики), но блоки с маленькими объектами копи¬руются и «упаковываются». Виртуальная машина постоянно следит за эффек¬тивностью сборки мусора и, если она становится неэффективной, потому что в программе остались только долгоживущие объекты, переключается на схему «пометить-и-убрать». Аналогично JVM следит за успешностью схемы «поме¬тить-и-убрать», и, когда куча становится излишне фрагментированной, СМ пе¬реключается обратно к схеме «остановиться-и-копировать». Это и есть адап¬тивный механизм.

Существуют и другие способы ускорения работы в JVM. Наиболее важ¬ные — это действия загрузчика и то, что называется компиляцией «на лету» (Just-In-Time, JIT). Компилятор JIT частично или полностью конвертирует программу в «родной» машинный код, благодаря чему последний не нуждается в обработке виртуальной машиной и может выполняться гораздо быстрее. При загрузке класса (обычно это происходит при первом создании объекта этого класса) система находит файл .class, и байт-код из этого файла переносится в память. В этот момент можно просто провести компиляцию JIT для кода класса, но такой подход имеет два недостатка: во-первых, это займет чуть больше времени, что вместе с жизненным циклом программы может серьезно отразиться на производительности. Во-вторых, увеличивается размер исполняемого файла (байт-код занимает гораздо меньше места в сравнении с расширенным кодом JIT), что может привести к подкачке памяти, и это тоже замедлит программу. Альтернативная схема отложенного вычисления подразумевает, что код JIT компилируется только тогда, когда это станет необходимо. Иначе говоря, код, который никогда не исполняется, не компилируется JIT. Новая технология Java HotSpot, встроенная в последние версии JDK, делает это похожим образом с применением последовательной оптимизации кода при каждом еговыполне¬нии. Таким образом, чем чаще выполняется код, тем быстрее он работает.

Инициализация членов класса

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

void f() { int i;

i++. // Ошибка - переменная i не инициализирована

}

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

Если примитивный тип является полем класса, то и способ обращения с ним несколько иной. Как было показано в главе 2, каждому примитивному полю класса гарантированно присваивается значение по умолчанию. Следующая про¬грамма подтверждает этот факт и выводит значения:

//. initialization/InitialValues java

// Вывод начальных значений, присваиваемых по умолчанию

import static net mindview util print *;

public class InitialValues { boolean t; char c, byte b; short s: int i;

float f; double d,

Начальное значение"). " + t);

+ с + + b); + s); + i);

+ 1): + f).

+ d).

+ reference).

InitialValues reference; void printlnitialValuesO { printC'Tnn данных print("boolean printC'char print("byte printCshort printC'int print("long print("float print("double print("reference

public static void main(String[] args) {

InitialValues iv = new InitialValuesO.

iv.printlnitialValuesO;

/* Тут возможен следующий вариант-

new InitialValuesO printlnitialValuesO; */

} /* Output- Тип'данных boolean char byte short int long float double reference *///-

Начальное значение

false [ ]

0

0

0

0

0.0

0.0

null

Присмотритесь — даже если значения явно не указываются, они автоматиче¬ски инициализируются. (Символьной переменной char присваивается значение ноль, которое отображается в виде пробела.) По крайней мере, нет опасности случайного использования неинициализированной переменной.

Если ссылка на объект, определямая внутри класса, не связывается с новым объектом, то ей автоматически присваивается специальное значение null (клю¬чевое слово Java).

Явная инициализация

Что делать, если вам понадобится придать переменной начальное значение? Проще всего сделать это прямым присваиванием этой переменной значения в точке ее объявления в классе. (Заметьте, что в С++ такое действие запрещено, хотя его постоянно пытаются выполнить новички.) В следующем примере по¬лям уже знакомого класса InitialValues присвоены начальные значения:

//• initialization/InitialValues2.java

// Явное определение начальных значений переменных

public class Ini ti alValues2 {

boolean bool = true; char ch = 'x'; byte b = 47; short s = Oxff; int i = 999; long Ing = 1, float f = 3.14f; double d = 3.14159; } ///:-

Аналогичным образом можно инициализировать и не-примитивные типы. Если Depth является классом, вы можете добавить переменную и инициализи¬ровать ее следующим образом:

//: initialization/Measurement.java class Depth {}

public class Measurement { Depth d = new DepthO; // ... } ///:-

Если вы попытаетесь использовать ссылку d, которой не задано начальное значение, произойдет ошибка времени исполнения, называемая исключением (исключения подробно описываются в главе 10).

Начальное значение даже может задаваться вызовом метода:

II: initialization/Methodlnit.java public class Methodlnit { int i = f(); int f() { return 11; } } ///:-

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

II: initialization/Methodlnit2.java public class MethodInit2 { int i = f(), int j = g(i); int f() { return 11; } int g(int n) { return n * 10; } } ///-

а так нет:

II: initialization/MethodInit3 java public class MethodInit3 { //! int j = g(i); 11 Недопустимая опережающая ссылка int i = f(); int f() { return 11; } int g(int n) { return n * 10, } } ///

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

Описанный подход инициализации очень прост и прямолинеен. У него есть ограничение — все объекты типа InitialValues получат одни и те же начальные значения. Иногда вам нужно именно это, но в других ситуациях необходима большая гибкость.

Инициализация конструктором

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

//: initialization/Counter.java public class Counter { int i;

Counter О {i=7, } // .. } ///-

переменной i сначала будет присвоено значение 0, а затем уже 7. Это верно для всех примитивных типов и ссылок на объекты, включая те, которым задаются явные значения в точке определения. По этим причинам компилятор не пыта¬ется заставить вас инициализировать элементы в конструкторе, или в ином определенном месте, или перед их использованием — инициализация и так га¬рантирована.

Порядок инициализации

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

II- initialization/OrderOflnitialization java // Демонстрирует порядок инициализации import static net mindview util.Print.*,

// При вызове конструктора для создания объекта // Window выводится сообщение class Window {

Window(int marker) { print("Window(" + marker + ")"); }

}

class House { Window wl = new Window(l); // Перед конструктором HouseO {

// Показывает, что выполняется конструктор print(" HouseO"):

w3 = new Window(33), 11 Повторная инициализация w3

}

Window w2 = new Window(2). // После конструктора

void f() { printC'fO"). }

Window w3 = new Window(3). // В конце

}

public class OrderOflnitialization { public static void main(String[] args) { House h = new HouseO;

h fO. // Показывает, что объект сконструирован

}

} /* Output Window(l) Window(2) Window(3) HouseO Window(33) fO */// -

В классе House определения объектов Window намеренно разбросаны, чтобы доказать, что все они инициализируются перед выполнением конструктора или каким-то другим действием. Вдобавок ссылка w3 заново проходит инициализа¬цию в конструкторе.

Из результатов программы видно, что ссылка w3 минует двойную инициали¬зацию, перед вызовом конструктора и во время него. (Первый объект теряется, и со временем его уничтожит сборщик мусора.) Поначалу это может показаться неэффективным, но такой подход гарантирует верную инициализацию — что произошло бы, если бы в классе был определен перегруженный конструктор, который не инициализировал бы ссылку w3, а она при этом не получала бы зна¬чения по умолчанию?

Инициализация статических данных

Данные статических полей всегда существуют в единственном экземпляре, не¬зависимо от количества созданных объектов. Ключевое слово static не может применяться к локальным-переменным, только к полям. Если статическое поле относится к примитивному типу, при отсутствии явной инициализации ему присваивается значение по умолчанию. Если это ссылка на объект, то ей при¬сваивается значение null.

Если вы хотите провести инициализацию в месте определения, она выгля¬дит точно так же, как и у нестатических членов класса.

Следующий пример помогает понять, когда инициализируется статическая память:

//• initialization/StaticInitialization.java // Указание значений по умолчанию в определении класса, import static net mindview util Print *;

class Bowl {

Bowl(int marker) {

print("Bowl(" + marker + ")"),

}

void fl(int marker) {

print("fl(" + marker + ")");

}

}

class Table {

static Bowl bowll = new Bowl(l); TableO {

print("Table()"); bowl 2.f1(1),

}

void f2(iлt marker) {

print("f2(" + marker + ")");

}

static Bowl bowl2 = new Bowl(2);

}

class Cupboard {

Bowl bowl3 = new Bowl(3), static Bowl bowl4 = new Bowl(4). CupboardO {

printC'CupboardO"). bowl4 fl(2).

}

void f3(int marker) {

print(Mf3(" + marker + ")"),

}

static Bowl bowl5 = new Bowl(5);

}

public class Staticlnitialization {

public static void main(String[] args) {

print ("Создание нового объекта Cupboard в mainO"), new CupboardO;

print ("Создание нового объекта Cupboard в mainO"), new CupboardO; table.f2(l). cupboard f3(l),

}

static Table table = new TableO, static Cupboard cupboard = new CupboardO; } /* Output; Bowl(1) Bowl(2) TableO fl(l) Bowl(4) Bowl(5) Bowl(3) Cupboard() fl(2)

Создание нового объекта Cupboard в mainO Bowl(3) CupboardO fl(2)

Создание нового объекта Cupboard в mainO Bowl(3)

CupboardО fl(2) f2(l) f3(l) *///:-

Класс Bowl позволяет проследить за процессом создания классов; классы Table и Cupboard содержат определения статических объектов Bowl. Заметьте, что в классе Cupboard создается нестатическая переменная Bowl bowl3, хотя все ос¬тальные определения — статические.

Из выходных данных программы видно, что статическая инициализация происходит только в случае необходимости. Если вы не создаете объектов Table и никогда не обращаетесь к Table.bowll или Table.bowl2, то, соответственно, не будет и объектов static Bowl bowll и static Bowl bowl2. Они инициализируются только при создании первого объекта Table (или при первом обращении к стати¬ческим данным). После этого статические объекты повторно не переопределя¬ются.

Сначала инициализируются static-члены, если они еще не были проинициали- зированы, и только затем нестатические объекты. Доказательство справедливости этого утверждения легко найти в результате работы программы. Для выполне¬ния main() (а это статический метод!) загружается класс Staticlnitialization; за¬тем инициализируются статические *поля table и cupboard, вследствие чего за¬гружаются эти классы. И так как все они содержат статические объекты Bowl, загружается класс Bowl. Таким образом, все классы программы загружаются до начала main(). Впрочем, эта ситуация нетипична, поскольку в рядовой про¬грамме не все поля объявляются как статические, как в данном примере.

Неплохо теперь обобщить знания о процессе создания объекта. Для примера возьмем класс с именем Dog:

• Хотя ключевое слово static и не используется явно, конструктор в дейст¬вительности является статическим методом. При создании первого объ¬екта типа Dog или при первом вызове статического метода-обращения к статическому полю класса Dog, интерпретатор Java должен найти класс Dog.class. Поиск осуществляется в стандартных каталогах, перечислен¬ных в переменной окружения С LASS PATH.

• После загрузки файла Dog.class (с созданием особого объекта Class, о кото¬ром мы узнаем позже) производится инициализация статических элемен¬тов. Таким образом, инициализация статических членов проводится только один раз, при первой загрузке объекта Class.

• При создании нового объекта конструкцией new Dog() для начала выделя¬ется блок памяти, достаточный для хранения объекта Dog в куче.

• Выделенная память заполняется нулями, при этом все примитивные поля объекта Dog автоматически инициализируются значениями по умолчанию (ноль для чисел, его эквиваленты для типов boolean и char, null для ссылок).

• Выполняются все действия по инициализации, происходящие в точке оп¬ределения полей класса.

• Выполняются конструкторы. Как вы узнаете из главы 7, на этом этапе выполняется довольно большая часть работы, особенно при использова¬нии наследования.

Явная инициализация статических членов

Язык Java позволяет сгруппировать несколько действий по инициализации объектов static в специальной конструкции, называемой статическим блоком. Выглядит это примерно так:

// initialization/Spoon.java public class Spoon { static int i, static {

i = 47,

}

} ///:-

Похоже на определение метода, но на самом деле мы видим лишь ключевое слово static с последующим блоком кода. Этот код, как и остальная инициали¬зация static, выполняется только один раз: при первом создании объекта этого класса или при первом обращении к статическим членам этого класса (даже если объект класса никогда не создается). Например:

II- initialization/ExplicitStatic java

II Явная инициализация с использованием конструкции "static"

import static net.mindview util.Print *;

class Cup {

CupCint marker) {

print("Cup(" + marker + ")"),

}

void f(int marker) {

printC'fC + marker + ")"),

}

}

class Cups {

static Cup cupl, static Cup cup2; static {

cupl = new Cup(l); cup2 = new Cup(2);

}

Cups О {

printCCupsO");

}

}

public class ExplicitStatic {

public static void main(String[] args) { printCInside mainO"); Cups.cupl.f(99); II (1)

}

II static Cups cupsl = new CupsO; II (2) II static Cups cups2 = new CupsO, II (2)

} /* Output: Inside mainO Cup(l) Cup(2) f (99) *///:-

Статический инициализатор класса Cups выполняется либо при обращении к статическому объекту cl в строке с пометкой (1), либо если строка (1) заком¬ментирована — в строках (2) после снятия комментариев. Если же и строка (1), и строки (2) закомментированы, static-инициализация класса Cups никогда не выполнится. Также неважно, будут ли исполнены одна или обе строки (2) программы — static-инициализация все равно выполняется только один раз.

Инициализация нестатических данных экземпляра

В Java имеется сходный синтаксис для инициализации нестатических перемен¬ных для каждого объекта. Вот пример: .

// initialization/Mugs java // "Инициализация экземпляра" в Java import static net mindview util.Print *.

class Mug {

Mug(int marker) {

print("Mug(" + marker + ")");

}

void f(int marker) {

print("f(" + marker + ")");

}

}

public class Mugs { Mug mugl.

Mug mug2, {

mugl = new Mug(l); mug2 = new Mug(2).

print("mugl & mug2 инициализированы");

}

Mugs О {

print("Mugs()");

}

Mugs(int i) {

print("Mugs(int)"),

}

public static void main(String[] args) { printC'B методе mainO"); new Mugs О,

print("new Mugs О завершено"), new Mugs(l),

print("new Mugs(l) завершено");

}

} /* Output. В методе mainO Mug(l)

Mug(2) продолжение &

mugl & mug2 инициализированы Mugs О

new Mugs О завершено

Mug(1)

Mug(2)

mugl & mug2 инициализированы Mugs(int)

new Mugs(l) завершено *///:-

Секция инициализации экземпляра

{

mugl = new Mug(l);

mug2 = new Mug(2);

print("mugl & mug2 инициализированы");

}

выглядит в точности так же, как и конструкция static-инициализации, разве что ключевое слово static отсутствует. Такой синтаксис необходим для поддержки инициализации анонимных внутренних классов (см. главу 9), но он также гаран¬тирует, что некоторые операции будут выполнены независимо от того, какой именно конструктор был вызван в программе. Из результатов видно, что сек¬ция инициализации экземпляра выполняется раньше любых конструкторов.

Инициализация массивов

Массив представляет собой последовательность объектов или примитивов, от¬носящихся к одному типу, обозначаемую одним идентификатором. Массивы определяются и используются с помощью оператора индексирования [ ]. Чтобы объявить массив, вы просто. указываете вслед за типом пустые квадратные скобки:

int[] al;

Квадратные скобки также могут размещаться после идентификатора, эф¬фект будет точно таким же:

int al[];

Это соответствует ожиданиям программистов на С и С++, привыкших к та¬кому синтаксису. Впрочем, первый стиль, пожалуй, выглядит более логично — он сразу дает понять, что имеется в виду «массив значений типа int». Он и бу¬дет использоваться в книге.

Компилятор не позволяет указать точный размер массива. Вспомните, что говорилось ранее о ссылках. Все, что у вас сейчас есть, — это ссылка на массив, для которого еще не было выделено памяти. Чтобы резервировать память для массива, необходимо записать некоторое выражение инициализации. Для мас¬сивов такое выражение может находиться в любом месте программы, но суще¬ствует и особая разновидность выражений инициализации, используемая толь¬ко в точке объявления массива. Эта специальная инициализация выглядит как набор значений в фигурных скобках. Выделение памяти (эквивалентное дейст¬вию оператора new) в этом случае проводится компилятором. Например:

int[] al = { 1, 2. 3, 4. 5 }.

Но зачем тогда вообще нужно определять ссылку на массив без самого мас¬сива?

int[] а2,

Во-первых, в Java можно присвоить один массив другому, записав сле¬дующее:

а2 = al,

В данном случае вы на самом деле копируете ссылку, как показано в при¬мере:

// initialization/ArraysOfPrimitives.java

// Массивы простейших типов.

import static net mindview.util.Print.*;

public class ArraysOfPrimitives {

public static void main(String[] args) { int:: al = { 1. 2, 3. 4, 5 }: int[] a2; a2 = al.

for(int i = 0; i < a2.length, i++)

a2[i] = a2[i] + 1; for(int i = 0; i < al.length; i++)

print("al[" + i +"]=" + al[i]);

}

} /* Output: al[0] = 2 al[l] = 3 al[2] = 4 al[3] = 5 al[4] = 6 *///:-

Массив al инициализируется набором значений, в то время как массив а2 — нет; присваивание по ссылке а2 присваивается позже — в данном случае при¬сваивается другой массив.

Все массивы (как массивы примитивов, так и массивы объектов) содержат поле> которое можно прочитать (но не изменить!) для получения количества элементов в массиве. Это поле называется length. Так как в массивах Java, С и С++ .нумерация элементов начинается с нуля, последнему элементу массива соответстйует индекс length—1. При выходе за границы массива С и С++ не пре¬пятствуют «прогулкам в памяти» программы, что часто приводит к печальным последствиям. Но Java защищает вас от таких проблем — при выходе за рамки массива происходит ошибка времени исполнения (исключение, тема главы 10) .

А если во время написания программы вы не знаете, сколько элементов вам понадобится в новом массиве? Тогда просто используйте new для создания его элементов. В следующем примере new работает, хотя в программе создается массив примитивных типов (оператор new неприменим для создания примити¬вов вне массива):

//: initialization/ArrayNew.java // Создание массивов оператором new. import java util.*;

import static net.mindview util.Print *;

public class ArrayNew {

public static void main(String[] args) { int[] a.

Random rand = new Random(47); a = new int[rand.nextlnt(20)]; print("Длина a = " + a length), print(Arrays.toString(a));

}

} /* Output- Длина a = 18

[0, 0. 0, 0. 0, 0, 0, 0, 0, 0. 0, 0. 0. 0. 0, 0. 0. 0] *///-

Размер массива выбирается случайным образом, с использованием метода Random.nextlnt(), генерирующего число от нуля до переданного в качестве аргу¬мента значения. Так как размер массива случаен, очевидно, что создание масси¬ва происходит во время исполнения программы. Вдобавок, результат работы программы позволяет убедиться в том, что элементы массивов простейших ти¬пов автоматически инициализируются «пустыми» значениями. (Для чисел и символов это ноль, а для логического типа boolean — false.)

Метод Arrays.toString(), входящий в стандартную библиотеку java.util, выдает печатную версию одномерного массива.

Конечно, в данном примере массив можно определить и инициализировать в одной строке:

int[] а = new int[rand.nextlnt(20)],

Если возможно, рекомендуется использовать именно такую форму записи. При создании массива непримитивных объектов вы фактически создаете массив ссылок. Для примера возьмем класс-обертку Integer, который является именно классом, а не примитивом:

//: initialization/ArrayClassObj java // Создание массива непримитивных объектов import java.util.*;

import static net.mindview util.Print.*,

public class ArrayClassObj {

' public static void main(String[] args) { Random rand = new Random(47); Integer[] a = new Integer[rand.nextlnt(20)]; print("длина a = " + a.length); for(int i = 0; i < a.length; i++)

a[i] = rand.nextlnt(500); // Автоматическая упаковка

print(Arrays.toString(a)),

}

} /* Output (пример) длина а = 18

[55. 193. 361. 461. 429. 368, 200. 22. 207, 288. 128. 51. 89. 309. 278. 498, 361. 20] *///-

Здесь даже после вызова new для создания массива

Integer[] а = new Integer[rand nextlnt(20)];

мы имеем лишь массив из ссылок — до тех пор, пока каждая ссылка не будет инициализирована новым объектом Integer (в данном случае это делается по¬средством автоупаковки):

a[i] = rand.nextlnt(500);

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

Массивы объектов также можно инициализировать списком в фигурных скобках. Существует две формы синтаксиса:

//• i niti ali zati on/ArrayInit java // Инициализация массивов import java.util *;

public class Arraylnit {

public static void main(String[] args) { Integer[] a = {

new Integer(l), new Integer(2), 3, // Autoboxing

}:

Integer[] b = new Integer[]{ new Integer(1), new Integer(2), 3. // Автоматическая упаковка

}:

System. out. pri ntl n (Arrays. toStri ng (a)); System.out println(Arrays.toString(b));

}

} /* Output- [1. 2. 3] [1. 2. 3] *///:-

В обоих случаях завершающая запятая в списке инициализаторов не обяза¬тельна (она всего лишь упрощает ведение длинных списков).

Первая форма полезна, но она более ограничена, поскольку может использо¬ваться только в точке определения массива. Вторая форма может использовать¬ся везде, даже внутри вызова метода.

Списки аргументов переменной длины

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

Такой список способен содержать неизвестное заранее количество аргументов неизвестного типа. Так как абсолютно все классы унаследованы от общего кор¬невого класса Object, можно создать метод, принимающий в качестве аргумента массив Object, и вызывать его следующим образом:

//. initialization/VarArgs.java

// Использование синтаксиса массивов

// для получения переменного списка параметров.

class А { int i; }

public class VarArgs {

static void printArray(Object[] args) { for(Object obj • args)

System.out print(obj + " "); System out printlnO,

}

public static void main(String[] args) { printArray(new Object[]{

new Integer(47), new Float(3 14), new Double(ll.ll)

}).

printArray(new 0bject[]{"pa3", "два", "три" }); pri ntArray (new Object[]{new AO, new AO, new AO});

}

} /* Output: (Sample) 47 3.14 11.11 раз два три

А@1а46еЗО А@3е25а5 A@19821f *///:-

Видно, что метод print() принимает массив объектов типа Object, перебирает его элементы и выводит их. Классы из стандартной библиотеки Java при печати выводят осмысленную информацию, однако объекты классов в данном примере выводят имя класса, затем символ @ и несколько шестнадцатеричных цифр. Таким образом, по умолчанию класс выводит имя и адрес объекта (если только вы не переопределите в классе метод toString() — см. далее).

До выхода Java SE5 переменные списки аргументов реализовывались имен¬но так. В Java SE5 эта долгожданная возможность наконец-то была добавлена в язык — теперь для определения переменного списка аргументов может ис¬пользоваться многоточие, как видно в определении метода printArray:

//: initialization/NewVarArgs java // Создание списков аргументов переменной длины // с использованием синтаксиса массивов.

public class NewVarArgs {

static void printArray(Object... args) { for(Object obj • args)

System out.print(obj + " "); System.out.printlnO;

}

public static void main(String[] args) {

// Можно передать отдельные элементы printArray(new Integer(47), new Float(3 14), new Doubledl. 11));

printArray(47. 3 14F, 11.11): printArray("раз", "два", "три"): printArray(new АО. new АО, new АО): // Или массив.

printArray((Object[])new Integer[]{ 1, 2, 3, 4 }); printArray(), // Пустой список тоже возможен

}

} /* Output- (lb% match) 47 3 14 11.11 47 3 14 11.11 раз два три

A@lbab50a А@сЗс749 A@150bd4d 12 3 4 *///•-

Резюме

Такой сложный механизм инициализации, как конструктор, показывает, на¬сколько важное внимание в языке уделяется инициализации. Когда Бьерн Страуструп разрабатывал С++, в первую очередь он обратил внимание на то, что низкая продуктивность С связана с плохо продуманной инициализацией, которой была обусловлена значительная доля ошибок. Аналогичные проблемы возникают и при некорректной финализации. Так как конструкторы позволяют гарантировать соответствующие инициализацию и завершающие действия по очистке (компилятор не позволит создать объект без вызова конструктора), тем самым обеспечивается полная управляемость и защищенность программы.

В языке С++ уничтожение объектов играет очень важную роль, потому что объекты, созданные оператором new, должны быть соответствующим образом разрушены. В Java память автоматически освобождается сборщиком мусора, и аналоги деструкторов обычно не нужны. В таких случаях сборщик мусора Java значительно упрощает процесс программирования и к тому же добавляет так необходимую безопасность при освобождении ресурсов. Некоторые сбор¬щики мусора могут проводить завершающие действия даже с такими ресурсами, как графические и файловые дескрипторы. Однако сборщики мусора добавля¬ют издержки во время выполнения программы, которые пока трудно реально оценить из-за сложившейся исторически медлительности интерпретаторов Ja¬va. И хотя в последнее время язык Java намного улучшил свою производитель¬ность, проблема его «задумчивости» все-таки наложила свой отпечаток на воз¬можность решения языком некоторого класса задач.

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

Управление доступом

Важнейшим фактором объектно-ориентированной разработки является отде­ление переменных составляющих от постоянных.

Это особенно важно для библиотек. Пользователь {программист-клиент) библиотеки зависит от неизменности некоторого аспекта вашего кода. С другой стороны, создатель библиотеки должен обладать достаточной свободой для проведения изменений и улучшений, но при этом изменения не должны нару­шить работоспособность клиентского кода.

Желанная цель может быть достигнута определенными договоренностями: Например, программист библиотеки соглашается не удалять уже существую­щие методы класса, потому что это может нарушить структуру кода программи- ста-клиента. В то же время обратная проблема гораздо острее. Например, как создатель библиотеки узнает, какие из полей данных используются программи- стом-клиентом? Это же относится и к методам, являющимся только частью реализации класса, то есть не предназначенным для прямого использования программистом-клиентом. А если создателю библиотеки понадобится удалить старую реализацию и заменить ее новой? Изменение любого из полей класса может нарушить работу кода программиста-клиента. Выходит, у создателя биб­лиотеки «связаны руки», и он вообще ничего не вправе менять.

Для решения проблемы в Java определены спецификаторы доступа (access specifiers), при помощи которых создатель библиотеки указывает, что доступно программисту-клиенту, а что нет. Уровни доступа (от полного до минимально­го) задаются следующими ключевыми словами: public, protected, доступ в преде­лах пакета (не имеет ключевого слова) и private. Из предыдущего абзаца может возникнуть впечатление, что создателю библиотеки лучше всего хранить все как можно «секретнее», а открывать только те методы, которые, по вашему мнению, должен использовать программист-клиент. И это абсолютно верно, хотя и выглядит непривычно для людей, чьи программы на других языках (в особенности это касается С) «привыкли» к остутствию ограничений. К кон­цу этой главы вы наглядно убедитесь в полезности механизма контроля досту­па в Java.

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

Пакет как библиотечный модуль

Пакет содержит группу классов, объединенных в одном пространстве имен.

Например, в стандартную поставку Java входит служебная библиотека, оформленная в виде пространства имен java,util. Один из классов java.util назы­вается ArrayList. Чтобы использовать класс в программе, можно использовать его полное имя java. util. Array List. Впрочем, полные имена слишком громоздки, поэтому в программе удобнее использовать ключевое слово import. Если вы со­бираетесь использовать всего один класс, его можно указать прямо в директиве import:

// access/Singlelmport.java

import java.util ArrayList,

public class Singlelmport {

public static void main(String[] args) {

ArrayList list = new java.util .ArrayListO:

}

} ///.-

Теперь к классу ArrayList можно обращаться без указания полного имени, но другие классы пакета java.util останутся недоступными. Чтобы импортировать все классы, укажите * вместо имени класса, как это делается почти во всех при­мерах книги:

import java.util *,

Механизм импортирования обеспечивает возможность управления про­странствами имен. Имена членов классов изолируются друг от друга. Метод f() класса А не конфликтует с методом f() с таким же определением (списком аргу­ментов) класса В. А как насчет имен классов? Предположим, что класс Stack создается на компьютере, где кем-то другим уже был определен класс с именем Stack. Потенциальные конфликты имен — основная причина, по которой так важны управление пространствами имен в Java и возможность создания уни­кальных идентификаторов для всех классов.

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

Файл с исходным текстом на Java часто называют компилируемым модулем. Имя каждого компилируемого модуля должно завершаться суффиксом .java, а внутри него может находиться открытый (public) класс, имеющий то же имя, что и файл (с заглавной буквы, но без расширения .java). Любой компилируе­мый модуль может содержать не более одного открытого класса, иначе компи­лятор сообщит об ошибке. Остальные классы модуля, если они там есть, скры­ты от окружающего мира — они не являются открытыми (public) и считаются «вспомогательными» по отношению к главному открытому классу.

В результате компиляции для каждого класса, определенного в файле .java, создается класс с тем же именемГно с расширением .class. Таким образом, при компиляции нескольких файлов .java может появиться целый ряд файлов с рас­ширением .class. Если вы программировали на компилируемом языке, то, на­верное, привыкли к тому, что компилятор генерирует промежуточные файлы (обычно с расширением OBJ), которые затем объединяются компоновщиком для получения исполняемого файла или библиотеки. Java работает не так. Ра­бочая программа представляет собой набор однородных файлов .class, которые объединяются в пакет и сжимаются в файл JAR (утилитой Java jar). Интерпре­татор Java отвечает за поиск, загрузку и интерпретацию^[1] этих файлов.

Библиотека также является набором файлов с классами. В каждом файле имеется один public-класс с любым количеством классов, не имеющих специфи­катора public. Если вы хотите объявить, что все эти компоненты (хранящиеся в отдельных файлах .java и .class) связаны друг с другом, воспользуйтесь клю­чевым словом package.

Директива package должна находиться в первой незакомментированной строке файла. Так, команда.

package access;

означает, что данный компилируемый модуль входит в библиотеку с именем access. Иначе говоря, вы указываете, что открытый класс в этом компилируе­мом модуле принадлежит имени mypackage и, если кто-то захочет использовать его, ему придется полностью записать или имя класса, или директиву import с access (конструкция, указанная выше). Заметьте, что по правилам Java имена пакетов записываются только строчными буквами.

Предположим, файл называется MyClass.java. Он может содержать один и только один открытый класс (public), причем последний должен называться MyClass (с учетом регистра символов):

//: access/mypackage/MyClass java

package access.mypackage;

public class MyClass { 11 ...

} ///.-

Если теперь кто-то захочет использовать MyClass или любые другие откры­тые классы из пакета access, ему придется использовать ключевое слово import, чтобы имена из access стали доступными. Возможен и другой вариант — запи­сать полное имя класса:

//: access/QualifiedMyClass java

public class QualifiedMyClass {

public static void main(String[] args) { access mypackage.MyClass m =

new access mypackage.MyClass();

}

} ///:-

С ключевым словом import решение выглядит гораздо аккуратнее:

II: access/ImportedMyClass.java

import access.mypackage.*:

public class ImportedMyClass {

public static void main(String[] args) { MyClass m = new MyClassO:

}

} ///

Ключевые слова package и import позволяют разработчику библиотеки орга­низовать логическое деление глобального пространства имен, предотвращаю­щее конфликты имен независимо от того, сколько людей подключится к Ин­тернету и начнет писать свои классы на Java.

Создание уникальных имен пакетов

Вы можете заметить, что, поскольку пакет на самом деле никогда не «упаковы­вается» в единый файл, он может состоять из множества файлов .class, что спо­собно привести к беспорядку, может, даже хаосу. Для предотвращения пробле­мы логично было бы разместить все файлы .class конкретного пакета в одном каталоге, то есть воспользоваться иерархической структурой файловой систе­мы. Это первый способ решения проблемы нагромождения файлов в Java; о втором вы узнаете при описании утилиты jar.

Размещение файлов пакета в отдельном каталоге решает две другие задачи: создание уникальных имен пакетов и обнаружение классов, потерянных в «деб­рях» структуры каталогов. Как было упомянуто в главе 2, проблема решается «кодированием» пути файла в имени пакета. По общепринятой схеме первая часть имени пакета должна состоять из перевернутого доменного имени разра­ботчика класса. Так как доменные имена Интернета уникальны, соблюдение этого правила обеспечит уникальность имен пакетов и предотвратит конфликты. (Только если ваше доменное имя не достанется кому-то другому, кто начнет писать программы на Java под тем же именем.) Конечно, если у вас нет собст­венного доменного имени, для создания уникальных имен пакетов придется придумать комбинацию с малой вероятностью повторения (скажем, имя и фа­милия). Если же вы решите публиковать свои программы на Java, стоит немно­го потратиться на получение собственного доменного имени.

Вторая составляющая — преобразование имени пакета в каталог на диске компьютера. Если программе во время исполнения понадобится загрузить файл .class (что делается динамически, в точке, где программа создает объект определенного класса, или при запросе доступа к статическим членам класса), она может найти каталог, в котором располагается файл .class.

Интерпретатор Java действует по следующей схеме. Сначала он проверяет переменную окружения CLASSPATH (ее значение задается операционной сис­темой, а иногда программой установки Java или инструментарием Java). CLASSPATH содержит список из одного или нескольких каталогов, используе­мых в качестве корневых при поиске файлов .class. Начиная с этих корневых каталогов, интерпретатор берет имя пакета и заменяет точки на слеши для по­лучения полного пути (таким образом, директива package foo.bar.baz преобразу­ется в foo\bar\baz, foo/bar/baz или что-то еще в зависимости от вашей операци­онной системы). Затем полученное имя присоединяется к различным эле­ментам CLASSPATH. В указанных местах ведется поиск файлов .class, имена которых совпадают с именем создаваемого программой класса. (Поиск также ведется в стандартных каталогах, определяемых местонахождением интерпре­татора Java.)

Чтобы понять все сказанное, рассмотрим мое доменное имя: MindView.net. Обращая его, получаем уникальное глобальное имя для моих классов: net. mindview. (Расширения com, edu, org и другие в пакетах Java прежде записыва­лись в верхнем регистре, но начиная с версии Java 2 имена пакетов записывают­ся только строчными буквами.) Если потребуется создать библиотеку с именем simple, я получаю следующее имя пакета:

package net.mindview.simple,

Теперь полученное имя пакета можно использовать в качестве объединяю­щего пространства имен для следующих двух файлов:

//: net/mindview/simple/Vector.java

// Создание пакета

package net mindview simple,

public class Vector { public VectorО {

System out printlnCnet mindview.simple.Vector");

}

} ///:-

Как упоминалось ранее, директива package должна находиться в первой строке исходного кода. Второй файл выглядит почти так же:

//: net/mindview/simple/List java

// Создание пакета

package net.mindview simple;

public class List { public ListO {

System.out pri ntln("net.mi ndvi ew.si mple.Li st"),

}

} /// ~

В моей системе оба файла находятся в следующем подкаталоге:

С \DOC\JavaT\net\mindview\simple

Если вы посмотрите на файлы, то увидите имя пакета net.mindview.simple, но что с первой частью пути? О ней позаботится переменная окружения CLAS- SPATH, которая на моей машине выглядит следующим образом:

CLASSPATH= ,D \JAVA\LIB,C.\D0C\JavaT

Как видите, CLASSPATH может содержать несколько альтернативных пу­тей для поиска.

Однако для файлов JAR используется другой подход. Вы должны записать имя файла JAR в переменной CLASSPATH, не ограничиваясь указанием пути к месту его расположения. Таким образом, для файла JAR с именем grape.jar пе­ременная окружения должна выглядеть так:

CLASSPATH= .D.\JAVAXLIB.С \flavors\grape.jar

После настройки CLASSPATH следующий файл можно разместить в любом каталоге:

// access/LibTest.java // Uses the library, import net mindview simple *;

public class LibTest {

public static void main(String[] args) { Vector v = new VectorO. List 1 = new ListO:

}

} /* Output:

net.mindview simple Vector net mindview.simple List */// -

Когда компилятор встречает директиву import для библиотеки simple, он на­чинает поиск в каталогах, перечисленных в переменной CLASSPATH, найдет каталог net/mindview/simple, а затем переходит к поиску компилированных фай­лов с подходящими именами (Vector.class для класса Vector и List.class для клас­са List). Заметьте, что как классы, так и необходимые методы классов Vector и List должны быть объявлены со спецификатором public.

Конфликты имен

Что происходит при импортировании конструкцией * двух библиотек, имею­щих в своем составе идентичные имена? Предположим, программа содержит следующие директивы:

import net mindview simple *; import java.util.*,

Так как пакет java,util.* тоже содержит класс с именем Vector, это может при­вести к потенциальному конфликту. Но, пока вы не начнете писать код, вызы­вающий конфликты, все будет в порядке — и это хорошо, поскольку иначе вам пришлось бы тратить лишние усилия на предотвращение конфликтов, которых на самом деле нет.

Конфликт действительно произойдет при попытке создать Vector:

Vector v = new VectorO;

К какому из классов Vector относится эта команда? Этого не знают ни ком­пилятор, ни читатель программы. Поэтому компилятор выдаст сообщение об ошибке и заставит явно указать нужное имя. Например, если мне понадобит­ся стандартный класс Java с именем Vector, я должен явно указать этот факт:

java util.Vector v = new java util,VectorO;

Данная команда (вместе с переменной окружения CLASSPATH) полностью описывает местоположение конкретного класса Vector, поэтому директива im­port java.util.* становится избыточной (по крайней мере, если вам не потребуют­ся другие классы из этого пакета).

Пользовательские библиотеки

Полученные знания позволяют вам создавать собственные библиотеки, сокра­щающие или полностью исключающие дублирование кода. Для примера можно взять уже знакомый псевдоним для метода System.out.println(), сокращающий количество вводимых символов. Его можно включить в класс Print:

//. net/mi ndvi ew/uti1/Print.java

// Методы-печати, которые могут использоваться

// без спецификаторов, благодаря конструкции

// Java SE5 static import.

package net.mindview.util;

import java.io *;

public class Print {

// Печать с переводом строки: public static void print(Object obj) { System.out.println(obj);

}

// Перевод строки: public static void print(S) { System, out. pri ntlnO;

}

// Печать без перевода строки public static void printnb(Object obj) { System.out.print(obj);

}

// Новая конструкция Java SE5 printfO (из языка С): public static PrintStream printf(String format, Object... args) {

return System.out.printf(format, args):

}

} ///-

Новые методы могут использоваться для вывода любых данных с новой строки (print()) или в текущей строке (printnb()).

Как нетрудно предположить, файл должен располагаться в одном из катало­гов, указанных в переменной окружения CLASSPATH, по пути net/mindview. После компиляции методы static print() и printnb() могут использоваться где угодно, для чего в программу достаточно включить директиву import static:

//: access/PrintTest.java

// Использование статических методов печати из Print.java. import static net.mindview.util.Print.*:

public class PrintTest {

public static void main(String[] args) {

print("Теперь это стало возможно!"): print(lOO): print(lOOL), print(3.14159):

}

} /* Output:

Теперь это стало возможно! 100 100

3.14159

Теперь, когда бы вы ни придумали новый интересный инструмент, вы всегда можете добавить его в свою библиотеку.

Предостережение при работе с пакетами

Помните, что создание пакета всегда неявно сопряжено с определением струк­туры каталогов. Пакет обязан находиться в одноименном каталоге, который, в свою очередь, определяется содержимым переменной CLASSPATH. Первые эксперименты с ключевым словом package могут оказаться неудачными, пока вы твердо не усвоите правило «имя пакета — его каталог». Иначе компилятор будет выводить множество сообщений о загадочных ошибках выполнения, о не­возможности найти класс, который находится рядом в этом же каталоге. Если у вас возникают такие ошибки, попробуйте закомментировать директиву package; если все запустится, вы знаете, где искать причины.

Спецификаторы доступа Java

В Java спецификаторы доступа public, protected и private располагаются перед определением членов классов — как полей, так и методов. Каждый специфика­тор доступа управляет только одним отдельным определением.

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

Доступ в пределах пакета

Во всех рассмотренных ранее примерах спецификаторы доступа не указыва­лись. Доступ по умолчанию не имеет ключевого слова, но часто его называют доступом в пределах пакета (package access, иногда «дружественным»). Это зна­чит, что член класса доступен для всех остальных классов текущего пакета, но для классов за пределами пакета он воспринимается как приватный (private). Так как компилируемый модуль — файл — может принадлежать лишь одному пакету, все классы одного компилируемого модуля автоматически открыты друг для друга в границах пакета.

Доступ в пределах пакета позволяет группировать взаимосвязанные классы в одном пакете, чтобы они могли легко взаимодействовать друг с другом. Раз­мещая классы в одном пакете, вы берете код пакета под полный контроль. Та­ким образом, только принадлежащий вам код будет обладать пакетным досту­пом к другому, принадлежащему вам же коду — и это вполне логично. Можно сказать, что доступ в пределах пакета и является основной причиной для груп­пировки классов в пакетах. Во многих языках определения в классах организу­ются совершенно произвольным образом, но в Java придется привыкать к более жесткой логике структуры. Вдобавок классы, которые не должны иметь доступ к классам текущего пакета, следует просто исключить из этого пакета.

Класс сам определяет, кому разрешен доступ к его членам. Не существует волшебного способа «ворваться» внутрь него. Код из другого пакета не может запросто обратиться к пакету и рассчитывать, что ему вдруг станут доступны все члены: protected,private и доступные в пакете. Получить доступ можно лишь несколькими «законными» способами:

•        Объявить член класса открытым (public), то есть доступным для кого угод­но и откуда угодно.

•        Сделать член доступным в пакете, не указывая другие спецификаторы доступа, и разместить другие классы в этом же пакете.

•        Как вы увидите в главе 7, где рассказывается о наследовании, производ­ный класс может получить доступ к защищенным (protected) членам ба­зового класса вместе с открытыми членами public (но не к приватцым членам private). Такой класс может пользоваться доступом в пределах па­кета только в том случае, если второй класс принадлежит тому же пакету (впрочем, пока на наследование и доступ protected можно не обращать внимания).

•        Предоставить «методы доступа», то есть методы для чтения и модифика­ции значения. С точки зрения ООП этот подход является предпочтитель­ным, и именно он используется в технологии JavaBeans.

public

При использовании ключевого слова public вы фактически объявляете, что сле­дующее за ним объявление члена класса доступно для всех, и прежде всего для клиентских программистов, использующих библиотеку. Предположим, вы оп­ределили пакет dessert, содержащий следующий компилируемый модуль:

// access/dessert/Cookie.java 11 Создание библиотеки, package access.dessert.

public class Cookie { public CookieO {

System.out.println("Конструктор Cookie");

}

void biteO { System out printlnCbite"); } } /// ~

Помните, что файл Cookie.java должен располагаться в подкаталоге dessert каталога с именем access (соответствующем данной главе книги), а последний должен быть включен в переменную CLASSPATH. Не стоит полагать, будто Java всегда начинает поиск с текущего каталога. Если вы не укажете символ . (точка) в переменной окружения CLASSPATH в качестве одного из путей по­иска, то Java и не заглянет в текущий каталог.

Если теперь написать программу, использующую класс Cookie:

// access/Dinner java // Использование библиотеки import access.dessert *;

public class Dinner {

public static void main(Stnng[] args) { Cookie x = new CookieO: //! x.biteO; // Обращение невозможно

}

} /* Output: Конструктор Cookie */// ~

то можно создать объект Cookie, поскольку конструктор этого класса объявлен открытым (public) и сам класс также объявлен как public. (Понятие открытого класса мы позднее рассмотрим чуть подробнее.) Тем не менее метод bite() этого класса недоступен в файле Dinner.java, поскольку доступ к нему предоставляет­ся только в пакете dessert. Так компилятор предотвращает неправильное ис­пользование методов.

Пакет по умолчанию

С другой стороны, следующий код работает, хотя на первый взгляд он вроде бы нарушает правила:

//• access/Cake java

// Обращение к классу из другого компилируемого модуля

class Cake {

public static void mainCString[] args) { Pie x = new PieO, x f():

}

} /* Output. Pie f() */// ~

Второй файл в том же каталоге:

//• access/Pie.java

// Другой класс

class Pie { void f() { System.out.pnntlnC'Pie.fO"): }

} ///:-

Вроде бы эти два файла не имеют ничего общего, и все же в классе Cake мож­но создать объект Pie и вызвать его метод f()! (Чтобы файлы компилировались, переменная CLASSPATH должна содержать символ точки.) Естественно было бы предположить, что класс Pie и метод f() имеют доступ в пределах пакета и поэтому закрыты для Cake. Они действительно обладают доступом в преде­лах пакета — здесь все верно. Однако их доступность в классе Cake.java объяс­няется тем, что они находятся в одном каталоге и не имеют явно заданного име­ни пакета. Java по умолчанию включает такие файлы в «пакет по умолчанию» для текущего каталога, поэтому они обладают доступом в пределах пакета к дру­гим файлам в этом каталоге.

private

Ключевое слово private означает, что доступ к члену класса не предоставляется никому, кроме методов этого класса. Другие классы того же пакета также не мо­гут обращаться к private-членам. На первый взгляд вы вроде бы изолируете класс даже от самого себя. С другой стороны, вполне вероятно, что пакет соз­дается целой группой разработчиков; в этом случае private позволяет изме­нять члены класса, не опасаясь, что это отразится на другом классе данного пакета.

Предлагаемый по умолчанию доступ в пределах пакета часто оказывается достаточен для сокрытия данных; напомню, что такой член класса недоступен пользователю пакета. Это удобно, так как обычно используется именно такой уровень доступа (даже в том случае, когда вы просто забудете добавить специ­фикатор доступа). Таким образом, доступ public чаще всего используется тогда, когда вы хотите сделать какие-либо члены класса доступными для программи- ста-клиента. Может показаться, что спецификатор доступа private применяется редко и можно обойтись и без него. Однако разумное применение private очень важно, особенно в условиях многопоточного программирования (см. далее).

Пример использования private:

II- access/IceCream.java

// Демонстрация ключевого слова private.

class Sundae {

private SundaeO {} static Sundae makeASundaeO { return new SundaeO;

}

}

public class IceCream {

public static void main(String[] args) { III Sundae x = new SundaeO; Sundae x = Sundae makeASundae();

}

} ///-

Перед вами пример ситуации, в которой private может быть очень полезен: предположим, вы хотите контролировать процесс создания объекта, не разре­шая посторонним вызывать конкретный конструктор (или любые конструкто­ры). В данном примере запрещается создавать объекты Sundae с помощью конст­руктора; вместо этого пользователь должен использовать метод makeASundae().

Все «вспомогательные» методы классов стоит объявить как private, чтобы предотвратить их случайные вызовы в пакете; тем самым вы фактически запре­щаете изменение поведения метода или его удаление.

То же верно и к private-полям внутри класса. Если только вы не собираетесь предоставить доступ пользователям к внутренней реализации (а это происхо­дит гораздо реже, чем можно себе представить), объявляйте все поля своих классов со спецификатором private.

protected

Чтобы понять смысл спецификатора доступа protected, необходимо немного за­бежать вперед. Сразу скажу, что понимание этого раздела не обязательно до знакомства с наследованием (глава 7). И все же для получения цельного пред­ставления здесь приводится описание protected и примеры его использования.

Ключевое слово protected тесно связано с понятием наследования, при кото­ром к уже существующему классу (называемому базовым классом) добавляются новые члены, причем исходная реализация остается неизменной. Также можно изменять поведение уже существующих членов класса. Для создания нового класса на базе существующего используется ключевое слово extends:

class Foo extends Bar {

Остальная часть реализации выглядит как обычно.

Если при создании нового пакета используется наследование от класса, на­ходящегося в другом пакете, новый класс получает доступ только к открытым (public) членам из исходного пакета. (Конечно, при наследовании в пределах одного пакета можно получить доступ ко всем членам с пакетным уровнем дос­тупа.) Иногда создателю базового класса необходимо предоставить доступ к конкретному методу производным классам, но закрыть его от всех остальных. Именно для этой задачи используется ключевое слово protected. Спецификатор protected также предоставляет доступ в пределах пакета — то есть члены с этим спецификатором доступны для других классов из того же пакета.

Интерфейс и реализация

Контроль над доступом часто называют сокрытием реализации. Помещение дан­ных и методов в классы в комбинации с сокрытием реализации часто называют инкапсуляцией. В результате появляется тип данных, обладающий характери­стиками и поведением.

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

Это подводит нас непосредственно ко второй причине — разделению интер­фейса и реализации. Если в программе использована определенная структура, но программисты-клиенты не могут получить доступ к ее членам, кроме от­правки сообщений риЬНс-интерфейсу, вы можете изменять все, что не объявле­но как public (члены с доступом в пределах пакета, protected и private), не нару­шая работоспособности изменений клиентского кода.

Для большей ясности при написании классов можно использовать такой стиль: сначала записываются открытые члены (public), затем следуют защищен­ные члены (protected), потом — с доступом в пределах пакета и наконец закры­тые члены (private). Преимущество такой схемы состоит в том, что при чтении исходного текста пользователь сначала видит то, что ему важно (открытые чле­ны, доступ к которым можно получить отовсюду), а затем останавливается при переходе к закрытым членам, являющимся частью внутренней реализации:

//. access/OrganizedByAccess.java public class OrganizedByAccess {

public void publO {

/*

*/ }

public void pub2() {

/*

*/ }

public void pub3() {

/*

. */ }

private void privlO

{ /* ■

*/

private void priv20

{ /* •

*/

private void priv30

{ /*

*/

private int i;

// ..

} III -

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

Доступ к классам

В Java с помощью спецификаторов доступа можно также указать, какие из клас­сов внутри библиотеки будут доступны для ее пользователей. Если вы хотите, чтобы класс был открыт программисту-клиенту, то добавляете ключевое слово public для класса в целом. При этом вы управляете даже самой возможностью создания объектов данного класса программистом-клиентом.

Для управления доступом к классу, спецификатор доступа записывается пе­ред ключевым словом class:

public class Widget {

Если ваша библиотека называется, например, access, то любой програм­мист-клиент сумеет обратиться извне к классу Widget:

import access Widget: или

import access *;

Впрочем, при этом действуют некоторые ограничения:

•        В каждом компилируемом модуле может существовать только один от­крытый (public) класс. Идея в том, что каждый компилируемый модуль содержит определенный открытый интерфейс и реализуется этим откры­тым классом. В модуле может содержаться произвольное количество вспомогательных классов с доступом в пределах пакета. Если в компили­руемом модуле определяется более одного открытого класса, компилятор выдаст сообщение об ошибке.

•        Имя открытого класса должно в точности совпадать с именем файла, в котором содержится компилируемый модуль, включая регистр симво­лов. Поэтому для класса Widget имя файла должно быть Widget.java, но никак не widget.java или WIDGET.java. В противном случае вы снова по­лучите сообщение об ошибке.

•        Компилируемый модуль может вообще не содержать открытых классов (хотя это и не типично). В этом случае файлу можно присвоить любое имя по вашему усмотрению. С другой стороны, выбор произвольного имени создаст трудности у тех людей, которые будут читать и сопровож­дать ваш код.

Допустим, в пакете access имеется класс, который всего лишь выполняет не­которые служебные операции для класса Widget или для любого другого ри- ЬИс-класса пакета. Конечно, вам не хочется возиться с созданием лишней доку­ментации для клиента; возможно, когда-нибудь вы просто измените структуру пакета, уберете этот вспомогательный класс и добавите новую реализацию. Но для этого нужно точно знать, что ни один программист-клиент не зависит от конкретной реализации библиотеки. Для этого вы просто опускаете ключе­вое слово public в определении класса; ведь в таком случае он ограничивается пакетным доступом, то есть может использоваться только в пределах своего пакета.

При создании класса с доступом в пределах пакета его поля все равно реко­мендуется помечать как private (всегда нужно по максимуму перекрывать дос­туп к полям класса), но методам стоит давать тот же уровень доступа, что имеет и сам класс (в пределах пакета). Класс с пакетным доступом обычно использу­ется только в своем пакете, и делать методы такого класса открытыми (public) стоит только при крайней необходимости — а о таких случаях вам сообщит компилятор.

Заметьте, что класс нельзя объявить как private (что сделает класс недоступ­ным для окружающих, использовать он сможет только «сам себя») или protected^[2]. Поэтому у вас есть лишь такой выбор при задании доступа к классу: в пределах пакета или открытый (public). Если вы хотите перекрыть доступ к классу для всех, объявите все его конструкторы со спецификатором private, соответственно, запретив кому бы то ни было создание объектов этого класса. Только вы сами, в статическом методе своего класса, сможете создавать такие объекты. Пример:

//. access/Lunch.java // Спецификаторы доступа для классов. // Использование конструкторов, объявленных private, // делает класс недоступным при создании объектов.

class Soupl {

private SouplО {}

// (1) Разрешаем создание объектов в статическом методе: public static Soupl makeSoupO { return new SouplO;

}

}

class Soup2 {

private Soup2() {}

// (2) Создаем один статический объект и // по требованию возвращаем ссылку на него, private static Soup2 psl = new Soup2(): public static Soup2 accessO { return psl:

}

public void f() {}

}

// В файле может быть определен только один public-класс: public class Lunch {

void testPrivateO {

// Запрещено, т.к конструктор объявлен приватным: //! Soupl soup = new SouplO:

}

void testStaticO {

Soupl soup = Soupl.makeSoupO;

}

void testSingletonO {

Soup2.access О f();

}

)

До этого момента большинство методов возвращало или void, или один из примитивных типов, поэтому определение:

public static Soupl makeSoupO { return new SouplO:

} на первый взгляд смотрится немного странно. Слово Soupl перед именем мето­да (makeSbup) показывает, что возвращается методом. В предшествующих при­мерах обычно использовалось обозначение void, которое подразумевает, что ме­тод не имеет возвращаемого значения. Однако метод также может возвращать ссылку на объект; в данном случае возвращается ссылка на объект класса Soupl.

Классы Soupl H'Soup2 наглядно показывают, как предотвратить прямое соз­дание объектов класса, объявив все его конструкторы со спецификатором pri­vate. Помните, что без явного определения хотя бы одного конструктора компи­лятор сгенерирует конструктор по умолчанию (конструктор без аргументов). Определяя конструктор по умолчанию в программе, вы запрещаете его автома­тическое создание. Если конструктор объявлен со спецификатором private, ни­кто не сможет создавать объекты данного класса. Но как же тогда использовать этот класс? Рассмотренный пример демонстрирует два способа. В классе Soupl определяется статический метод, который создает новый объект Soupl и возвра­щает ссылку на него. Это бывает полезно в ситуациях, где вам необходимо про­вести некоторые операции над объектом перед возвратом ссылки на него, или при подсчете общего количества созданных объектов Soupl (например, для ог­раничения их максимального количества).

В классе Soup2 использован другой подход — в программе всегда создается не более одного объекта этого класса. Объект Soup2 создается как статическая приватная переменная, пэтому он всегда существует только в одном экземпляре и его невозможно получить без вызова открытого метода access().

Резюме

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

Если программисты-клиенты предоставлены сами себе и не ограничены ни­какими правилами, они могут делать все, что им заблагорассудится, с любыми членами класса — даже теми, доступ к которым вам хотелось бы ограничить. Все детали реализации класса открыты для окружающего мира.

В этой главе рассматривается процесс построения библиотек из классов; во-первых, механизм группировки классов внутри библиотеки и, во-вторых, механизм управления доступом к членам класса.

По оценкам проекты на языке С начинают «рассыпаться» примерно тогда, когда код достигает объема от 50 до 100 Кбайт, так как С имеет единое «про­странство имен»; в системе возникают конфликты имен, создающие массу не­удобств. В Java ключевое слово package, схема именования пакетов и ключевое слово import обеспечивают полный контроль над именами, так что конфликта имен можно легко избежать.

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

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

Открытый интерфейс класса — это то, что фактически видит его пользова­тель, поэтому очень важно «довести до ума» именно эту, самую важную, часть класса в процессе анализа и разработки. И даже при этом у вас остается относи­тельная свобода действий. Даже если идеальный интерфейс не удалось постро­ить с первого раза, вы можете добавить в него новые методы — без удаления уже существующих методов, которые могут использоваться программистами- клиентами.

^[1] Использовать Java-интерпретатор не обязательно. Существует несколько компиляторов, создаю­щих единый исполняемый файл.

^[2] На самом деле доступ private или protected могут иметь внутренние классы, но это особый случай (см. главу 8).

Повторное использование классов

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

Повторное использование на базе копирования кода характерно для проце­дурных языков, подобных С, но оно работало не очень хорошо. Решение этой проблемы в Java, как и многое другое, строится на концепции класса. Вместо того чтобы создавать новый класс «с чистого листа», вы берете за основу уже существующий класс, который кто-то уже создал и проверил на работоспособ­ность.

Хитрость состоит в том, чтобы использовать классы без ущерба для сущест­вующего кода. В этой главе рассматриваются два пути реализации этой идеи. Первый довольно прямолинеен: объекты уже имеющихся классов просто созда­ются внутри вашего нового класса. Механизм построения новрго класса из объ­ектов существующих классов называется композицией (composition). Вы просто используете функциональность готового кода, а не его структуру.

Второй способ гораздо интереснее. Новый класс создается как специализа­ция уже существующего класса. Взяв существующий класс за основу, вы добав­ляете к нему свой код без изменения существующего класса. Этот механизм на­зывается наследованием (inheritance), и большую часть работы в нем совершает компилятор. Наследование является одним из «краеугольных камней» объект- но-ориентированного программирования; некоторые из его дополнительных применений описаны в главе 8.

у

и

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

Синтаксис композиции

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

// reusing/SprinklerSystem java

// Композиция для повторного использования кода.

class WaterSource { private String s, WaterSourceO {

System out println( "WaterSourceO"); s = "сконструирован";

}

public String toStringO { return s; }

}

public class SprinklerSystem {

private String valvel. valve2, valve3, valve4, private WaterSource source = new WaterSourceO; private int i. private float f, public String toStringO { return

"valvel = " + valvel + " " + • "valve2 = " + valve2 + " " + "valve3 = " + valve3 + " " +

"valve4 = " + valve4 + "\n" +

••-j = - + -j + ■■ •• + -f = •• + f + •• " +

"source = " + source,

}

public static void main(String[] args) {

SprinklerSystem sprinklers = new SprinklerSystem(), System out println(sprinklers);

}

} /* Output- WaterSourceO

valvel = null valve2 = null valve3 = null valve4 = null i = 0 f = 0.0 source = сконструирован *///•-

В обоих классах определяется особый метод toString(). Позже вы узнаете, что каждый не-примитивный объект имеет метод toString(), который вызывается в специальных случаях, когда компилятор располагает не объектом, а хочет по­лучить его строковое представление в формате String. Поэтому в выражении из метода S р ri n klerSyste m.toStri n g ():

"source = " + source;

компилятор видит, что к строке "source = " «прибавляется» объект класса WaterSource. Компилятор не может это сделать, поскольку к строке можно «до­бавить» только такую же строку, поэтому он преобразует объект source в String, вызывая метод toString(). После этого компилятор уже в состоянии соеди­нить две строки и передать результат в метод System.out.println() (или стати­ческим методам print() и printnb(), используемым в книге). Чтобы подобное поведение поддерживалось вашим классом, достаточно включить в него ме­тод toString().

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

Компилятор не создает объекты для ссылок «по умолчанию», и это логично, потому что во многих случаях это привело бы к лишним затратам ресурсов. Если вам понадобится проинициализировать ссылку, сделайте это самостоя­тельно:

•       в точке определения объекта. Это значит, что объект всегда будет ини­циализироваться перед вызовом конструктора;

•       в конструкторе данного класса;

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

•       с использованием инициализации экземпляров.

В следующем примере продемонстрированы все четыре способа:

//: reusing/Bath.java

// Инициализация в конструкторе с композицией.

import static net.mindview.util.Print.*:

class Soap {

private String s: SoapO {

printCSoapO"); s = "Constructed";

}

public String toStringO { return s: }

}

public class Bath {

private String // Инициализация в точке определения- si = "Счастливый", s2 = "Счастливый", s3. s4. private Soap castille; private int i; private float toy; public BathO {

print( В конструкторе BathO"), s3 = "Радостный"; toy = 3.14f; _ч castille = new SoapO;

}

// Инициализация экземпляра-

{ i = 47; }

public String toStringO {

if(s4 == null) // Отложенная инициализация- s4 = "Радостный";

return

"si = " + si + "\n" + "s2 = " + s2 + "\n" + "s3 = " + s3 + "\n" + "s4 = " + s4 + "\n" + ^Hi = " + i + "\n" + "toy = " + toy + "\n" + "castille = " + castille;

}

public static void main(String[] args) { Bath b = new Bath О; print(b);

}

} /* Output; В конструкторе Bath О SoapO

si = Счастливый s2 = Счастливый s3 = Радостный s4 = Радостный i = 47 toy = 3 14

castille = Сконструирован *///;-

Заметьте, что в конструкторе класса Bath команда выполняется до проведе­ния какой-либо инициализации. Если инициализация в точке определения не выполняется, нет никаких гарантий того, что она будет выполнена перед от­правкой сообщения по ссылке объекта — кроме неизбежных исключений вре­мени выполнения.

При вызове метода toStringO в нем присваивается значение ссылке s4, чтобы все поля были должным образом инициализированы к моменту их использова­ния.

Синтаксис наследования

Наследование является неотъемлемой частью Java (и любого другого языка ООП). Фактически оно всегда используется при создании класса, потому что, даже если класс не объявляется производным от другого класса, он автоматиче­ски становится производным от корневого класса Java Object.

Синтаксис композиции очевиден, но для наследования существует совер­шенно другая форма записи. При использовании наследования вы фактически говорите: «Этот новый класс похож на тот старый класс». В программе этот факт выражается перед фигурной скобкой, открывающей тело класса: сначала записывается ключевое слово extends, а затем имя базового (base) класса. Тем самым вы автоматически получаете доступ ко всем полям и методам базового класса. Пример:

//. reusing/Detergent.java

// Синтаксис наследования и его свойства

import static net mindview util Print.*.

class Cleanser {'

private String s = "Cleanser", public void append(String a) { s += a; } public void diluteO { append( dilutee)"), } public void applyO { appendC applyO"); } public void scrubO { appendC scrubO"): } public String toStringO { return s. } public static void main(String[] args) { Cleanser x = new CleanserO, x diluteO: x applyO, x scrubO; print(x);

}

}

public class Detergent extends Cleanser { II Изменяем метод- public void scrubO {

appendC' Detergent.scrubO").

super scrubO, // Вызываем метод базового класса

}

11 Добавляем новые методы к интерфейсу public void foamO { appendC foamO"), } // Проверяем новый класс, public static void main(String[] args) { Detergent x = new DetergentO, x.diluteO, x.applyO, x scrubO; x. foamO; print(x);

print("Проверяем базовый класс"); Cleanser main(args);

}

} /* Output

Cleanser diluteO applyO Detergent.scrub() scrubO foamO Проверяем базовый класс Cleanser diluteO applyO scrubO */// ~

Пример демонстрирует сразу несколько особенностей наследования. Во-первых, в методе класса Cleanser append() новые строки присоединяются к строке s оператором += — одним из операторов, специально «перегруженных» создателями Java для строк (String).

Во-вторых, как Cleanser, так и Detergent содержат метод main(). Вы можете оп­ределить метод main() в каждом из своих классов; это позволяет встраивать тес­товый код прямо в класс. Метод main() даже не обязательно удалять после за­вершения тестирования, его вполне можно оставить на будущее.

Даже если у вас в программе имеется множество классов, из командной строки исполняется только один (так как метод main() всегда объявляется как public, то неважно, объявлен ли класс, в котором он описан, как public). В нашем примере команда java Detergent вызывает метод Detergent.mainQ. Однако вы так­же можете использовать команду java Cleanser для вызова метода Cleanser.main(), хотя класс Cleanser не объявлен открытым. Даже если класс обладает доступом в пределах класса, открытый метод main() остается доступным.

Здесь метод Detergent.main() вызывает Cleanser.main() явно, передавая ему собственный массив аргументов командной строки (впрочем, для этого годится любой массив строк).

Важно, что все методы класса Cleanser объявлены открытыми. Помните, что при отсутствии спецификатора доступа, член класса автоматически получает доступ «в пределах пакета», что позволяет обращаться к нему только из теку­щего пакета. Таким образом, в пределах данного пакета при отсутствии специ­фикатора доступа вызов этих методов разрешен кому угодно — например, это легко может сделать класс Detergent. Но если бы какой-то класс из другого па­кета был объявлен производным от класса Cleanser, то он получил бы доступ только к его public-членам. С учетом возможности наследования все поля обыч­но помечаются как private, а все методы — как public. (Производный класс также получает доступ к защищенным (protected) членам базового класса, но об этом позже.) Конечно, иногда вы будете отступать от этих правил, но в любом случае полезно их запомнить.

Класс Cleanser содержит ряд методов: append(), dilute(), apply(), scrub() и toString(). Так как класс Detergent произведен от класса Cleanser (с помощью ключевого слова extends), он автоматически получает все эти методы в своем интерфейсе, хотя они и не определяются явно в классе Detergent. Таким обра­зом, наследование обеспечивает повторное использование класса.

Как показано на примере метода scrub(), разработчик может взять уже суще­ствующий метод базового класса и изменить его. Возможно, в этом случае по­требуется вызвать метод базового класса из новой версии этого метода. Однако в методе scrub() вы не можете просто вызвать scrub() — это приведет к рекурсии, а нам нужно не это. Для решения проблемы в Java существует ключевое слово super, которое обозначает «суперкласс», то есть класс, производным от которого является текущий класс. Таким образом, выражение super.scrub() обращается к методу scrub() из базового класса.

При наследовании вы не ограничены использованием методов базового класса. В производный класс можно добавлять новые методы тем же способом, что и раньше, то есть просто определяя их. Метод foam() — наглядный пример такого подхода.

В методе Detergent.main() для объекта класса Detergent вызываются все методы, доступные как из класса Cleanser, так и из класса Detergent (имеется в виду ме­тод foam()).

Инициализация базового класса

Так как в наследовании участвуют два класса, базовый и производный, не сразу понятно, какой же объект получится в результате. Внешне все выглядит так, словно новый класс имеет тот же интерфейс, что и базовый класс, плюс еще не­сколько дополнительных методов и полей. Однако наследование не просто ко­пирует интерфейс базового класса. Когда вы создаете объект производного класса, внутри него содержится подобъект базового класса. Этот подобъект вы­глядит точно так же, как выглядел бы созданный обычным порядком объект ба­зового класса. Поэтому извне представляется, будто бы в объекте производного класса «упакован» объект базового класса.

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

//: reusing/Cartoon.java

// Вызовы конструкторов при проведении наследования, import static net.mindview.util.Print.*,

class Art {

ArtO { print("Конструктор Art"); }

}

class Drawing extends Art {

DrawingО { print("Конструктор Drawing"); }

}

public class Cartoon extends Drawing {

public CartoonO { print("Конструктор Cartoon"); } public static void main(String[] args) { Cartoon x = new CartoonO;

}

} /* Output; Конструктор Art Конструктор Drawing Конструктор Cartoon * ///:-

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

Конструкторы с аргументами

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

//: reusing/Chess.java

// Наследование, конструкторы и аргументы.

import static net.mindview.util.Print.*;

class Game {

Game(int i) {

print("Конструктор Game"),

}

}

class BoardGame extends Game { BoardGame(int i) { super(i);

print("Конструктор BoardGame");

}

}

public class Chess extends BoardGame { Chess О {

super(ll);

print("Конструктор Chess");

}

public static void main(String[] args) { Chess x = new ChessO:

}

} /* Output- Конструктор Game Конструктор BoardGame Конструктор Chess *///:-

Если не вызвать конструктор базового класса в BoardGame(), то компилятор «пожалуется» на то, что не может обнаружить конструктор в форме Game(). Вдобавок вызов конструктора базового класса должен быть первой командой в конструкторе производного класса. (Если вы вдруг забудете об этом, компи­лятор вам тут же напомнит.)

Делегирование

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

//. reusing/SpaceShipControls.java

public class SpaceShipControls { void up(int velocity) {} void down(int velocity) {} void left(int velocity) {} void right(int velocity) {} void forward(int velocity) {} void back(int velocity) {} void turboBoostO {} } ///-

Для построения космического корабля можно воспользоваться наследова­нием:

// reusing/SpaceShip java

public class SpaceShip extends S^ceShipControls { private String name.

public SpaceShip(String name) { this.name = name, }

public String toStringO { return name. }_______

public static void main(String[] args) {

SpaceShip protector = new SpaceShipC'NSEA Protector"), protector forward(lOO).

}

} /// ~

Однако космический корабль не может рассматриваться как частный случай своего управляющего модуля — несмотря на то, что ему, к примеру, можно при­казать двигаться вперед (forward()). Точнее сказать, что SpaceShip содержит SpaceShipControls, и в то же время все методы последнего предоставляются клас­сом SpaceShip. Проблема решается при помощи делегирования:

// reusing/SpaceShipDelegation java

public class SpaceShipDelegation { private String name, private SpaceShipControls controls =

new SpaceShipControlsO: public SpaceShipDelegation(String name) {

this name = name. }

// Делегированные методы: public void back(int velocity) { controls.back(velocity);

}

public void down(int velocity) { controls.down(velocity);

}

public void forward(int velocity) { controls forward(velocity).

}

public void leftCint velocity) { controls left(velocity).

}

public void rightOnt velocity) { controls right(velocity);

}

public void turboBoostO {

controls.turboBoostO.

}

public void up(int velocity) { controls.up(velocity):

}

public static void main(String[] args) { SpaceShipDelegation protector =

new SpaceShipDelegationC'NSEA Protector");                продолжение &

protector.forwarcK 100);

}

} ///:-

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

Хотя делегирование не поддерживается языком Java, его поддержка присут­ствует во многих средах разработки. Например, приведенный пример был авто­матически сгенерирован в JetBrains Idea IDE.

Сочетание композиции и наследования

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

II: reusing/PlaceSetting.java 11 Совмещение композиции и наследования, import static net.mindview.util.Print.*;

class Plate {

'PlateCint i) {

print("Конструктор Plate");

}

}

class DinnerPlate*extends Plate { DinnerPlate(int i) { super(i),

print("Конструктор DinnerPlate");

class Utensil {

Utensil(int i) {

print("Конструктор Utensil");

}

}

class Spoon extends Utensil { Spoon(int i) {

super(i);

print'CKoHCTpyKTop Spoon");

class Fork extends Utensil { Fork(int i) {

super(i);

System.out.println("Конструктор Fork");

}

class Knife extends Utensil { Knife(int i) {

super(i):

print("Конструктор Knife");

class Custom {

Custom(int i) {

print("Конструктор Custom");

public class'PIaceSetting extends Custom { private Spoon sp; private Fork frk; private Knife kn; private DinnerPlate pl; public PIaceSetting(int i) { super(i + 1); sp = new Spoon(i + 2); frk = new Fork(i + 3); kn = new Knifed + 4); pl = new DinnerPlated + 5); pri nt("Конструктор PlaceSetti ng"):

}

public static void main(String[] args) {

. PlaceSetting x = new PlaceSetting(9);

}

} /* Output: Конструктор Custom Конструктор Utensil Конструктор Spoon Конструктор Utensil Конструктор Fork Конструктор Utensil Конструктор Knife Конструктор Plate Конструктор DinnerPlate конструктор PlaceSetting *///:-

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

Обеспечение правильного завершения

В Java отсутствует понятие деструктора из С++ — метода, автоматически вы­зываемого при уничтожении объекта. В Java программисты просто «забывают» об объектах, не уничтожая их самостоятельно, так как функции очистки памяти возложены на сборщика мусора.

Во многих случаях эта модель работает, но иногда класс выполняет некото­рые операции, требующие завершающих действий. Как упоминалось в главе 5, вы не знаете, когда будет вызван сборщик мусора и произойдет ли это вообще. Поэтому, если в классе должны выполняться действия по очистке, вам придется написать для этого особый метод и сделать так, чтобы программисты-клиенты знали о необходимости вызова этого метода. Более того, как описано в главе 10, вам придется предусмотреть возможные исключения и выполнить завершаю­щие действия в секции finally.

Представим пример системы автоматизированного проектирования, которая рисует на экране изображения:

//: reusing/CADSystem.java // Обеспечение необходимого завершения package reusing:

import static net.mindview util.Print.*;

class Shape {

Shape(int i) { print("Конструктор Shape"); } void disposed { print("Завершение Shape"); }

'}

class Circle extends Shape { Circle(int i) {

super(i),

print("Рисуем окружность Circle");

}

void disposeO {

print("Стираем окружность Circle"); super. disposeO;

}

}

class Triangle extends Shape { Triangle(int i) { super(i);

print("Рисуем треугольник Triangle");

}

void disposeO {

print("Стираем треугольник Triangle"); super.disposeO;

}

}

class Line extends Shape { private int start, end; Line(int start, int end) { super(start); this.start = start; this.end = end;

print("Рисуем линию Line: " + start + ", " + end);

}

void disposeO {

print("Стираем линию Line: " + start + ", " + end). super.disposeO;

}

public class CADSystem extends Shape { private Circle c; private Triangle t; private Line[] lines = new Line[3], public CADSystem(int i) { super(i + 1).

for(int j = 0, j < lines length; j++) lines[j] = new Line(j. j*j), с = new Circled), t = new Triangle(l), print("Комбинированный конструктор").

}

void disposed {

print("CADSystem.dispose()"); // Завершение осуществляется в порядке, // обратном порядку инициализации t disposed; с.disposed;

for(int i = lines length - 1; i >=0; i--)

lines[i] .disposed; super disposed;

}

public static void main(String[] args) { CADSystem x = new CADSystem(47), try {

// Код и обработка исключений. } finally {

х disposed,

}

}

} /* Output: Конструктор Shape Конструктор Shape Рисуем линию Line- 0, 0 Конструктор Shape Рисуем линию Line- 1. 1 Конструктор Shape Рисуем линию Line- 2, 4 Конструктор Shape Рисуем окружность Circle Конструктор Shape Рисуем треугольник Triangle Комбинированный конструктор CADSystem. disposed Стираем треугольник Triangle Завершение Shape Стираем окружность Circle Завершение Shape Стираем линию Line: 2, 4 Завершение Shape Стираем линию Line: 1, 1 Завершение Shape Стираем линию Line 0. 0 Завершение Shape Завершение Shape *///.-

Все в этой системе является некоторой разновидностью класса Shape (кото­рый, в свою очередь, неявно наследует от корневого класса Object). Каждый класс переопределяет метод dispose() класса Shape, вызывая при этом версию метода из базового класса с помощью ключевого слова super. Все конкретные классы, унаследованные от Shape — Circle, Triangle и Line, имеют конструкторы, которые просто выводят сообщение, хотя во время жизни объекта любой метод может сделать что-то, требующее очистки. В каждом классе есть свой собствен­ный метод dispose(), который восстанавливает ресурсы, не связанные с памя­тью, к исходному состоянию до создания объекта.

В методе main() вы можете заметить два новых ключевых слова, которые бу­дут подробно рассмотрены в главе 10: try и finally. Ключевое слово try показыва­ет, что следующий за ним блок (ограниченный фигурными скобками) является защищенной секцией. Код в секции finally выполняется всегда, независимо от того, как прошло выполнение блока try. (При обработке исключений можно выйти из блока try некоторыми необычными способами.) В данном примере секция finally означает: «Что бы ни произошло, в конце всегда вызывать метод x.dispose()».

Также обратите особое внимание на порядок вызова завершающих методов для базового класса и объектов-членов в том случае, если они зависят друг от друга. В основном нужно следовать тому же принципу, что использует компи­лятор С++ при вызове деструкторов: сначала провести завершающие действия для вашего класса в последовательности, обратной порядку их создания. (Обычно для этого требуется, чтобы элементы базовых классов продолжали су­ществовать.) Затем вызываются завершающие методы из базовых классов, как и показано в программе.

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

Сокрытие имен

Если какой-либо из методов базового класса Java был перегружен несколько раз, переопределение имени этого метода в производном классе не скроет ни одну из базовых версий (в отличие от С++). Поэтому перегрузка работает вне зависимости от того, где был определен метод — на текущем уровне или в базовом классе:

//: reusing/Hide java

// Перегрузка имени метода из базового класса

// в производном классе не скроет базовую версию метода.

import static net.mindview.util.Print.*:

class Milhouse {}

class Bart extends Homer { void doh(Milhouse m) {

print("doh(Milhouse)");

}

}

public class Hide {

public static void main(String[] args) { Bart b = new BartO; b doh(l); b doh('x'); b.doh(l.Of); b doh(new MilhouseO);

}

} /* Output. doh(float) doh(char) doh(float) doh(Milhouse) *///:-

Мы видим, что все перегруженные методы класса Homer доступны классу Bart, хотя класс Bart и добавляет новый перегруженный метод (в С++ такое дей­ствие спрятало бы все методы базового класса). Как вы увидите в следующей главе, на практике при переопределении методов гораздо чаще используется точно такое же описание и список аргументов, как и в базовом классе. Иначе легко можно запутаться (и поэтому С++ запрещает это, чтобы предотвратить совершение возможной ошибки).

В Java SE5 появилась запись @0verride; она не является ключевым словом, но может использоваться так, как если бы была им. Если вы собираетесь пере­определить метод, используйте @0verride, и компилятор выдаст сообщение об ошибке, если вместо переопределения будет случайно выполнена перегрузка:

//• reusing/Lisa java //{CompileTimeError} (Won't compile)

class Lisa extends Homer {

(^Override void doh(Milhouse m) {

System out println("doh(Milhouse)");

class Homer {

char doh(char с) {

print("doh(char)"); return 'd';

}

float doh(float f) {

print("doh(float)"); return l.Of,

}

Композиция в сравнении с наследованием

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

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

Иногда требуется предоставить пользователю прямой доступ к композиции вашего класса, то есть сделать встроенный объект открытым (public). Встроен­ные объекты и сами используют сокрытие реализации, поэтому открытый дос­туп безопасен. Когда пользователь знает, что класс собирается из составных частей, ему значительно легче понять его интерфейс. Хорошим примером слу­жит объект Саг (машина):

// reusing/Car.java

// Композиция с использованием открытых объектов

// двигатель

class Engine {

public void startO {} // запустить public void rev() {} // переключить public void stopO {} // остановить

}

// колесо

class Wheel {

public void inflate(int psi) {} // накачать

}

// окно

class Window {

public void rollupO {} // поднять public void rolldownO {} // опустить

}

// дверь

class Door {

public Window window = new WindowO; // окно двери public void openО {} // открыть public void closeO {} // закрыть

}

// машина

public class Car {

public Engine engine = new EngineO; public Wheel[] wheel = new Wheel[4], public Door

left = new DoorO,

right = new DoorO: // двухдверная машина

public CarO {

for (int i =0; i <4; i++)

wheel[i] = new Wheel О;

}

public static void main(String[] args) { Car car = new CarO; car 1 eft.window.rollup(); car.wheel[0].inflate(72);

}

} /// -

Так как композиция объекта является частью проведенного анализа задачи (а не просто частью реализации класса), объявление членов класса открытыми (public) помогает программисту-клиенту понять, как использовать класс, и об­легчает создателю класса написание кода. Однако нужно все-таки помнить, что описанный случай является специфическим и в основном поля класса следует объявлять как private.

При использовании наследования вы берете уже существующий класс и соз­даете его специализированную версию. В основном это значит, что класс обще­го назначения адаптируется для конкретной задачи. Если чуть-чуть подумать, то вы поймете, что не имело бы смысла использовать композицию машины и средства передвижения — машина не содержит средства передвижения, она сама есть это средство. Взаимосвязь «является» выражается наследованием, а взаимосвязь «имеет» описывается композицией.

protected

После знакомства с наследованием ключевое слово protected наконец-то обрело смысл. В идеале закрытых членов private должно было быть достаточно. В ре­альности существуют ситуации, когда вам необходимо спрятать что-либо от ок­ружающего мира, тем не менее оставив доступ для производных классов.

Ключевое слово protected — дань прагматизму. Оно означает: «Член класса является закрытым (private) для пользователя класса, но для всех, кто наследу­ет от класса, и для соседей по пакету он доступен». (В Java protected автомати­чески предоставляет доступ в пределах пакета.)

Лучше всего, конечно, объявлять поля класса как private — всегда стоит оста­вить за собою право изменять лежащую в основе реализацию. Управляемый доступ наследникам класса предоставляется через методы protected:

// reusing/Ore java

// Ключевое слово protected

import static net.mindview.util.Print.*;

class Villain {

private String name;

protected void set(String nm) { name = nm; } public Villain(String name) { this.name = name, } public String toStringO {

return "Я объект Villain и мое имя " + name;

}

public class Ore extends Villain { private int orcNumber, public Orc(String name, int orcNumber) { super(name);

this.orcNumber = orcNumber;

}

public void change(String name, int orcNumber) {

set(name); // Доступно, так как объявлено protected this.orcNumber = orcNumber;

}

public String toStringO {

return "Ore " + orcNumber + ": " + super.toString().

}

public static void main(String[] args) {

Ore ore = new ОгсС'Лимбургер". 12); print(orc);

огс.сЬапдеСБоб"* 19); print(orc);

}

} /* Output:

Ore 12: Я объект Villain и мое имя Лимбургер

Ore 19: Я объект Villain и мое имя Боб

*///-

Как видите, метод change() имеет доступ к методу set(), поскольку тот объяв­лен как protected. Также обратите внимание, что метод toString() класса Ore оп­ределяется с использованием версии этого метода из базового класса.

Восходящее преобразование типов

Самая важная особенность наследования заключается вовсе не в том, что оно предоставляет методы для нового класса, — наследование выражает отношения между новым и базовым классом. Ее можно выразить .следующим образом: «Новый класс имеет тип существующего класса».

Данная формулировка — не просто причудливый способ описания наследо­вания, она напрямую поддерживается языком. В качестве примера рассмотрим базовый класс с именем Instrument для представления музыкальных инструмен­тов и его производный класс Wind. Так как наследование означает, что все мето­ды базового класса также доступны в производном классе, любое сообщение, которое вы в состоянии отправить базовому классу, можно отправить и произ­водному классу. Если в классе Instrument имеется метод play(), то он будет при­сутствовать и в классе Wind. Таким образом, мы можем со всей определенно­стью утверждать, что объекты Wind также имеют тип Instrument. Следующий пример показывает, как компилятор поддерживает такое понятие:

//: reusing/Wind.java

// Наследование и восходящее преобразование.

class Instrument {

public void playO {} static void tune(Instrument i) { // ...

i .playO:

}

}

// Объекты Wind также являются объектами Instrument, // поскольку они имеют тот же интерфейс: public class Wind extends Instrument {

public static void main(String[] args) { Wind flute = new WindО.

Instrument.tune(flute); // Восходящее преобразование

}

} ///:-

Наибольший интерес в этом примере представляет метод tune(), получаю­щий ссылку на объект Instrument. Однако в методе Wind.main() методу tune() пе­редается ссылка на объект Wind. С учетом всего, что говорилось о строгой про­верке типов в Java, кажется странным, что метод с готовностью берет один тип вместо другого. Но стоит вспомнить, что объект Wind также является объектом Instrument, и не существует метода, который можно вызвать в методе tune() для объектов Instrument, но нельзя для объектов Wind. В методе tune() код работает для Instrument и любых объектов, производных от Instrument, а преобразование ссылки на объект Wind в ссылку на объект Instrument называется восходящим преобразованием типов (upcasting).

Почему «восходящее преобразование»?

Термин возник по историческим причинам: традиционно на диаграммах насле­дования корень иерархии изображался у верхнего края страницы, а диаграмма разрасталась к нижнему краю страницы. (Конечно, вы можете рисовать свои диаграммы так, как сочтете нужным.) Для файла Wind.java диаграмма наследо­вания выглядит так:

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

Преобразование также может выполняться и в обратном направлении — так называемое нисходящее преобразование (downcasting). Но при этом возникает проблема, которая рассматривается в главе 1.1.

Снова о композиции с наследованием

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

Ключевое слово final

В Java смысл ключевого слова final зависит от контекста, но в основном оно оз­начает: «Это нельзя изменить». Запрет на изменения может объясняться двумя причинами: архитектурой программы или эффективностью. Эти две причины основательно различаются, поэтому в программе возможно неверное употреб­ление ключевого слова final.

В следующих разделах обсуждаются три возможных применения final: для данных, методов и классов.

Неизменные данные

Во многих языках программирования существует тот или иной способ сказать компилятору, что частица данных является «константой». Константы полезны в двух ситуациях:

•        константа времени компиляции, которая никогда не меняется;

•        значение, инициализируемое во время работы программы, которое нель­зя изменять.

Компилятор подставляет значение константы времени компиляции во все выражения, где оно используется; таким образом предотвращаются некоторые издержки выполнения. В Java подобные константы должны относиться к при­митивным типам, а для их определения используется ключевое слово final. Зна­чение такой константы присваивается во время определения.

Поле, одновременно объявленное с ключевыми словами static и final, суще­ствует в памяти в единственном экземпляре и не может быть изменено.

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

Следующий пример демонстрирует использование final для полей классов:

// reusing/Final Data java

// Действие ключевого слова final для полей.

import java util *,

import static net mindview.util Print.*;

class Value {

int i. // доступ в пределах пакета public Value(int i) { this i = i, }

}

public class FinalData {

private static Random rand = new Random(47); private String id,

public FinalData(String id) { this.id = id: } // Могут быть константами времени компиляции, private final int valueOne = 9. private static final int VALUE_TW0 = 99, // Типичная открытая константа, public static final int VALUE_THREE = 39: // He может быть константой времени компиляции: private final int i4 = rand.nextlnt(20); static final int INT_5 = rand nextlnt(20); private Value vl = new Value(ll): private final Value v2 = new Value(22), private static final Value VAL_3 = new Value(33): // Массивы.

private final int[] a = { 1. 2, 3. 4, 5, 6 }: public String toStringO {

return id + ": " + "i4 = " + i4 + ". INT_5 = " + INT_5;

}

public static void main(String[] args) {

FinalData fdl = new FinalDataCfdl"),

//! fdl.valueOne++, // Ошибка значение нельзя изменить

fdl.v2 i++, // Объект не является неизменным!

fdl.vl = new Value(9); // OK - не является неизменным

for(int i = 0, i < fdl.a.length; i++)

fdl a[i]++; // Объект не является неизменным! //! fdl v2 = new Value(O); // Ошибка: ссылку //! fdl VAL_3 = new Valued); // нельзя изменить //' fdl a = new int[3], print(fdl),

print("Создаем FinalData"); FinalData fd2 = new FinalData("fd2^M). print(fdl), print(fd2):

}

} /* Output.

fdl i4 = 15. INT 5 = 18                                                                                                                      _Л

продолжение &

Создаем Final Data fdl: i4 = 15. INT_5 = 18 fd2: i4 = 13. INT_5 = 18 *///:-

Так как valueOne и VALUE_TWO являются примитивными типами со значениями, заданными на стадии компиляции, они оба могут использоваться в качестве констант времени компиляции, и принципиальных различий между ними нет. Константа VALUE_THREE демонстрирует общепринятый способ определения по­добных полей: спецификатор public открывает к ней доступ за пределами пакета; ключевое слово static указывает, что она существует в единственном числе, а ключевое слово final указывает, что ее значение остается неизменным. Заметь­те, что примитивы final static с неизменными начальными значениями (то есть константы времени компиляции) записываются целиком заглавными буквами, а слова разделяются подчеркиванием (эта схема записи констант позаимствова­на из языка С).

Само по себе присутствие final еще не означает, что значение переменной из­вестно уже на стадии компиляции. Данный факт продемонстрирован на приме­ре инициализации i4 и INT_5 с использованием случайных чисел. Эта часть про­граммы также показывает разницу между статическими и нестатическими константами. Она проявляется только при инициализации во время исполне­ния, так как все величины времени компиляции обрабатываются компилято­ром одинаково (и обычно просто устраняются с целью оптимизации). Различие проявляется в результатах запуска программы. Заметьте, что значения поля i4 для объектов fdl и fd2 уникальны, но значение поля INT_5 не изменяется при создании второго объекта FinalData. Дело в том, что поле INT_5 объявлено как static, поэтому оно инициализируется только один раз во время загрузки класса.

Переменные от vl до VAL_3 поясняют смысл объявления ссылок с ключевым словом final. Как видно из метода main(), объявление ссылки v2 как final еще не означает, что ее объект неизменен. Однако присоединить ссылку v2 к новому объекту не получится, как раз из-за того, что она была объявлена как final. Именно такой смысл имеет ключевое слово final по отношению к ссылкам. Вы также можете убедиться, что это верно и для массивов, которые являются про­сто другой разновидностью ссылки. Пожалуй, для ссылок ключевое слово final обладает меньшей практической ценностью, чем для примитивов.

Пустые константы

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

//: c06:BlankFinal .java // "Пустые" неизменные поля.

class Poppet {

private int i:

Poppet(int ii) { i = ii; }

}

public class BlankFinal {

private final int i = 0; // Инициализированная константа private final int j; // Пустая константа private final Poppet p; // Пустая константа-ссылка II Пустые константы НЕОБХОДИМО инициализировать // в конструкторе: public BlankFinalО {

j = 1; // Инициализация пустой константы р = new Poppet(l); // Инициализация пустой неизменной ссылки

}

public BlankFinal(int х) {

j = х; // Инициализация пустой константы р = new Poppet(x), // Инициализация пустой неизменной ссылки

}

public static void main(String[] args) { new BlankFinal О; new BlankFinal(47),

}

} ///:-

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

Неизменные аргументы

Java позволяет вам объявлять неизменными аргументы метода, объявляя их с ключевым словом final в списке аргументов. Это значит, что метод не может изменить значение, на которое указывает передаваемая ссылка:

II: reusing/FinalArguments.java II Использование final с аргументами метода

class Gizmo {

public void spinO {}

}

public class Final Arguments { void with(final Gizmo g) {

III g = new GizmoO; II запрещено -- g объявлено final

}

void without(Gizmo g) {

g = new GizmoO: II Разрешено -- g не является final g.spinO;

}

II void f(final int i) { i++, } II Нельзя изменять. II неизменные примитивы доступны только для чтения: int g(final int i) { return i + 1; } public static void main(String[] args) {

Final Arguments bf = new FinalArgumentsO;

bf .without(null):                                                                              продолжение & bf with(niil 1),

}

} ///.-

Методы f() и g() показывают, что происходит при передаче методу примити­вов с пометкой final: их значение можно прочитать, но изменить его не удастся.

Неизменные методы

Неизменные методы используются по двум причинам. Первая причина — «бло­кировка» метода, чтобы производные классы не могли изменить его содержа­ние. Это делается по соображениям проектирования, когда вам точно надо знать, что поведение метода не изменится при наследовании.

Второй причиной в прошлом считалась эффективность. В более ранних реа­лизациях Java объявление метода с ключевым словом final позволяло компиля­тору превращать все вызовы такого метода во встроенные (inline). Когда ком­пилятор видит метод, объявленный как final, он может (на свое усмотрение) пропустить стандартный механизм вставки кода для проведения вызова метода (занести аргументы в стек, перейти к телу метода, исполнить находящийся там код, вернуть управление, удалить аргументы из стека и распорядиться возвра­щенным значением) и вместо этого подставить на место вызова копию реально­го кода, находящегося в теле метода. Таким образом устраняются издержки обычного вызова метода. Конечно, для больших методов подстановка приведет к «разбуханию» программы, и, скорее всего, никаких преимуществ от использо­вания прямого встраивания не будет.

В последних версиях Java виртуальная машина выявляет подобные ситуа­ции и устраняет лишние передачи управления при оптимизации, поэтому ис­пользовать final для методов уже не обязательно — и более того, нежелательно.

Спецификаторы final и private

Любой закрытый (private) метод в классе косвенно является неизменным (final) методом. Так как вы не в силах получить доступ к закрытому методу, то не смо­жете и переопределить его. Ключевое слово final можно добавить к закрытому методу, но его присутствие ни на что не повлияет.

Это может вызвать недоразумения, так как при попытке переопределения закрытого (private) метода, также неявно являющегося final, все вроде бы рабо­тает и компилятор не выдает сообщений об ошибках:

//• reusi ng/Fi nalOverri di ngll1usi on.java

// Все выглядет так, будто закрытый (и неизменный) метод

// можно переопределить, но это заблуждение.

import static net mindview.util Print.*,

class WithFinals {

// To же, что и просто private:

private final void f() { printC'WithFinals f()^M), }

// Также автоматически является final

private void g() { printC'WithFinals.g()"), }

class OverridingPrivate extends WithFinals {

private final void f() {

printC'OverridingPrivate fO").

}

private void g() {

printC'OverridingPrivate g()").

}

}

class 0verridingPrivate2 extends OverridingPrivate {

public final void f() {

print("0verridingPrivate2 f()").

}

public void g() {

print("0verridingPrivate2 g()").

}

public class FinalOverridingll1usion {

public static void main(String[] args) {

0verridingPrivate2 op2 = new 0verridingPrivate2();

op2 f();

op2.g();

// Можно провести восходящее преобразование-

OverridingPrivate op = op2;

// Но методы при этом вызвать невозможно.

//! op f().

//! op.g().

// И то же самое здесь- WithFinals wf = ор2. //! wf.fO, //! wf g();

}

} /* Output: 0verridingPrivate2.f()

0verridingPrivate2.g() */// ~

«Переопределение» применимо только к компонентам интерфейса базового класса. Иначе говоря, вы должны иметь возможность выполнить восходящее преобразование объекта к его базовому типу и вызвать тот же самый метод (это утверждение подробнее обсуждается в следующей главе). Если метод объявлен как private, он не является частью интерфейса базового класса; это просто неко­торый код, скрытый внутри класса, у которого оказалось то же имя. Если вы создаете в производном классе одноименный метод со спецификатором public, protected или с доступом в пределах пакета, то он никак не связан с закрытым методом базового класса. Так как privat-метод недоступен и фактически неви­дим для окружающего мира, он не влияет ни на что, кроме внутренней органи­зации кода в классе, где он был описан.

Неизменные классы

Объявляя класс неизменным (записывая в его определении ключевое слово final), вы показываете, что не собираетесь использовать этот класс в качестве базового при наследовании и запрещаете это делать другим. Другими словами, по какой-то причине структура вашего класса должна оставаться постоянной — или же появление субклассов нежелательно по соображениям безопасности.

// reusing/Jurassic java

// Объявление неизменным всего класса

class SmallBrain {}

final class Dinosaur { int i = 7, int j = 1,

SmallBrain x = new SmallBrain(), void f() {}

}

//¹ class Further extends Dinosaur {}

// Ошибка Нельзя расширить неизменный класс Dinosaur

public class Jurassic {

public static void main(String[] args) { Dinosaur n = new DinosaurO; n.f(). n.i = 40. n.j++.

}

} ///-

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

Предостережение

На первый взгляд идея объявления неизменных методов (final) во время разра­ботки класса выглядит довольно заманчиво — никто не сможет переопределить ваши методы. Иногда это действительно так.

Но будьте осторожнее в своих допущениях. Трудно предусмотреть все воз­можности повторного использования класса, особенно для классов общего на­значения. Определяя метод как final, вы блокируете возможность использова­ния класса в проектах других программистов только потому, что сами не могли предвидеть такую возможность.

Хорошим примером служит стандартная библиотека Java. Класс vector Java 1.0/1.1 часто использовался на практике и был бы еще полезнее, если бы по со­ображениям эффективности (в данном случае эфемерной) все его методы не были объявлены как final. Возможно, вам хотелось бы создать на основе vector производный класс и переопределить некоторые методы, но разработчи­ки почему-то посчитали это излишним. Ситуация выглядит еще более парадок­сальной по двум причинам. Во-первых, класс Stack унаследован от Vector, и это значит, что Stack есть Vector, а это неверно с точки зрения логики. Тем не менее мы видим пример ситуации, в которой сами проектировщики Java используют наследование от Vector. Во-вторых, многие полезные методы класса Vector, та­кие как addElement() и elementAt(), объявлены с ключевым словом synchronized. Как вы увидите в главе 12, синхронизация сопряжена со значительными из­держками во время выполнения, которые, вероятно, сводят к нулю все преиму­щества от объявления метода как final. Все это лишь подтверждает теорию о том", что программисты не умеют правильно находить области для примене­ния оптимизации. Очень плохо, что такой неуклюжий дизайн проник в стан­дартную библиотеку Java. (К счастью, современная библиотека контейнеров Java заменяет Vector классом ArrayList, который сделан гораздо более аккуратно и по общепринятым нормам. К сожалению, существует очень много готового кода, написанного с использованием старой библиотеки контейнеров.)

Инициализация и загрузка классов

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

В языке Java таких проблем не существует, поскольку в нем используется другой подход к загрузке. Вспомните, что скомпилированный код каждого класса хранится в отдельном файле. Этот файл не загружается, пока не возник­нет такая необходимость. В сущности, код класса загружается только в точке его первого использования. Обычно это происходит при создании первого объ­екта класса, но загрузка также выполняется при обращениях к статическим по­лям или методам.

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

Инициализация с наследованием

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

// reusing/Beetle java

// Полный процесс инициализации

import static net mindview util Print *.

class Insect {

private int 1 =9. protected int j. InsectO {

System out println("i = " + i + ". j = " + j), J = 39,

}

private static int xl =

printlnitC"Поле static Insect xl инициализировано"), static int printlnit(String s) { print(s). return 47.

public class Beetle extends Insect {

private int k = рппШЩ"Поле Beetle k инициализировано"), public BeetleO {

prtC'k = " + k), prtC'j = " + j).

}

private static int x2 =

printInit("Пoлe static Beetle x2 инициализировано"), public static void main(String[] args) { print("Конструктор Beetle"). Beetle b = new BeetleO;

}

} /*

Поле static Insect.xl инициализировано Поле static Beetle x2 инициализировано Конструктор Beetle i = 9. j = 0

Поле Beetle k инициализировано k = 47

j = 39 */// ~

Запуск класса Beetle в Java начинается с выполнения метода Beetle.main() (статического), поэтому загрузчик пытается найти скомпилированный код класса Beetle (он должен находиться в файле Beetle.class). При этом загрузчик обнаруживает, что у класса имеется базовый класс (о чем говорит ключевое слово extends), который затем и загружается. Это происходит независимо от того, собираетесь вы создавать объект базового класса или нет. (Чтобы убе­диться в этом, попробуйте закомментировать создание объекта.)

Если у базового класса имеется свой базовый класс, этот второй базовый класс будет загружен в свою очередь, и т. д. Затем проводится static-инициали­зация корневого базового класса (в данном случае это Insect), затем следующе­го за ним производного класса, и т. д. Это важно, так как производный класс и инициализация его static-объектов могут зависеть от инициализации членов базового класса.

В этой точке все необходимые классы уже загружены, и можно переходить к созданию объекта класса. Сначала всем примитивам данного объекта при­сваиваются значения по умолчанию, а ссылкам на объекты задается значение null — это делается за один проход посредством обнуления памяти. Затем вызы­вается конструктор базового класса. В нашем случае вызов происходит автома­тически, но вы можете явно указать в программе вызов конструктора базового класса (записав его в первой строке описания конструктора Beetle()) с помо­щью ключевого слова super. Конструирование базового класса выполняется по тем же правилам и в том же порядке, что и для производного класса. После за­вершения работы конструктора базового класса инициализируются перемен­ные, в порядке их определения. Наконец, выполняется оставшееся тело конст­руктора.

Резюме

Как наследование, так и композиция позволяют создавать новые типы на осно­ве уже существующих. Композиция обычно применяется для повторного ис­пользования реализации в новом типе, а наследование — для повторного исполь­зования интерфейса. Так как производный класс имеет интерфейс базового класса, к нему можно применить восходящее преобразование к базовому клас­су; это очень важно для работы полиморфизма (см. следующую главу).

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

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

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

Полиморфизм

Меня спрашивали: «Скажите, мистер Бэббидж, если заложить в машину неверные числа, на выходе она все равно выдаст правильный ответ?» Не представляю, какую же кашу надо иметь в голове, чтобы задавать подобные вопросы.Чарльз Бэббидж (1791-1871)

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

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

Инкапсуляция создает новые типы данных за счет объединения характери­стик и поведения. Сокрытие реализации отделяет интерфейс от реализации за счет изоляции технических подробностей в private-частях класса. Подобное механическое разделение понятно любому, кто имел опыт работы с процедур­ными языками. Но полиморфизм имеет дело с логическим разделением в кон­тексте типов. В предыдущей главе вы увидели, что наследование позволяет ра­ботать с объектом, используя как его собственный тип, так и его базовый тип. Этот факт очень важен, потому что он позволяет работать со многими типами (производными от одного базового типа) как с единым типом, что дает возмож­ность единому коду работать с множеством разных типов единообразно. Вы­зов полиморфного метода позволяет одному типу выразить свое отличие от другого, сходного типа, хотя они и происходят от одного базового типа. Это отличие выражается различным действием методов, вызываемых через базо­вый класс.

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

Снова о восходящем преобразовании

Как было показано в главе 7, с объектом можно работать с использованием как его собственного типа, так и его базового типа. Интерпретация ссылки на объ­ект как ссылки на базовый тип называется восходящим преобразованием.

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

II polymorphism/music/Musi с java

// Объекты Note для использования с Instrument

package polymorphism.music,

public enum Note {

MIDDLE_C. C_SHARP, B_FLAT, // И т.д } /// ~

Перечисления были представлены в главе 5. В следующем примере Wind яв­ляется частным случаем инструмента (Instrument), поэтому класс Wind наследу­ет от Instrument:

//• polymorphism/music/instrument java

package polymorphism.music,

import static net mindview.util.Print.*,

class Instrument {

public void play(Note n) {

print("Instrument.pi ay(Г);

}

}

III ~

//• polymorphism/music/Wind java package polymorphism.music;

// Объекты Wind также являются объектами Instrument, II поскольку имеют тот же интерфейс: public class Wind extends Instrument { // Переопределение метода интерфейса public void pi ay(Note n) {

System out pri ntl n( "Wind playO " + n),

}

} III-

II polymorphism/music/Music.java II Наследование и восходящее преобразование package polymorphism music,

public class Music {

public static void tune(Instrument i) { // ...

i.play(Note.MIDDLE_C),

}

public static void main(String[] args) {

Wind flute = new WindO

tune(flute). // Восходящее преобразование

}

} /* Output

Wind playO MIDDLE_C

*/// -

Метод Music.tune() получает ссылку на Instrument, но последняя также может указывать на объект любого класса, производного от Instrument. В методе main() ссылка на объект Wind передается методу tune() без явных преобразований. Это нормально; интерфейс класса Instrument должен существовать и в классе Wind, поскольку последний был унаследован'от Instrument. Восходящее преобразова­ние от Wind к Instrument способно «сузить» этот интерфейс, но не сделает его «меньше», чем полный интерфейс класса Instrument.

Потеря типа объекта

Программа Music.java выглядит немного странно. Зачем умышленно игнориро­вать фактический тип объекта? Именно это мы наблюдаем при восходящем преобразовании, и казалось бы, программа стала яснее, если бы методу tune() передавалась ссылка на объект Wind. Но при этом мы сталкиваемся с очень важ­ным обстоятельством: если поступить подобным образом, то потом придется писать новый метод tune() для каждого типа Instrument, присутствующего в системе. Предположим, что в систему были добавлены новые классы Stringed и Brass:

// polymorphi sm/musi c/Musi c2.java // Перегрузка вместо восходящего преобразования package polymorphism.music, import static net.mindview util Print *;

class Stringed extends Instrument {

public void play(Note n) {

pri nt ("Stri nged.pl ay() " + n):

}

}

class Brass extends Instrument {

public void play(Note n) {

printC'Brass playO " + n),

}

}

public class Music2 {

public static void tune(Wind i) { i.play(Note MIDDLE_C),

}

public static void tune(Stringed i) { i.play(Note MIDDLE'C);

}

public static void tune(Brass i) { i play(Note.MIDDLE_C);

}

public static void main(String[] args) {

Wind flute = new Wind(),

Stringed violin = new StnngedO.

Brass frenchHorn = new BrassO.

tune(flute), // Без восходящего преобразования

tune(violin);

tune(frenchHorn).

}

} /* Output

Wind playO MIDDLE_C

Stringed.pi ayО MIDDLE_C

Brass pi ayО MIDDLE_C *///-

Программа работает, но у нее есть огромный недостаток: для каждого нового Instrument приходится писать новый, зависящий от конкретного типа метод tune(). Объем программного кода увеличивается, а при добавлении нового ме­тода (такого, как tune()) или нового типа инструмента придется выполнить не­мало дополнительной работы. А если учесть, что компилятор не выводит сооб­щений об ошибках, если вы забудете перегрузить один из ваших методов, весь процесс работы с типами станет совершенно неуправляемым.

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

Именно это и позволяет делать полиморфизм. Однако большинство про­граммистов с опытом работы на процедурных языках при работе с полимор­физмом испытывают некоторые затруднения.

Особенности

Сложности с программой Music.java обнаруживаются после ее запуска. Она вы­водит строку Wind.play(). Именно это и требуется, но не понятно, откуда берется такой результат. Взгляните на метод tune():

public static void tune(Instrument i) {

//

i play(Note.MIDDLE_C),

}

Метод получает ссылку на объект Instrument. Как компилятор узнает, что ссылка на Instrument в данном случае указывает на объект Wind, а не на Brass или Stringed? Компилятор и не знает. Чтобы в полной мере разобраться в сути про­исходящего, необходимо рассмотреть понятие связывания (binding).

Связывание «метод-вызов»

Присоединение вызова метода к телу метода называется связыванием. Если связывание проводится перед запуском программы (компилятором и компонов­щиком, если он есть), оно называется ранним связыванием (early binding). Возмож­но, ранее вам не приходилось слышать этот термин, потому что в процедурных языках никакого выбора связывания не было. Компиляторы С поддерживают только один тип вызова — раннее связывание.

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

Проблема решается благодаря позднему связыванию (late binding), то есть связыванию, проводимому во время выполнения программы, в зависимости от типа объекта. Позднее связывание также называют динамическим (dynamic) или связыванием на стадии выполнения (runtime binding). В языках, реализую­щих позднее связывание, должен существовать механизм определения факти­ческого типа объекта во время работы программы, для вызова подходящего ме­тода. Иначе говоря, компилятор не знает тип объекта, но механизм вызова методов определяет его и вызывает соответствующее тело метода. Механизм позднего связывания зависит от конкретного языка, но нетрудно предполо­жить, что для его реализации в объекты должна включаться какая-то дополни­тельная информация.

Для всех методов Java используется механизм позднего связывания, если только метод не был объявлен как final (приватные методы являются final по умолчанию). Следовательно, вам не придется принимать решений относитель­но использования позднего связывания — оно осуществляется автоматически.

Зачем объявлять метод как final? Как уже было замечено в предыдущей гла­ве, это запрещает переопределение соответствующего метода. Что еще важнее, это фактически «отключает» позднее связывание или, скорее, указывает компи­лятору на то, что позднее связывание не является необходимым. Поэтому для методов final компилятор генерирует чуть более эффективный код. Впрочем, в большинстве случаев влияние на производительность вашей программы незна­чительно, поэтому final лучше использовать в качестве продуманного элемента своего проекта, а не как средство улучшения производительности.

Получение нужного результата

Теперь, когда вы знаете, что связывание всех методов в Java осуществляется полиморфно, через позднее связывание, вы можете писать код для базового класса, не сомневаясь в том, что для всех производных классов он также будет работать верно. Другими словами, вы «посылаете сообщение объекту и позво­ляете ему решить, что следует делать дальше».

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

В примере с фигурами имеется базовый класс с именем Shape (фигура) и различные производные типы: Circle (окружность), Square (прямоугольник), Triangle (треугольник) и т. п. Выражения типа «окружность есть фигура» оче­видны и не представляют трудностей для понимания. Взаимосвязи показаны на следующей диаграмме наследования:

Восходящее преобразование имеет место даже в такой простой команде: Shape s = new CircleO;

Здесь создается объект Circle, и полученная ссылка немедленно присваивает­ся типу Shape. На первый взгляд это может показаться ошибкой (присвоение одного типа другому), но в действительности все правильно, потому что тип Circle (окружность) является типом Shape (фигура) посредством наследования. Компилятор принимает команду и не выдает сообщения об ошибке.

Предположим, вызывается один из методов базового класса (из тех, что были переопределены в производных классах):

s.drawO;

Опять можно подумать, что вызывается метод draw() из класса Shape, раз имеется ссылка на объект Shape — как компилятор может сделать что-то дру­гое? И все же будет вызван правильный метод Circle.draw(), так как в программе используется позднее связывание (полиморфизм).

Следующий пример показывает несколько другой подход:

//: polymorph!sm/shape/Shapes java package polymorphism.shape;

public class Shape {

public void drawO {} public void eraseO {} } Hi­ll'. polymorphism/shape/Circle java package polymorphism shape: import static net.mindview.util.Print.*,

public class Circle extends Shape {

public void drawO { printC'Circle.drawO"); } public void eraseO { printC'Circle.eraseO"). } } Hi­ll-. polymorphism/shape/Square.java package polymorphism.shape: import static net.mindview.util Print *.

public class Square extends Shape {

public void drawO { printC'Square.drawO"), }                                                       _                _Л

продолжение &

public void eraseO { printC'Square.eraseO"); } } ///.-

//• polymorphism/shape/Triangle java

package polymorphism.shape;

import static net mindview.util Print.*;

public class Triangle extends Shape {

public void drawO { printC'Triangle.drawO"). } public void eraseO { printC'Triangle eraseO"). } } Hi­ll. polymorphism/shape/RandomShapeGenerator java II "Фабрика", случайным образом создающая объекты package polymorphism.shape; import java.util *;

public class RandomShapeGenerator {

private Random rand = new Random(47); public Shape next О {

switch(rand nextlnt(3)) { default-

case 0: return new CircleO; case 1: return new SquareO, case 2: return new TriangleO;

}

}

} Hi­ll: polymorphism/Shapes.java II Polymorphism in Java, import polymorphism.shape.*;

public class Shapes {

private static RandomShapeGenerator gen =

new RandomShapeGeneratorO; public static void main(String[] args) { Shape[] s = new Shape[9]; II Заполняем массив фигурами: for(int i = 0, i < s.length; i++)

s[i] = gen nextO; II Полиморфные вызовы методов- for(Shape shp • s) shp.drawO,

}

} /* Output: Triangle.drawO Triangle.drawO Square drawO Triangle.drawO Square.drawO Triangle drawO Square drawO Triangle drawO Circle.drawO *///.-

Базовый класс Shape устанавливает общий интерфейс для всех классов, про­изводных от Shape — то есть любую фигуру можно нарисовать (draw()) и сте­реть (erase()). Производные классы переопределяют этот интерфейс, чтобы реа­лизовать уникальное поведение для каждой конкретной фигуры.

Класс RandomShapeGenerator — своего рода «фабрика», при каждом вызове метода next() производящая ссылку на случайно выбираемый объект Shape. За­метьте, что восходящее преобразование выполняется вкомандах return, каждая из которых получает ссылку на объект Circle, Square или Triangle, а выдает ее за пределы next() в виде возвращаемого типа Shape. Таким образом, при вызове этого метода вы не сможете определить конкретный тип объекта, поскольку всегда получаете просто Shape.

Метод main() содержит массив ссылок на Shape, который заполняется после­довательными вызовами RandomShapeGenerator.next(). К этому моменту вам из­вестно, что имеются объекты Shape, но вы не знаете об этих объектах ничего конкретного (так же, как и компилятор). Но если перебрать содержимое масси­ва и вызвать draw() для каждого его элемента, то, как по волшебству, произой­дет верное, свойственное для определенного типа действие — в этом нетрудно убедиться, взглянув на результат работы программы.

Случайный выбор фигур в нашем примере всего лишь помогает понять, что компилятор во время компиляции кода не располагает информацией о том, ка­кую реализацию следует вызывать. Все вызовы метода draw() проводятся с при­менением позднего связывания.

Расширяемость

Теперь вернемся к программе Music.java. Благодаря полиморфизму вы можете добавить в нее сколько угодно новых типов, не изменяя метод tune(). В хорошо спланированной ООП-программе большая часть ваших методов (или даже все методы) следуют модели метода tune(), оперируя только с интерфейсом базово­го класса. Такая программа является расширяемой, поскольку в нее можно до­бавить дополнительную функциональность, определяя новые типы данных от общего базового класса. Методы, работающие на уровне интерфейса базово­го класса, совсем не нужно изменять, чтобы приспособить их к новым классам.

Давайте возьмем пример с объектами Instrument и включим дополнительные методы в базовый класс, а также определим несколько новых классов. Рассмот­рим диаграмму (см. рисунок на обороте).

Все новые классы правильно работают со старым, неизмененным методом tune(). Даже если метод tune() находится в другом файле, а к классу Instrument присоединяются новые методы, он все равно будет работать верно без повтор­ной компиляции. Ниже приведена реализация рассмотренной диаграммы:

продолжение &

//. polymorph"!sm/music3/Music3.java // Расширяемая программа package polymorphism music3; import polymorphism.music Note; import static net.mindview.util.Print *;

class Instrument {

void play(Note л) { print("Instrument playO " + n). }

String what О { return "Instrument". }

void adjustO { printC'Adjusting Instrument"). }

}

class Wind extends Instrument {

void play(Note n) { print ("Wind playO " + n), }

String whatO { return "Wind"; }

void adjustO { printC'Adjusting Wind"). }

}

class Percussion extends Instrument {

void play(Note n) { printC'Percussion.playO " + n). }

String whatO { return "Percussion"; }

void adjustO { printC'Adjusting Percussion"), }

}

class Stringed extends Instrument {

void play(Note n) { printC'Stringed playO " + n), }

String whatO { return "Stringed". }

void adjustO { printC'Adjusting Stringed"); }

}

class Brass extends Wind {

void play(Note n) { print("Brass.play() " + n); } void adjustO { printC'Adjusting Brass"); }

}

class Woodwind extends Wind {

void play(Note n) { print ("Woodwind playO " + n); } String whatO { return "Woodwind"; }

public class Music3 {

// Работа метода не зависит от фактического типа объекта, // поэтому типы, добавленные в систему, будут работать правильно public static void tune(Instrument i) { // ...

i.play(Note.MIDDLE_C),

}

public static void tuneAll(Instrument!!] e) { for(Instrument i : e) tune(i);

}

public static void main(String[] args) {

// Восходящее преобразование при добавлении в массив Instrument!!] orchestra = { new WindO. new PercussionO. new StringedO, new BrassO, new WoodwindО

}:

tuneAll(orchestra),

}

} /* Output. Wind.pi ayО MIDDLE_C Percussion.playO MIDDLE_C Stringed.pi ayО MIDDLE_C Brass.playO MIDDLE_C Woodwind pi ayО MIDDLE_C *///:-

Новый метод what() возвращает строку (String) с информацией о классе, а метод adjust() предназначен для настройки инструментов.

В методе main() сохранение любого объекта в массиве orchestra автоматиче­ски приводит к выполнению восходящего преобразования к типу Instrument.

Вы можете видеть, что метод tune() изолирован от окружающих изменений кода, но при этом все равно работает правильно. Для достижения такой функ­циональности и используется полиморфизм. Изменения в коде не затрагивают те части программы, которые не зависят от них. Другими словами, полимор­физм помогает отделить «изменяемое от неизменного».

Проблема: «переопределение» закрытых методов

Перед вами одна из ошибок, совершаемых по наивности:

//: polymorph!sm/PrivateOverride.java

// Попытка переопределения приватного метода

package polymorphism;

import static net.mindview.util.Print.*;

public class PrivateOverride {

private void f() { printCprivate f(D; } public static void main(String[] args) {

Pri vateOverride po = new DerivedO; po.fO:

}

class Derived extends PrivateOverride {

public void f() { print("public f()"). } } /* Output

private f() *///-

Вполне естественно было бы ожидать, что программа выведет сообщение public f(), но закрытый (private) метод автоматически является неизменным (final), а заодно и скрытым от производного класса. Так что метод f() класса Derived в нашем случае является полностью новым — он даже не был перегру­жен, так как метод f() базового класса классу Derived недоступен.

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

Конструкторы и полиморфизм

Конструкторы отличаются от обычных методов, и эти отличия проявляются и при использовании полиморфизма. Хотя конструкторы сами по себе не по­лиморфны (фактически они представляют собой статические методы, только ключевое слово static опущено), вы должны хорошо понимать, как работают конструкторы в сложных полиморфных иерархиях. Такое понимание в даль­нейшем поможет избежать некоторых затруднительных ситуаций.

Порядок вызова конструкторов

Порядок вызова конструкторов коротко обсуждался в главах 5 и 7, но в то вре­мя мы еще не рассматривали полиморфизм.

Конструктор базового класса всегда вызывается в процессе конструирова­ния производного класса. Вызов автоматически проходит вверх по цепочке на­следования, так что в конечном итоге вызываются конструкторы всех базовых классов по всей цепочке наследования. Это очень важно, поскольку конструк­тору отводится особая роль — обеспечивать правильное построение объектов. Производный класс обычно имеет доступ только к своим членам, но не к чле­нам базового класса (которые чаще всего объявляются со спецификатором private). Только конструктор базового класса обладает необходимыми зна­ниями и правами доступа, чтобы правильно инициализировать свои внут­ренние элементы. Именно поэтому компилятор настаивает на вызове конст­руктора для любой части производного класса. Он незаметно подставит конструктор по умолчанию, если вы явно не вызовете конструктор базового класса в теле конструктора производного класса. Если конструктора по умол­чанию не существует, компилятор сообщит об этом. (Если у класса вообще нет пользовательских конструкторов, компилятор автоматически генерирует кон­структор по умолчанию.)

Следующий пример показывает, как композиция, наследование и полимор­физм влияют на порядок конструирования:

// polymorphism/Sandwich.java

// Порядок вызова конструкторов.

package polymorphism,

import static net mindview.util.Print.*;

class Meal {

Meal О { printCMealO"). }

}

class Bread {

BreadO { printCBreadO"). }

}

class Cheese {

CheeseO { printC'CheeseO"). }

}

class Lettuce {

LettuceO { print("Lettuce()"); }

}

class Lunch extends Meal {

Lunch0 { printC'LunchO"). }

}

class PortableLunch extends Lunch {

PortableLunchO { printC'PortableLunchO");}

}

public class Sandwich extends PortableLunch { private Bread b = new BreadO, private Cheese с = new CheeseO, private Lettuce 1 = new LettuceO; public Sandwich0 { print("Sandwich()"); } public static void main(String[] args) { new SandwichO;

}

} /* Output: Meal О LunchO

PortableLunchO BreadO CheeseO LettuceO SandwichO *///:-

В этом примере создается сложный класс, собранный из других классов, и в каждом классе имеется конструктор, который сообщает о своем выполне­нии. Самый важный класс — Sandwich, с тремя уровнями наследования (четырьмя, если считать неявное наследование от класса Object) и тремя встроенными объ­ектами. Результат виден при создании объекта Sandwich в методе main(). Это значит, что конструкторы для сложного объекта вызываются в следующей по­следовательности:

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

•        Проводится инициализация членов класса в порядке их объявления.

•        Вызывается тело конструктора производного класса.

Порядок вызова конструкторов немаловажен. При наследовании вы распо­лагаете полной информацией о базовом классе и можете получить доступ к лю­бому из его открытых (public) или защищенных (protected) членов. Следова­тельно, при этом подразумевается, что все члены базового класса являются действительными в производном классе. При вызове нормального метода из­вестно, что конструирование уже было проведено, поэтому все части объекта инициализированы. Однако в конструкторе вы также должны быть уверены в том, что все используемые члены уже проинициализированы. Это можно га­рантировать только одним способом — сначала вызывать конструктор базового класса. В дальнейшем при выполнении конструктора производного класса можно быть уверенным в том, что все члены базового класса уже инициализи­рованы. Гарантия действительности всех членов в конструкторе — важная при­чина, по которой все встроенные объекты (то есть объекты, помещенные в класс посредством композиции) инициализируются на месте их определения (как в рассмотренном примере сделано с объектами Ь, с и I). Если вы будете следовать этому правилу, это усилит уверенность в том, что все члены базового класса и объекты-члены были проинициализированы. К сожалению, это помо­гает не всегда, в чем вы убедитесь в следующем разделе.

Наследование и завершающие действия

Если при создании нового класса используется композиция и наследование, обычно вам не приходится беспокоиться о проведении завершающих действий — подобъекты уничтожаются сборщиком мусора. Но если вам необходимо провес­ти завершающие действия, создайте в своем классе метод dispose() (в данном разделе я решил использовать такое имя; возможно, вы придумаете более удач­ное название). Переопределяя метод dispose() в производном классе, важно помнить о вызове версии этого метода из базового класса, поскольку иначе не будут выполнены завершающие действия базового класса. Следующий пример доказывает справедливость этого утверждения:

//: polymorphism/Frog.java

// Наследование и завершающие действия.

package polymorphism;

import static net.mindview util.Print.*;

class Characteristic { private String s;

CharacteristicCString s) { this s = s;

print("Создаем Characteristic " + s);

}

protected void disposeO {

print("Завершаем Characteristic " + s);

class Description {

private String s;

Description(String s) { this s = s.

print("Создаем Description " + s).

}

protected void disposeO {

print("Завершаем Description " + s);

}

}

// живое существо class LivingCreature {

private Characteristic p =

new Characteristic"живое существо");

private Description t =

new Description("обычное живое существо");

LivingCreatureO {

printCLivingCreatureO");

}

protected void disposeO {

print("dispose() в LivingCreature "), t.disposeO; p.disposeO;

// животное

class Animal extends LivingCreature { private Characteristic p =

new Characteristic("имеет сердце"); private Description t =

new Descripti0n(">khb0th0e. не растение"); Animal О { print("Animal()"); } protected void disposeO {

print("disposeO в Animal "); t.disposeO; p.disposeO; super, di sposeO;

// земноводное

class Amphibian extends Animal { private Characteristic p =

new Characteristic"может жить в воде"); private Description t =

new Descriptions в воде, и на земле"); Amphibian О {                  продолжение &

// лягушка

public class Frog extends Amphibian {

private Characteristic p = new CharacteristicC'KBaKaei"). private Description t = new Description"ест жуков"), public FrogO { printC'FrogO"), } protected void disposeO {

print С завершение Frog"), t disposeO; p disposeO; super.disposeO;

}

public static void main(String[] args) { Frog frog = new FrogO; print("Пока!"); frog. disposeO;

}

} /* Output:

Создаем Characteristic живое существо Создаем Description обычное живое существо LivingCreatureO

Создаем Characteristic имеет сердце Создаем Description животное, не растение Animal О

Создаем Characteristic может жить в воде Создаем Description и в воде, и на земле Amphibian О

Создаем Characteristic квакает Создаем Description ест жуков FrogO Пока!

завершение Frog

Завершаем Description ест жуков Завершаем Characteristic квакает disposeO в Amphibian

Завершаем Description и в воде, и на земле Завершаем Characteristic может жить в воде disposeO в Animal

Завершаем Description животное, не растение Завершаем Characteristic имеет сердце disposeO в LivingCreature Завершаем Description обычное живое существо Завершаем Characteristic живое существо *///:-

print ("Amphibian (Г);

}

protected void disposeO {

print ("disposeO в Amphibian "); t.disposeO; p.disposeO; super.disposeO,

Каждый класс в иерархии содержит объекты классов Characteristic и De­scription, которые также необходимо «завершать». Очередность завершения должна быть обратной порядку инициализации в том случае, если объекты

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

Также обратите внимание на то, что в описанном примере объект Frog явля­ется «владельцем» встроенных объектов. Он создает их, определяет продолжи­тельность их существования (до тех пор, пока существует Frog) и знает, когда вызывать dispose() для встроенных объектов. Но если встроенный объект ис­пользуется совместно с другими объектами, ситуация усложняется и вы уже не можете просто вызвать dispose(). В таких случаях для отслеживания количе­ства объектов, работающих со встроенным объектом, приходится использовать подсчет ссылок. Вот как это выглядит:

// polymorphism/ReferenceCounting.java

11 Уничтожение совместно используемых встроенных объектов

import static net mindview.util.Print.*;

class Shared {

private int refcount = 0; private static long counter = 0, private final long id = counter++, public SharedO {

print("Создаем " + this);

}

public void addRefO { refcount++; } protected void disposeO { if(--refcount == 0)

printODisposing " + this),

}

public String toStringO { return "Shared " + id; }

}

class Composing {

private Shared shared; private static long counter = 0. private final long id = counter++, public Composing(Shared shared) { print("Создаем " + this); this.shared = shared, this shared addRefO.

}

protected void disposeO {

printC'disposing " + this), shared disposeO,

}

public String toStringO { return "Composing " + id; }

}

public class ReferenceCounting {

public static void main(String[] args) {

Shared shared = new SharedO;

Composing[] composing = { new Composing(shared).

new Composing(shared), new Composing(shared), new Composing(shared), new Composing(shared) }; for(Composing с • composing) с disposeO.

}

} /* Output: Создаем Shared 0 Создаем Composing 0 Создаем Composing 1 Создаем Composing 2 Создаем Composing 3 Создаем Composing 4 уничтожаем Composing 0 уничтожаем Composing 1 уничтожаем Composing 2 уничтожаем Composing 3 уничтожаем Composing 4 уничтожаем Shared 0 *///:-

В переменной static long counter хранится количество созданных экземпля­ров Shared. Для счетчика выбран тип long вместо int для того, чтобы предотвра­тить переполнение (это всего лишь хороший стиль программирования; в рас­сматриваемых примерах переполнение вряд ли возможно). Поле id объявлено со спецификатором final, поскольку его значение остается постоянным на про­тяжении жизненного цикла объекта

Присоединяя к классу общий объект, необходимо вызвать addRef(), но метод dispose() будет следить за состоянием счетчика ссылок и сам решит, когда нуж­но выполнить завершающие действия. Подсчет ссылок требует дополнитель­ных усилий со стороны программиста, но при совместном использовании объ­ектов, требующих завершения, у вас нет особого выбора.

Поведение полиморфных методов при вызове из конструкторов

В иерархиях конструкторов возникает интересный вопрос. Что происходит, если вызвать в конструкторе динамически связываемый метод конструируемо­го объекта?

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

Но ничего подобного. При вызове динамически связываемого метода в кон­структоре используется переопределенное описание этого метода. Однако по­следствия такого вызова могут быть весьма неожиданными, и здесь могут крыть­ся некоторые коварные ошибки.

По определению, задача конструктора — дать объекту жизнь (и это отнюдь не простая задача). Внутри любого конструктора объект может быть сформирован лишь частично — известно только то, что объекты базового класса были проини- циализированы. Если конструктор является лишь очередным шагом на пути по­строения объекта класса, производного от класса данного конструктора, «про­изводные» части еще не были инициализированы на момент вызова текущего конструктора. Однако динамически связываемый вызов может перейти во «внешнюю» часть иерархии, то есть к производным классам. Если он вызовет метод производного класса в конструкторе, это может привести к манипуляциям с неинициализированными данными — а это наверняка приведет к катастрофе. Следующий пример поясняет суть проблемы:

// polymorphism/PolyConstructors java // Конструкторы и полиморфизм дают не тот // результат, который можно было бы ожидать import static net mindview util Print *.

class Glyph {

void drawO { print("Glyph drawO"), } GlyphO {

printCGlyphO перед вызовом drawO");

drawO.

print ("GlyphO после вызова drawO").

class RoundGlyph extends Glyph { private int radius = 1; RoundGlyph(int r) { radius = r.

print("RoundGlyph RoundGlyph(). radius = " + radius);

}

void drawO {

print ("RoundGlyph. drawO, radius = " + radius);

public class PolyConstructors {

public static void main(String[] args) { new RoundGlyph(5);

}

} /* Output-

GlyphO перед вызовом drawO RoundGlyph drawO, radius = 0 GlyphO после вызова drawO RoundGlyph RoundGlyphO, radius = 5 *///:-

Метод Glyph.draw() изначально предназначен для переопределения в произ­водных классах, что и происходит в RoundGlyph. Но конструктор Glyph вызывает этот метод, и в результате это приводит к вызову метода RoundGlyph.draw(), что вроде бы и предполагалось. Однако из результатов работы программы видно — когда конструктор класса Glyph вызывает метод draw(), переменной radius еще не присвоено даже значение по умолчанию 1. Переменная равна 0. В итоге класс может не выполнить свою задачу, а вам придется долго всматриваться в код программы, чтобы определить причину неверного результата.

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

•        Память, выделенная под новый объект, заполняется двоичными нулями.

•        Конструкторы базовых классов вызываются в описанном ранее порядке. В этот момент вызывается переопределенный метод draw() (да, перед вы­зовом конструктора класса RoundGlyph), где обнаруживается, что пере­менная radius равна нулю из-за первого этапа.

•        Вызываются инициализаторы членов класса в порядке их определения.

•        Исполняется тело конструктора производного класса.

У происходящего есть и положительная сторона — по крайней мере, данные инициализируются нулями (или тем, что понимается под нулевым значением для определенного типа данных), а не случайным «мусором» в памяти. Это от­носится и к ссылкам на объекты, внедренные в класс с помощью композиции. Они принимают особое значение null. Если вы забудете инициализировать та­кую ссылку, то получите исключение во время выполнения программы. Ос­тальные данные заполняются нулями, а это обычно легко заметить по выход­ным данным программы.

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

При написании конструктора руководствуйтесь следующим правилом: не пытайтесь сделать больше для того, чтобы привести объект в нужное состоя­ние, и по возможности избегайте вызова каких-либо методов. Единственные методы, которые можно вызывать в конструкторе без опаски — неизменные (final) методы базового класса. (Сказанное относится и к закрытым (private) ме­тодам, поскольку они автоматически являются неизменными.) Такие методы невозможно переопределить, и поэтому они застрахованы от «сюрпризов».

Ковариантность возвращаемых типов

В Java SE5 появилась концепция ковариантности возвращаемых типов; этот термин означает, что переопределенный метод производного класса может вер­нуть тип, производный от типа, возвращаемого методом базового класса:

//: polymorph!sm/CovanantReturn java

class Grain {

public String toStringO { return "Grain"; }

}

class Wheat extends Grain {

public String toStringO { return "Wheat"; }

class Mill {

Grain process О { return new GrainO; }

}

class WheatMill extends Mill {

Wheat process О { return new WheatO; }

}

public class CovariantReturn {

public static void main(String[] args) { Mill m = new Mi 11(); Grain g = m.processO; System out println(g); m = new WheatMi 110; g = m process О, System out.println(g);

}

} /* Output Grain Wheat */// ~

Главное отличие Java SE5 от предыдущих версий Java заключается в том, что старые версии заставляли переопределение process() возвращать Grain вме­сто Wheat, хотя тип Wheat, производный от Grain, является допустимым возвра­щаемым типом. Ковариантность возвращаемых типов позволяет вернуть более специализированный тип Wheat.

Разработка с наследованием

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

Лучше для начала использовать композицию, пока вы точно не уверены в том, какой именно механизм следует выбрать. Композиция не стесняет разра­ботку рамками иерархии наследования. К тому же механизм композиции более гибок, так как он позволяет динамически выбирать тип (а следовательно, и по­ведение), тогда как наследование требует, чтобы точный тип был известен уже во время компиляции. Следующий пример демонстрирует это:

// polymorphi sm/Transmogrify.java // Динамическое изменение поведения объекта // с помощью композиции (шаблон проектирования «Состояние») • import static net.mindview.util.Print.*;

class Actor {

public void act О {}

}

class HappyActor extends Actor {

public void actO { pri nt ("HappyActor"), }

class SadActor extends Actor {

public void act() { printCSadActor"). }

}

class Stage {

private Actor actor = new HappyActor(); public void changeO { actor = new SadActorO. } public void performPlayO { actor.act(), }

}

public class Transmogrify {

public static void main(String[] args) { Stage stage = new StageO; stage. performPlayO; stage. changeO; stage. performPlayO;

}

} /* Output-

HappyActor

SadActor

*///:-

Объект Stage содержит ссылку на объект Actor, которая инициализируется объектом HappyActor. Это значит, что метод performPlayO имеет определенное поведение. Но так как ссылку на объект можно заново присоединить к другому объекту во время выполнения программы, ссылке actor назначается объект SadActor, и после этого поведение метода performPlayO изменяется. Таким обра­зом значительно улучшается динамика поведения на стадии выполнения про­граммы. С другой стороны, переключиться на другой способ наследования во время работы программы невозможно; иерархия наследования раз и навсе­гда определяется в процессе компиляции программы.

Нисходящее преобразование и динамическое определение типов

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

Должен существовать какой-то механизм, гарантирующий правильность нисходящего преобразования; в противном случае вы можете случайно исполь­зовать неверный тип, послав ему сообщение, которое он не в состоянии при­нять. Это было бы небезопасно.

В некоторых языках (подобных С++) для проведения безопасного нисхо­дящего преобразования типов необходимо провести специальную операцию, но в Java каждое преобразование контролируется! Поэтому, хотя внешне все вы­глядит как обычное приведение типов в круглых скобках, во время выполнения программы это преобразование проходит проверку на фактическое соответст­вие типу. Если типы не совпадают, происходит исключение ClassCastException. Процесс проверки типов во время выполнения программы называется динами­ческим определением типов (run-time type identification, RTTI). Следующий пример демонстрирует действие RTTI:

//: polymorphi sm/RTTI java

// Нисходящее преобразование и динамическое определение типов (RTTI)

// {ThrowException}

class Useful {

public void f() {} public void g() {}

}

class MoreUseful extends Useful { public void f() {} public void g() {} public void u() {} public void v() {} public void w() {}

}

public class RTTI {

public static void main(String[] args) { Useful[] x = {

new Useful О. new MoreUsefulО

}:

x[0].f(): x[l] g().

// СТадия компиляции- метод не найден в классе Useful• //! x[l].u().

((MoreUseful)х[1]) u(); // Нисх преобразование /RTTI ((MoreUseful)x[0]).u0; // Происходит исключение

}

} ///:-

Класс MoreUseful расширяет интерфейс класса Useful. Но благодаря наследо­ванию он также может быть преобразован к типу Useful. Вы видите, как это про­исходит, при инициализации массива х в методе main(). Так как оба объекта в массиве являются производными от Useful, вы можете послать сообщения (вызвать методы) f() и д() для обоих объектов, но при попытке вызова метода и() (который существует только в классе MoreUseful) вы получите сообщение об ошибке компиляции.

Чтобы получить доступ к расширенному интерфейсу объекта MoreUseful, ис­пользуйте нисходящее преобразование. Если тип указан правильно, все прой­дет успешно; иначе произойдет исключение ClassCastException. Вам не пона­добится писать дополнительный код для этого исключения, поскольку оно указывает на общую ошибку, которая может произойти в любом месте про­граммы.

Впрочем, RTTI не сводится к простой проверке преобразований. Например, можно узнать, с каким типом вы имеете дело, прежде чем проводить нисходя­щее преобразование. Глава 11 полностью посвящена изучению различных ас­пектов динамического определения типов Java.

Резюме

Полиморфизм означает «многообразие форм». В объектно-ориентированном программировании базовый класс предоставляет общий интерфейс, а различ­ные версии динамически связываемых методов — разные формы использова­ния интерфейса.

Как было показано в этой главе, невозможно понять или создать примеры с использованием полиморфизма, не прибегнув к абстракции данных и насле­дованию. Полиморфизм — это возможность языка, которая не может рассмат­риваться изолированно; она работает только согласованно, как часть «общей картины» взаимоотношений классов.

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

Интерфейсы

Интерфейсы и абстрактные классы улучшают структуру кода и способствуют отделению интерфейса от реализации.

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

Мы начнем с понятия абстрактного класса, который представляет собой своего рода промежуточную ступень между обычным классом и интерфейсом. Абстрактные классы — важный и необходимый инструмент для создания клас­сов, содержащих нереализованные методы. Применение «чистых» интерфейсов возможно не всегда.

Абстрактные классы и методы

В примере с классами музыкальных инструментов из предыдущей главы мето­ды базового класса Instrument всегда оставались «фиктивными». Попытка вызо­ва такого метода означала, что в программе произошла какая-то ошибка. Это объяснялось тем, что класс Instrument создавался для определения общего ин­терфейса всех классов, производных от него.

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

Если в программе определяется абстрактный класс вроде Instrument, созда­ние объектов такого класса практически всегда бессмысленно. Абстрактный класс создается для работы с набором классов через общий интерфейс. А если Instrument только выражает интерфейс, а создание объектов того класса не име­ет смысла, вероятно, пользователю лучше запретить создавать такие объекты. Конечно, можно заставить все методы Instrument выдавать ошибки, но в этом случае получение информации откладывается до стадии выполнения. Ошибки такого рода лучше обнаруживать во время компиляции.

В языке Java для решения подобных задач применяются абстрактные мето­ды¹. Абстрактный метод незавершен; он состоит только из объявления и не имеет тела. Синтаксис объявления абстрактных методов выглядит так:

abstract void f();

Класс, содержащий абстрактные методы, называется абстрактным классом. Такие классы тоже должны помечаться ключевым словом abstract (в противном случае компилятор выдает сообщение об ошибке).

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

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

Класс Instrument очень легко можно сделать абстрактным. Только некоторые из его методов станут абстрактными, поскольку объявление класса как abstract не подразумевает, что все его методы должны быть абстрактными. Вот что по­лучится:

А вот как выглядит реализация примера оркестра с использованием абст­рактных классов и методов:

//. interfaces/music4/Musiс4 java // Абстрактные классы и методы package interfaces.music4; import polymorphism.music.Note, import static net mindview util Print *.

abstract class Instrument {

private int i; // Память выделяется для каждого объекта public abstract void play(Note n); public String whatO { return "Instrument"; } public abstract void adjustO,

}

class Wind extends Instrument { public void play(Note n) {

print("Wind playО " + n),

}

public String whatO { return "Wind"; } public void adjustO {}

}

class Percussion extends Instrument { public void play(Note n) {

printC'Percussion playO " + n).

}

public String whatO { return "Percussion", } public void adjustO {}

}

class Stringed extends Instrument { public void play(Note n) {

print ("Stringed playO " + n),

}

public String whatO { return "Stringed". } public void adjustO {}

}

class Brass extends Wind {

public void play(Note n) {

printCBrass.playO " + n);

}

public void adjustO { printC'Brass adjustO"), }

}

class Woodwind extends Wind { public void play(Note n) {

print("Woodwind playО " + n);

}

public String whatO { return "Woodwind", }

}

public class Music4 {

// Работа метода не зависит от фактического типа объекта. // поэтому типы, добавленные в систему, будут работать правильно:

static void tune(Instrument i) {

//

i.piay(Note MIDDLE_C),

}

static void tuneAll (Instrument!!] e) { for(Instrument i e) tune(i).

}

public static void main(String[] args) {

// Восходящее преобразование при добавлении в массив Instruments orchestra = { new WindO. new PercussionO. new StringedO. new BrassO. new WoodwindО

}.

tuneAl1(orchestra).

}

} /* Output Wind.pi ayО MIDDLE_C Percussion playO MIDDLE_C Stringed playO MIDDLE_C Brass playO MIDDLE_C Woodwind pi ayО MIDDLE_C */// ~

Как видите, объем изменений минимален.

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

Интерфейсы

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

Ключевое слово interface фактически означает: «Именно так должны выгля­деть все классы, которые реализуют данный интерфейс». Таким образом, лю­бой код, использующий конкретный интерфейс, знает только то, какие методы вызываются для этого интерфейса, но не более того. Интерфейс определяет своего рода «протокол взаимодействия» между классами.

Однако интерфейс представляет собой нечто большее, чем абстрактный класс в своем крайнем проявлении, потому что он позволяет реализовать подо­бие «множественного наследования» С++: иначе говоря, создаваемый класс мо­жет быть преобразован к нескольким базовым типам.

Чтобы создать интерфейс, используйте ключевое слово interface вместо class. Как и в случае с классами, вы можете добавить перед словом interface специфи­катор доступа public (но только если интерфейс определен в файле, имеющем то же имя) или оставить для него дружественный доступ, если он будет исполь­зоваться только в пределах своего пакета. Интерфейс также может содержать поля, но они автоматически являются статическими (static) и неизменными (final).

Для создания класса, реализующего определенный интерфейс (или группу интерфейсов), используется ключевое слово implements. Фактически оно озна­чает: «Интерфейс лишь определяет форму, а сейчас будет показано, как это ра­ботает». В остальном происходящее выглядит как обычное наследование. Рас­смотрим реализацию на примере иерархии классов Instrument:

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

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

Все сказанное можно увидеть в следующем примере с объектами Instrument. Заметьте, что каждый метод интерфейса ограничивается простым объявлением; ничего большего компилятор не" разрешит. Вдобавок ни один из методов интер­фейса Instrument не объявлен со спецификатором public, но все методы автома­тически являются открытыми:

// interfaces/music5/Music5.java

// Интерфейсы.

package interfaces.music5;

import polymorphism.music.Note;

import static net.mindview.util.Print.*;

interface Instrument {

// Константа времени компиляции:

int VALUE = 5; // является и static, и final

// Определения методов недопустимы:

void play(Note n); // Автоматически объявлен как public

void adjustO;

}

class Wind implements Instrument { public void play(Note n) {

print(this + ".playO " + n);

}

public String toStringO { return "Wind"; } public void adjustO { print(this + ".adjustO"); }

}

class Percussion implements Instrument { public void play(Note n) {

print(this + ".playO " + n),

}

public String toStringO { return "Percussion"; } public void adjustO { print(this + " adjustO"); }

}

class Stringed implements Instrument { public void play(Note n) {

print(this + ".playO " + n);

}

public String toStringO { return "Stringed"; } public void adjustO { print(this + ".adjustO"); }

}

class Brass extends Wind {

public String toStringO { return "Brass"; }

}

class Woodwind extends Wind {

public String toStringO { return "Woodwind"; }

}

public class Music5 {

// Работа метода не зависит от фактического типа объекта. // поэтому типы, добавленные в систему, будут работать правильно: static void tune(Instrument i) { // .

i.play(Note.MIDDLE_C);

}

static void tuneAll(Instruments e) { for(Instrument i : e) tune(i);

}

public static void main(String[] args) {

// Восходящее преобразование при добавлении в массив. Instrument!!] orchestra = { new WindO. new PercussionO. new StringedO, new BrassO. new WoodwindО

}.

tuneAll(orchestra),

}

} /* Output: Wind.pi ayО MIDDLE_C Percussion.playO MIDDLE_C Stringed.pi ayО MIDDLE_C Brass.pi ayО MIDDLE_C Woodwind pi ayО MIDDLE_C */// ~

В этой версии присутствует еще одно изменение: метод what() был заменен на toString(). Так как метод toString() входит в корневой класс Object, его присут­ствие в интерфейсе не обязательно.

Остальной код работает так же, как прежде. Неважно, проводите ли вы пре­образование к «обычному» классу с именем Instrument, к абстрактному классу с именем Instrument или к интерфейсу с именем Instrument — действие будет одинаковым. В методе tune() ничто не указывает на то, является класс Instrument «обычным» или абстрактным, или это вообще не класс, а интерфейс.

Отделение интерфейса от реализации

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

Представьте, что у нас имеется класс Processor с методами name() и process(). Последний получает входные данные, изменяет их и выдает результат. Базовый класс расширяется для создания разных специализированных типов Processor. В следующем примере производные типы изменяют объекты String (обратите внимание: ковариантными могут быть возвращаемые значения, но не типы ар­гументов):

//• interfaces/classprocessor/Apply.java package interfaces classprocessor; import java.util.*;

import static net.mindview.util.Print.*;

class Processor {

public String nameО {

return getClass().getSimpleName();

}

Object process(Object input) { return input; }

class Upcase extends Processor {

String process(Object input) { // Ковариантный возвращаемый тип return ((String)input) toUpperCase(),

class Downcase extends Processor { String process(Object input) {

return ((String)input) toLowerCase(),

class Splitter extends Processor { String process(Object input) {

// Аргумент splitO используется для разбиения строки return Arrays toString(((String)input) splitC ")),

public class Apply {

public static void process(Processor p. Object s) { print ("Используем Processor " + p nameO), print(p.process(s));

}

public static String s =

"Disagreement with beliefs is by definition incorrect"; public static void main(String[] args) { process(new UpcaseO, s); process(new Downcase(), s); process(new SplitterO, s),

}

} /* Output:

Используем Processor Upcase

DISAGREEMENT WITH BELIEFS IS BY DEFINITION INCORRECT Используем Processor Downcase disagreement with beliefs is by definition incorrect Используем Processor Splitter

[Disagreement, with, beliefs, is, by, definition, incorrect] *///-

Метод Apply.process() получает любую разновидность Processor, применяет ее к Object, а затем выводит результат. Метод split() является частью класса String. Он получает объект String, разбивает его на несколько фрагментов по ограничи­телям, определяемым переданным аргументом, и возвращает String[]. Здесь он используется как более компактный способ создания массива String.

Теперь предположим, что вы обнаружили некое семейство электронных фильтров, которые тоже было бы уместно использовать с методом Apply. process():

// interfaces/filters/Waveform java package interfaces.filters.

public class Waveform {

private static long counter;

private final long id = counter++; public String toStringO { return "Waveform " + id. } } Hi­ll- interfaces/filters/Filter java package interfaces filters,

public class Filter {

public String nameO {

return getClassO getSimpleName().

}

public Waveform process(Waveform input) { return input; } } III ~

// interfaces/filters/LowPass java package interfaces filters,

public class LowPass extends Filter { double cutoff;

public LowPass(double cutoff) { this.cutoff = cutoff; } public Waveform process(Waveform input) {

return input; II Фиктивная обработка

}

} Hi­ll ■ i nterfaces/fi 1ters/Hi ghPass.java package interfaces.filters;

public class HighPass extends Filter { double cutoff;

public HighPass(double cutoff) { this.cutoff = cutoff; } public Waveform process(Waveform input) { return input. } } ///.-

// interfaces/filters/BandPass java package interfaces filters;

public class BandPass extends Filter { double lowCutoff. highCutoff; public BandPass(double lowCut. double highCut) { lowCutoff = lowCut; highCutoff = highCut;

}

public Waveform process(Waveform input) { return input; } } III-

Класс Filter содержит те же интерфейсные элементы, что и Processor, но, по­скольку он не является производным от Processor (создатель класса Filter и не по­дозревал, что вы захотите использовать его как Processor), он не может исполь­зоваться с методом Apply.process(), хотя это выглядело бы вполне естественно. Логическая привязка между Apply.process() и Processor оказывается более силь­ной, чем реально необходимо, и это обстоятельство препятствует повторному ис­пользованию кода Apply.process(). Также обратите внимание, что входные и вы­ходные данные относятся к типу Waveform.

Но, если преобразовать класс Processor в интерфейс, ограничения ослабля­ются и появляется возможность повторного использования Apply.process(). Об­новленные версии Processor и Apply выглядят так:

//: interfaces/interfaceprocessor/Processor.java package interfaces interfaceprocessor;

public interface Processor { String nameO;

Object process(Object input), } ///-

//. interfaces/interfaceprocessor/Apply.java package i nterfaces.i nterfaceprocessor, import static net mindview.util.Print.*:

public class Apply {

public static void process(Processor p. Object s) { print ("Using Processor " + p.nameO): print(p.process(s)):

}

} ///:-

В первом варианте повторного использования кода клиентские программи­сты пишут свои классы с поддержкой интерфейса:

//: interfaces/interfaceprocessor/StringProcessor.java package i nterfaces.i nterfaceprocessor; import java.util.*;

public abstract class StringProcessor implements Processor! public String nameO {

return getClassO getSimpleNameO;

}

public abstract String process(Object input); public static String s =

"If she weighs the same as a duck, she's made of wood"; public static void main(String[] args) { Apply, process (new UpcaseO, s); Apply, process (new DowncaseO, s); Apply, process (new SplitterO. s);

class Upcase extends StringProcessor {

public String process(Object input) { II Ковариантный возвращаемый тип return ((String)input) .toUpperCaseO;

class Downcase extends StringProcessor { public String process(Object input) {

return ((String)input).toLowerCase();

class Splitter extends StringProcessor {

public String process(Object input) {

return Arrays.toString(((String)input).split(" ")).

}

} /* Output

Используем Processor Upcase

IF SHE WEIGHS THE SAME AS A DUCK, SHE'S MADE OF WOOD Используем Processor Downcase if she weighs the same as a duck, she's made of wood Используем Processor Splitter

[If. she. weighs, the. same. as. a. duck., she's, made. of. wood] *///:-

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

//: interfaces/interfaceprocessor/FilterProcessor java package interfaces interfaceprocessor, import interfaces.filters.*;

class FilterAdapter implements Processor { Filter filter.

public FilterAdapter(Filter filter) { this.filter = filter.

}

public String nameO { return filter.nameO; } public Waveform process(Object input) {

return filter.process((Waveform)input).

}

}

public class FilterProcessor {

public static void main(String[] args) { Waveform w = new Waveform(); -

Apply process(new FilterAdapter(new LowPass(l.O)), w); Apply.process(new FilterAdapter(new HighPass(2.0)). w); Apply.process(

new FilterAdapter(new BandPass(3.0. 4 0)).w);

}

} /* Output.

Используем Processor LowPass Waveform 0

Используем Processor HighPass Waveform 0

Используем Processor BandPass

Waveform 0 *///.-

Конструктор FilterAdapter получает исходный интерфейс (Filter) и создает объект с требуемым интерфейсом Processor. Также обратите внимание на при­менение делегирования в классе FilterAdapter.

Отделение интерфейса от реализации позволяет применять интерфейс к разным реализациям, а следовательно, расширяет возможности повторного использования кода.

«Множественное наследование» в Java

Так как интерфейс по определению не имеет реализации (то есть не обладает памятью для хранения данных), нет ничего, что могло бы помешать совмеще­нию нескольких интерфейсов. Это очень полезная возможность, так как в неко­торых ситуациях требуется выразить утверждение: «Икс является и А, и Б, и В од­новременно». В С++ подобное совмещение интерфейсов нескольких классов называется множественным наследованием, и оно имеет ряд очень неприятных аспектов, поскольку каждый класс может иметь свою реализацию. В Java мож­но добиться аналогичного эффекта, но, поскольку реализацией обладает всего один класс, проблемы, возникающие при совмещении нескольких интерфейсов в С++, в Java принципиально невозможны:

При наследовании базовый класс вовсе не обязан быть абстрактным или «реальным» (без абстрактных методов). Если наследование действительно осу­ществляется не от интерфейса, то среди прямых «предков» класс может быть только один — все остальные должны быть интерфейсами. Имена интерфейсов перечисляются вслед за ключевым словом implements и разделяются запятыми. Интерфейсов может быть сколько угодно, причем к ним можно проводить вос­ходящее преобразование. Следующий пример показывает, как создать новый класс на основе реального класса и нескольких интерфейсов:

//: interfaces/Adventure java

// Использование нескольких интерфейсов.

interface CanFight { void fightO,

}

interface CanSwim { void swimO,

}

interface CanFly { void fly().

}

class ActionCharacter {

public void fightO {}

}

class Hero extends ActionCharacter

implements CanFight, CanSwim, CanFly { public void swimO {}

public void fly() {}

}

public class Adventure {

public static void t(CanFight x) { x fightO; } public static void u(CanSwim x) { x swimO, } public static void v(CanFly x) { x fly(); } public static void w(ActionCharacter x) { x.fightO. } public static void main(String[] args) { Hero h = new HeroO;

t(h), // Используем объект в качестве типа CanFight u(h). // Используем объект в качестве типа CanSwim v(h). // Используем объект в качестве типа CanFly w(h), // Используем объект в качестве ActionCharacter

}

} ///-

Мы видим, что класс Него сочетает реальный класс ActionCharacter с интер­фейсами CanFight, CanSwim и CanFly. При объединении реального класса с интер­фейсами на первом месте должен стоять реальный класс, а за ним следуют ин­терфейсы (иначе компилятор выдаст ошибку).

Заметьте, что объявление метода fight() в интерфейсе CanFight совпадает с тем, что имеется в классе ActionCharacter, и поэтому в классе Него нет опреде­ления метода fight(). Интерфейсы можно расширять, но при этом получается другой интерфейс. Необходимым условием для создания объектов нового типа является наличие всех определений. Хотя класс Него не имеет явного определе­ния метода fight(), это определение существует в классе ActionCharacter, что и де­лает возможным создание объектов класса Него.

Класс Adventure содержит четыре метода, которые принимают в качестве ар­гументов разнообразные интерфейсы и реальный класс. Созданный объект Него передается всем этим методам, а это значит, что выполняется восходящее пре­образование объекта к каждому интерфейсу по очереди. Система интерфейсов Java спроектирована так, что она нормально работает без особых усилий со сто­роны программиста.

Помните, что главная причина введения в язык интерфейсов представлена в приведенном примере: это возможность выполнять восходящее преобразова­ние к нескольким базовым типам. Вторая причина для использования интер­фейсов совпадает с предназначением абстрактных классов: запретить програм- мисту-клиенту создание объектов этого класса.

Возникает естественный вопрос: что лучше — интерфейс или абстрактный класс? Если можно создать базовый класс без определений методов и перемен­ных-членов, выбирайте именно интерфейс, а не абстрактный класс. Вообще го­воря, если известно, что нечто будет использоваться как базовый класс, первым делом постарайтесь сделать это «нечто» интерфейсом.

Расширение интерфейса через наследование

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

//• interfaces/HorrorShow java

// Расширение интерфейса с помощью наследования

interface Monster { void menace(),

}

interface DangerousMonster extends Monster { void destroy();

}

interface Lethal { void kill();

}

class DragonZilla implements DangerousMonster { public void menaceО {} public void destroyО {}

}

interface Vampire extends DangerousMonster, Lethal { void drinkBloodO;

}

class VeryBadVampire implements Vampire { public void menaceO {} public void destroyО {} public void killO {} public void drinkBloodO {}

}

public class HorrorShow {

static void u(Monster b) { b.menaceO; } static void v(DangerousMonster d) { d. menaceO, d.destroyО;

}

static void w(Lethal 1) { 1 killO; } public static void main(String[] args) {

DangerousMonster barney = new DragonZi11a(); u(barney); v(barney);

Vampire vlad = new VeryBadVampire(); u(vlad), v(vlad); w(vlad);

}

} ///:-

DangerousMonster представляет собой простое расширение Monster, в резуль­тате которого образуется новый интерфейс. Он реализуется классом DragonZilla.

Синтаксис, использованный в интерфейсе Vampire, работает только при на­следовании интерфейсов. Обычно ключевое слово extends может использо­ваться всего с одним классом, но, так как интерфейс можно составить из несколь­ких других интерфейсов, extends подходит для написания нескольких имен интерфейсов при создании нового интерфейса. Как нетрудно заметить, имена нескольких интерфейсов разделяются при этом запятыми.

Конфликты имен при совмещении интерфейсов

При реализации нескольких интерфейсов может возникнуть небольшая про­блема. В только что рассмотренном примере интерфейс CanFight и класс Action- Character имеют идентичные методы void fight(). Хорошо, если методы полно­стью тождественны, но что, если они различаются по сигнатуре или типу возвращаемого значения? Рассмотрим такой пример:

//• i interfaces/InterfaceColli si on java package interfaces;

interface  II { void f(); }

interface  12 { int f(int i); }

interface  13 { int f(). }

class С {   public int f() { return 1; } }

class C2 implements II. 12 { public void f() {}

public int f(int i) { return 1; } // перегружен

}

class C3 extends С implements 12 {

public int f(int i) { return 1; } // перегружен

}

class C4 extends С implements 13 { // Идентичны, все нормально; public int f() { return 1; }

}

// Методы различаются только по типу возвращаемого значения; //! class С5 extends С implements II {} //! interface 14 extends II. 13 {} ///;-

Трудность возникает из-за того, что переопределение, реализация и пере­грузка образуют опасную «смесь». Кроме того, перегруженные методы не могут различаться только возвращаемыми значениями. Если убрать комментарий в двух последних строках программы, сообщение об ошибке разъясняет суть происходящего:

InterfaceCollisi on.java.23 f() в С не может реализовать f() в II; попытка использовать несовместимые возвращаемые типы обнаружено: int требуется- void

InterfaceCollisi on java;24- интерфейсы 13 и II несовместимы; оба определяют f(). но с различными возвращаемыми типами

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

Интерфейсы как средство адаптации

Одной из самых убедительных причин для использования интерфейсов являет­ся возможность определения нескольких реализаций для одного интерфейса. В простых ситуациях такая схема принимает вид метода, который при вызове передается интерфейсу; от вас потребуется реализовать интерфейс и передать объект методу.

Соответственно, интерфейсы часто применяются в архитектурном паттерне «Стратегия». Вы пишете метод, выполняющий несколько операций; при вызо­ве метод получает интерфейс, который тоже указываете вы. Фактически вы го­ворите: «Мой метод может использоваться с любым объектом, удовлетворяю­щим моему интерфейсу». Метод становится более гибким и универсальным.

Например, конструктор класса Java SE5 Scanner получает интерфейс Readable. Анализ показывает, что Readable не является аргументом любого дру­гого метода из стандартной библиотеки Java — этот интерфейс создавался ис­ключительно для Scanner, чтобы его аргументы не ограничивались определен­ным классом. При таком подходе можно заставить Scanner работать с другими типами. Если вы хотите создать новый класс, который может использоваться со Scanner, реализуйте в нем интерфейс Readable:

//. interfaces/RandomWords java

// Реализация интерфейса для выполнения требований метода

import java nio.*;

import java util.*,

public class RandomWords implements Readable { private static Random rand = new Random(47); private static final char[] capitals =

"ABCDEFGHIJKLMNOPQRSTUVWXYZ".toCharArray(); private static final char[] lowers =

"abcdefghijklmnopqrstuvwxyz".toCharArrayO; private static final char[] vowels =

"aeiou" toCharArrayO; private int count,

public RandomWords(int count) { this.count = count: } public int read(CharBuffer cb) { if(count-- == 0)

return -1; // Признак конца входных данных cb.append(capi tals[rand.nextInt(capi ta1s.1 ength) ]); for(int i = 0; i < 4; i++) {

cb.append(vowels[rand.nextInt(vowels.1ength)]); cb append(lowers[rand.nextInt(lowers.length)]),

}

cb.append(" "),

return 10; // Количество присоединенных символов

}

public static void main(String[] args) {

Scanner s = new Scanner(new RandomWords(10)); while(s.hasNextO)

System.out.println(s.nextO);

}

} /* Output:

Yazeruyac

Fowenucor Goeazimom Raeuuacio Nuoadesiw Hageaikux Ruqicibui. Numasetih Kuuuuozog Waqizeyoy */// ~

Интерфейс Readable требует только присутствия метода read(). Метод read() либо добавляет данные в аргумент CharBuffer (это можно сделать несколькими способами; обращайтесь к документации CharBuffer), либо возвращает -1 при отсутствии входных данных.

Допустим, у нас имеется класс, не реализующий интерфейс Readable, — как заставить его работать с Scanner? Перед вами пример класса, генерирующего ве­щественные числа:

// interfaces/RandomDoubles java import java util *;

public class RandomDoubles {

private static Random rand = new Random(47), public double next О { return rand nextDouble(), } public static void main(String[] args) {

RandomDoubles rd = new RandomDoubles(), for(int i = 0, l < 7. i ++)

System out print(rd next О + " "),

}

} /* Output

0 7271157860730044 0 5309454508634242 0 16020656493302599 0 18847866977771732

0 5166020801268457 0 2678662084200585 0 2613610344283964 *///.-

Мы снова можем воспользоваться схемой адаптера, но на этот раз адапти­руемый класс создается наследованием и реализацией интерфейса Readable. Псевдомножественное наследование, обеспечиваемое ключевым словом inter­face, позволяет создать новый класс, который одновременно является и Random- Doubles, и Readable:

//• interfaces/AdaptedRandomDoubles java // Создание адаптера посредством наследования import java nio *. import java util *,

public class AdaptedRandomDoubles extends RandomDoubles implements Readable { private int count;

public AdaptedRandomDoubles(int count) { this count = count,

}

public int read(CharBuffer cb) { if(count-- == 0)

return -1.

String result = Double toString(nextO) + "

cb.append(result); return result.lengthO;

}

public static void main(String[] args) {

Scanner s = new Scanner(new AdaptedRandomDoubles(7)), while(s hasNextDoubleO)

System.out print(s nextDoubleO + " ");

}

} /* Output-

0.7271157860730044 0.5309454508634242 0 16020656493302599 0 18847866977771732 0.5166020801268457 0.2678662084200585 0.2613610344283964 *///•-

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

Поля в интерфейсах

Так как все поля, помещаемые в интерфейсе, автоматически являются статиче­скими (static) и неизменными (final), объявление interface хорошо подходит для создания групп постоянных значений. До выхода Java SE5 только так можно было имитировать перечисляемый тип enum из языков С и С++:

//• interfaces/Months java

// Использование интерфейсов для создания групп констант, package interfaces:

public interface Months { int

JANUARY = 1, FEBRUARY = 2, MARCH = 3, APRIL = 4, MAY « 5. JUNE = 6, JULY = 7, AUGUST = 8, SEPTEMBER = 9, OCTOBER = 10. NOVEMBER = 11, DECEMBER = 12:

} ///-

Отметьте стиль Java — использование только заглавных букв (с разделением слов подчеркиванием) для полей со спецификаторами static и final, которым присваиваются фиксированные значения на месте описания. Поля интерфейса автоматически являются открытыми (public), поэтому нет необходимости явно указывать это.

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

Инициализация полей интерфейсов

Поля, определяемые в интерфейсах, не могут быть «пустыми константами», но могут инициализироваться не-константными выражениями. Например:

//• interfaces/RandVals java // Инициализация полей интерфейсов // не-константными выражениями, import java.util.*;

public interface RandVals {

Random RAND = new Random(47); int RANDOM_INT = RAND.nextInt(10); long RAND0M_L0NG = RAND.nextLong() * 10; float RANDOMJLOAT = RAND, next Long () * 10; double RAND0M_D0UBLE = RAND.nextDouble() * 10; } ///.-

Так как поля являются статическими, они инициализируются при первой загрузке класса, которая происходит при первом обращении к любому из полей интерфейса. Простой тест:

//: interfaces/TestRandVals.java import static net.mindview.util.Print.*;

public class TestRandVals {

public static void main(String[] args) { print(RandVals.RANDOMJNT); pri nt(RandVals.RAND0M_L0NG); print(RandVals.RANDOM FLOAT); pri nt(RandVa1s.RANDOM^DOUBLE);

}

} /* Output: 8

-32032247016559954 -8.5939291E18 5.779976127815049 *///:-

Конечно, поля не являются частью интерфейса. Данные хранятся в статиче­ской области памяти, отведенной для данного интерфейса.

Вложенные интерфейсы

Интерфейсы могут вкладываться в классы и в другие интерфейсы¹. При этом обнаруживается несколько весьма интересных особенностей:

//: interfaces/nesting/Nestinglnterfaces.java package interfaces.nesting;

class A {

interface В {

void f();

}

public class BImp implements В { public void f() {}

private class BImp2 implements В {                                                                 продолжение &

public void f() {}

}

public interface С { void f();

}

class CImp implements С { public void f() {}

}

private class CImp2 implements С { public void f() {}

}

private interface D { void f();

}

private class DImp implements D { public void f() {}

}

public class DImp2 implements D { public void f() {}

}

public D getDO { return new DImp2(); }

private D dRef;

public void receiveD(D d) { dRef = d; dRef.fO:

}

interface E {

interface G {

void f();

}

// Избыточное объявление public: public interface H { void f();

}

void g();

// He может быть private внутри интерфейса: //! private interface I {}

public class Nestinglnterfaces {

public class BImp implements А.В { public void f() {}

}

class CImp implements А С { public void f() {}

}

// Private-интерфейс не может быть реализован нигде, // кроме как внутри класса, где он был определен: //! class DImp implements A.D { //! public void f() {} //! }

class EImp implements E { public void g() {}

}

class EGImp implements E.G { public void f() {}

}

class EImp2 implements E { public void g() {} class EG implements E.G { public void f() {}

}

}

public static void main(String[] args) { A a = new ), // Нет доступа к A.D. //! A D ad = a getDO. // He возвращает ничего, кроме A.D: //! A DImp2 di2 = a getDO. // Член интерфейса недоступен //' a getDO f().

// Только другой класс А может использовать getDO А а2 = new А(). а2 receiveD(a getDO).

}

} /// ~

Синтаксис вложения интерфейса в класс достаточно очевиден. Вложенные интерфейсы, как и обычные, могут иметь «пакетную» или открытую (public) видимость.

Любопытная подробность: интерфейсы могут быть объявлены закрытыми (private), как видно на примере A.D (используется тот же синтаксис описания, что и для вложенных классов). Для чего нужен закрытый вложенный интер­фейс? Может показаться, что такой интерфейс реализуется только в виде за­крытого (private) вложенного класса, подобного DImp, но A.DImp2 показывает, что он также может иметь форму открытого (public) класса. Тем не менее класс A.DImp2 «замкнут» сам на себя. Факт реализации private-интерфейса не может упоминаться в программе, поэтому реализация такого интерфейса — просто способ принудительного определения методов этого интерфейса без добавле­ния информации о дополнительном типе (то есть восходящее преобразование становится невозможным).

Метод getD() усугубляет сложности, связанные с private-интерфейсом, — это открытый (public) метод, возвращающий ссылку на закрытый (private) интер­фейс. Что можно сделать с возвращаемым значением этого метода? В методе main() мы видим несколько попыток использовать это возвращаемое значение, и все они оказались неудачными. Заставить метод работать можно только од­ним способом — передать возвращаемое значение некоторому объекту, которо­му разрешено его использование (в нашем случае это еще один объект А, у кото­рого имеется необходимый метод receiveD()).

Интерфейс Е показывает, что интерфейсы могут быть вложены друг в друга. Впрочем, правила для интерфейсов — в особенности то, что все элементы ин­терфейса должны быть открытыми (public), — здесь строго соблюдаются, поэто­му интерфейс, вложенный внутрь другого интерфейса, автоматически объявля­ется открытым и его нельзя сделать закрытым (private).

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

Интерфейсы и фабрики

Предполагается, что интерфейс предоставляет своего рода «шлюз» к несколь­ким альтернативным реализациям. Типичным способом получения объектов, соответствующих интерфейсу, является паттерн «фабрика». Вместо того, чтобы вызывать конструктор напрямую, вы вызываете метод объекта-фабрики, кото­рый предоставляет реализацию интерфейса — в этом случае программный код теоретически отделяется от реализации интерфейса, благодаря чему становится возможной совершенно прозрачная замена реализации. Следующий пример де­монстрирует типичную структуру фабрики:

//: interfaces/Factories.java

import static net.mindview.util.Print.*;

interface Service { void methodic); void method2();

}

interface ServiceFactory { Service getServiceO;

}

class Implementationl implements Service {

ImplementationlO {} // Доступ в пределах пакета public void methodic) {print("Implementationl methodl");}

public void method2() {print("Implementationl method2");} } • . .

class ImplementationlFactory implements ServiceFactory { public Service getServiceO {

return new ImplementationlO;

}

}

class Implementation2 implements Service {

Implementation2() {} // Доступ в пределах пакета publ/ic void methodlО {print("Implementation2 methodl");} public void method2() {print("Implementation2 method2");}

}

class Implementation2Factory implements ServiceFactory { public Service getService.O {

return new Implementation2();

}

}

public class Factories {

public static void serviceConsumer(ServiceFactory fact) { Service s = fact.getServiceO;

s methodic). s.method2();

}

public static void main(String[] args) {

serviceConsumer(new ImplementationlFactoryO); // Реализации полностью взаимозаменяемы serviceConsumec(new Implementation2FactoryO);

}

} /* Output. Implementation! methodl Implementationl method2 Implementation2 methodl Implementation2 method2 *///:-

Без применения фабрики вам пришлось бы где-то указать точный тип созда­ваемого объекта Service, чтобы он мог вызвать подходящий конструктор.

Но зачем вводить лишний уровень абстракции? Данный паттерн часто при­меняется при создании библиотек. Допустим, вы создаете систему для игр, ко­торая позволяла бы играть в шашки и шахматы на одной доске:

//: interfaces/Games.java

// Игровая библиотека с использованием фабрики

import static net.mindview.util.Print.*:

interface Game { boolean moveO; } interface GameFactory { Game getGameO; }

class Checkers implements Game { private int moves = 0: private static final int MOVES = 3: public boolean motfeO {

print("Checkers move " + moves): return ++moves != MOVES;

}

}

class CheckersFactory implements GameFactory {

public Game getGameO { return new CheckersO; }

}

class Chess implements Game { private int moves = 0; private static final int MOVES = 4; public boolean moveO {

print("Chess move " + moves); return ++moves != MOVES;

}

}

class ChessFactory implements GameFactory {

public Game getGameO { return new ChessO; }

}

public class Games {

public static void playGame(GameFactory factory) {

Game s = factory.getGameO;                                                         продолжение & while(s.moveO)

}

public static void main(String[] args). { playGame(new CheckersFactoryO); playGame(new ChessFactoryO);

}

} /* Output: Checkers move 0 Checkers move 1 Checkers move 2 Chess move 0 Chess move 1 Chess move 2 Chess move 3 *///:-

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

В следующей главе будет представлен более элегантный способ реализации фабрик на базе анонимных внутренних классов.

Резюме

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

Многие программисты поддались этому искушению. Тем не менее любая аб­стракция должна быть мотивирована реальной потребностью. Основное назна­чение интерфейсов — возможность переработки реализации в случае необходи­мости, а не введение лишнего уровня абстракции вместе с дополнительными сложностями. Дополнительные сложности могут оказаться довольно сущест­венными. А представьте, что кто-то будет вынужден разбираться в вашем коде и в конечном итоге поймет, что интерфейсы были добавлены «на всякий слу­чай», без веских причин — в таких ситуациях все проектирование, которое вы­полнялось данным разработчиком, начинает выглядеть довольно сомнительно.

В общем случае рекомендуется отдавать предпочтение классам перед ин­терфейсами. Начните с классов, а если необходимость интерфейсов станет оче­видной — переработайте архитектуру своего проекта. Интерфейсы — замеча­тельный инструмент, но ими нередко злоупотребляют.

Внутренние классы

Определение класса может размещаться внутри определения другого класса. Такие классы называются внутренними (inner class).

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

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

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

Создание внутренних классов

Внутренние классы создаются в точности так, как и следовало ожидать, — опре­деление класса размещается внутри окружающего класса:

//: innerclasses/Parcel 1.java // Создание внутренних классов.

public class Parcel 1 {

class Contents {

private int i = 11,

public int valueO { return i; }

}

class Destination {

private String label, DestinationCString whereTo) { label = whereTo;

}

String readLabeK) { return label; }

}

// Использование внутренних классов имеет много общего // с использованием любых других классов в пределах Parcel 1: public void shipCString dest) {

Contents с = new ContentsO; Destination d = new Destination(dest); System.out.pri ntln(d readLabel()),

}

public static void main(String[] args) { Parcel 1 p = new Parcel 10. p.ship("Тасмания").

}

} /* Output: Тасмания *///:-

Если вам понадобится создать объект внутреннего класса где-либо, кроме как в не-статическом методе внешнего класса, тип этого объекта должен зада­ваться в формате ИмяВнешнегоКласса.ИмяВнутреннегоКласса, что и делается в методе main().

Связь с внешним классом

Пока что внутренние классы выглядят как некоторая схема для сокрытия имен и организации кода — полезная, но не особенно впечатляющая. Однако есть еще один нюанс. Объект внутреннего класса связан с внешним объектом-созда­телем и может обращаться к его членам без каких-либо дополнительных описа­ний. Вдобавок для внутренних классов доступны все без исключения элементы внешнего класса^[1]. Следующий пример иллюстрирует сказанное:

//: innerclasses/Sequence,java // Хранение последовательности объектов

interface Selector { boolean endO, Object currentO; void nextO;

}

public class Sequence {

private Object[] objects;

private int next = 0,

public Sequence(int size) { items = new Object[size], }

public void add(Object x) {

if(next < items length)

iterns[next++] = x,

}

private class SequenceSelector implements Selector { private int i = 0.

public boolean endО { return i == items.length; } public Object current О { return i terns [ i D: } public void nextО { if(i < items.length) i++; }

}

public Selector selectorO {

return new SequenceSelectorO;

}

public static void main(String[] args) {

Sequence sequence = new Sequence(lO); for(int i = 0, i < 10; i++)

sequence.add(Integer.toString(i)), Selector selector = sequence getSelectorO; whileC!selector endO) {

System.out.println(selector.currentО + " "); selector.nextO;

}

}

} /* Output- 0 1 2 3 4 5 6 7 8 9 *///:-

Класс Sequence — не более чем «оболочка» для массива с элементами Object, имеющего фиксированный размер. Для добавления новых объектов в конец по­следовательности (при наличии свободного места) используется метод add(). Для выборки каждого объекта в последовательности Sequence предусмотрен ин­терфейс с именем Selector. Он позволяет узнать, достигнут ли конец последова­тельности (метод end()), обратиться к текущему объекту (метод current()) и перей­ти к следующему объекту последовательности (метод next()). Так как Selector является интерфейсом, другие классы вправе реализовать его по-своему, а переда­ча его в параметре методов повышает универсальность кода.

Здесь SequenceSelector является закрытым (private) классом, предоставляю­щим функциональность интерфейса Selector. В методе main() вы можете наблю­дать за процессом создания последовательности с последующим заполнением ее объектами String. Затем вызывается метод getSelector() для получения интер­фейса Selector, который используется для перемещения по последовательности и выбора ее элементов.

На первый взгляд создание SequenceSelector напоминает создание обычного внутреннего класса. Но присмотритесь к нему повнимательнее. Заметьте, что в каждом из методов end(), current() и next() присутствует ссылка на items, а это не одно из полей класса SequenceSelector, а закрытое (private) поле объемлющего класса. Внутренний класс может обращаться ко всем полям и методам внешне­го класса-оболочки, как будто они описаны в нем самом. Это весьма удобно, и вы могли в этом убедиться, изучая рассмотренный пример.

Итак, внутренний класс автоматически получает доступ к членам объемлю­щего класса. Как же это происходит? Внутренний класс содержит скрытую ссылку на определенный объект окружающего класса, ответственный за его создание. При обращении к члену окружающего класса используется эта (скрытая) ссылка. К счастью, все технические детали обеспечиваются компиля­тором, но теперь вы знаете, что объект внутреннего класса можно создать толь­ко в сочетании с объектом внешнего класса (как будет показано позже, если внутренний класс не является статическим). Конструирование объекта внут­реннего класса требует наличия ссылки на объект внешнего класса; если ссыл­ка недоступна, компилятор выдаст сообщение об ошибке. Большую часть вре­мени весь процесс происходит без всякого участия со стороны программиста.

Конструкции .this и .new

Если вам понадобится получить ссылку на объект внешнего класса, запишите имя внешнего класса, за которым следует точка, а затем ключевое слово this. Полученная ссылка автоматически относится к правильному типу, известному и проверяемому на стадии компиляции, поэтому дополнительные издержки на стадии выполнения не требуются. Следующий пример показывает, как ис­пользовать конструкцию .this:

//: innerclasses/DotThis.java

// Обращение к объекту внешнего класса.

public class DotThis {

void f() { System.out.pnntlnCDotThis.fО"); } public class Inner {

public DotThis outer() {

return DotThis this.

// A plain "this" would be Inner's "this"

}

}

public Inner inner О { return new InnerO; } public static void main(String[] args) { DotThis dt = new DotThisO; DotThis Inner dti = dt.innerO; dti.outer().f();

}

} /* Output:

DotThis.f()

*///:-

Иногда бывает нужно приказать другому объекту создать объект одного из его внутренних классов. Для этого перед .new указывается ссылка на другой объект внешнего класса:

//: innerclasses/DotNew.java

// Непосредственное создание внутреннего класса в синтаксисе .new

public class DotNew {

public class Inner {}

public static void main(String[] args) {

DotNew dn - new DotNew(); DotNew.Inner dni = dn.new InnerO;

}

} III -

При создании объекта внутреннего класса указывается не имя внешнего класса DotNew, как можно было бы ожидать, а имя объекта внешнего класса. Это также решает проблему видимости имен для внутреннего класса, поэтому мы не используем (а вернее, не можем использовать) запись вида dn.new DotNew. Inner().

Невозможно создать объект внутреннего класса, не имея ссылки на внешний класс. Но если создать вложенный класс (статический внутренний класс), ссыл­ка на объект внешнего класса не нужна.

Рассмотрим пример использования .new в примере Parcel:

// innerclasses/Parcel3 java

// Использование new для создания экземпляров внутренних классов

public class Parcel3 { class Contents {

private int i = 11,

public int valueO { return i; }

}

class Destination {

private String label;

DestinationCString whereTo) { label = whereTo; } String readLabelO { return label; }

}

public static void main(String[] args) { Parcel3 p = new Parcel3(); II Для создания экземпляра внутреннего класса // необходимо использовать экземпляр внешнего класса: Pa reel 3. Contents с = p. new ContentsO; Parcel3.Destination d = p new Destination"Танзания");

}

} III -

Внутренние классы и восходящее преобразование

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

Для начала определим интерфейсы для предыдущих примеров:

// i nnerclasses/Desti nati on.java public interface Destination {

String readLabel(); } Hi­ll-. innerclasses/Contents.java public interface Contents {

int valueO; } ///-

Теперь интерфейсы Contents и Destination доступны программисту-клиенту. (Помните, что в объявлении interface все члены класса автоматически являются открытыми (public).)

При получении из метода ссылки на базовый класс или интерфейс возмож­ны ситуации, в которых вам не удастся определить ее точный тип, как здесь:

//. innerclasses/TestParcel.java

class Parcel4 {

private class PContents implements Contents { private int i = 11; public int valueO { return i; }

}

protected class PDestination implements Destination { private String label; private PDestination(String whereTo) { label = whereTo;

}

public String readLabelО { return label; }

}

public Destination destination(String s) { return new PDestination(s);

}

public Contents contents О {

return new PContentsО;

public class TestParcel {

public static void main(String[] args) { Parcel4 p = new Parcel4(); Contents с = p.contents О; Destination d = p.destinationC'TacMaHMfl"); // Запрещено - нет доступа к private-классу: //! Parcel4.PContents pc = p.new PContentsО;

}

} ///-

В класс Parcel4 было добавлено кое-что новое: внутренний класс PContents является закрытым (private), поэтому он недоступен для всех, кроме внешнего класса Рагсе14. Класс PDestination объявлен как protected, следовательно, доступ к нему имеют только класс Parcel4, классы из одного пакета с Рагсе14 (так как спецификатор protected также дает доступ з пределах пакета) и наследники класса Рагсе14. Таким образом, программист-клиент обладает ограниченной ин­формацией и доступом к этим членам класса. Более того, нельзя даже выпол­нить нисходящее преобразование к закрытому (private) внутреннему классу (или protected, кроме наследников), поскольку его имя недоступно, как показано в классе Test. Таким образом, закрытый внутренний класс позволяет разработ­чику класса полностью запретить использование определенных типов и скрыть все детали реализации класса. Вдобавок, расширение интерфейса с точки зре­ния программиста-клиента не будет иметь смысла, поскольку он не сможет по­лучить доступ к дополнительным методам, не принадлежащим к открытой части класса. Наконец, у компилятора Java появится возможность оптимизи­ровать код.

Внутренние классы в методах и областях действия

Ранее мы рассмотрели ряд типичных применений внутренних классов. В ос­новном ваш код будет содержать «простые» внутренние классы, смысл которых понять нетрудно. Однако синтаксис внутренних классов скрывает множество других, не столь тривиальных способов их использования: внутренние классы можно создавать внутри метода или даже в пределах произвольного блока. На то есть две причины:

•        как было показано ранее, вы реализуете некоторый интерфейс, чтобы за­тем создавать и возвращать ссылку его типа;

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

В следующих примерах рассмотренная недавно программа будет изменена, благодаря чему у нас появятся:

•        класс, определенный внутри метода;

•        класс, определенный внутри области действия (блока), которая находит­ся внутри метода;

•        безымянный класс, реализующий интерфейс;

•        безымянный класс, расширяющий класс, у которого отсутствует конст­руктор по умолчанию;

•        безымянный класс, выполняющий инициализацию полей;

•       безымянный класс, осуществляющий конструирование посредством инициализации экземпляра (безымянные внутренние классы не могут иметь конструкторы).

Первый пример демонстрирует создание целого класса в контексте метода (вместо создания в контексте другого класса). Такие внутренние классы назы­ваются локальными:

//• innerclasses/Parce!5.java

// Вложение класса в тело метода.

public class Parcel5 {

public Destination dest(String s) {

class PDestination implements Destination { private String label; private PDestination(String whereTo) { label = whereTo;

}

public String readLabelO { return label; }                              _                _Л

продолжение &

}

return new PDestination(s).

}

public static void main(String[] args) { Parcel5 p = new Parcel50; Destination d = p destinationC'TacMaHHH");

}

} ///.-

Теперь класс PDestination является частью метода destination(), а не частью класса Parcel5. Поэтому доступ к классу PDestination возможен только из метода destination(). Обратите внимание на восходящее преобразование, производимое в команде return, — из метода возвращается лишь ссылка на базовый класс Destination, и ничего больше. Конечно, тот факт, что имя класса PDestination на­ходится внутри метода destination(), не означает, что объект PDestination после выхода из этого метода станет недоступным.

Идентификатор PDestination может использоваться для внутренних классов каждого отдельного класса в одном подкаталоге, без порождения конфликта имен.

Следующий пример демонстрирует, как можно вложить внутренний класс в произвольную область действия:

//. innerclasses/Parcel6 java

// Вложение класса в область действия

public class Parcel6 {

private void internalTracking(boolean b) { if(b) {

class TrackingSlip {

private String id;

TrackingSlipCString s) { id = s;

}

String getSlipO { return id; }

}

TrackingSlip ts = new TrackingSlipC'ожидание");

String s = ts getSlipO;

}

// Здесь использовать класс нельзя!

// Вне области видимости.

//! TrackingSlip ts = new Tracki ngSlipCx").

}

public void trackO { internalTracking(true), }

public static void main(String[] args) { Parcel6 p = new Parcel60; p trackO;

}

} ///:-

Класс TrackingSlip вложен в область действия команды if. Это не значит, что класс создается в зависимости от условия — он компилируется вместе со всем остальным кодом. Однако при этом он недоступен вне контекста, в котором был определен. В остальном он выглядит точно так же, как и обычный класс.

Безымянные внутренние классы

Следующий пример выглядит немного странно:

// innerclasses/Parcel7 java

// Метод возвращает экземпляр безымянного внутреннего класса

public class Parcel7 {

public Contents contents О {

return new Contents О { // Вставить определение класса private int i = 11; public int valueO { return i; } }. // В данной ситуации точка с запятой необходима

}

public static void main(String[] args) { Parcel7 p = new Parcel7(); Contents с = p.contents О;

}

} ///-

Метод contents() совмещает создание возвращаемого значения с определени­ем класса, который это возвращаемое значение и представляет! Вдобавок, этот класс является безымянным — у него отсутствует имя. Ситуация запутывается еще тем, что поначалу мы будто бы приступаем к созданию объекта Contents, а потом, остановившись перед точкой с запятой, говорим: «Стоп, а сюда я под­кину определение класса».

Такая необычная форма записи значит буквально следующее: «Создать объ­ект безымянного класса, который унаследован от Contents». Ссылка, которая возвращается при этом из выражения new, автоматически повышается до базо­вого типа Contents. Синтаксис записи безымянного внутреннего класса являет­ся укороченной формой записи такой конструкции:

//: innerclasses/Parcel7b.java

II Расширенная версия Parcel7.java

public class Parcel7b {

class MyContents implements Contents { private int i = 11; public int valueO { return i; }

}

public Contents contents О { return new MyContentsО; } public static void main(String[] args) { Parcel 7b p = new Parcel7b(); Contents с = p contentsO;

}

} ///-

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

// innerclasses/Parcel8 java

// Вызов конструктора базового класса.

public class Parcel8 {                                                                                                 продолжение &

public Wrapping wrapping(int x) {

// Вызов конструктора базового класса, return new Wrapping(x) { // аргумент конструктора public int valueO {

return super.valueO * 47;

}

}; // Требуется точка с запятой

}

public static void main(String[] args) { Parcel8 p = new Parcel80; Wrapping w = p.wrapping(lO);

}

} ///:-

Требуемый аргумент просто передается в конструктор базового класса, как в рассмотренном примере х в выражении new Wrapping(x). Хотя это обычный класс с реализацией, Wrapping также используется в качестве общего «интер­фейса» для своих производных классов:

II: innerclasses/Wrapping.java public class Wrapping { private int i,

public Wrapping(int x) { i = x; } public int valueO { return i; } } ///:-

Класс Wrapping имеет конструктор с аргументом — просто для того, чтобы ситуация стала чуть более интересной.

Точка с запятой в конце безымянного внутреннего класса поставлена вовсе не для того, чтобы обозначить конец тела класса (как делается в С++). Вместо этого она указывает на конец выражения, в котором содержится внутренний класс. Таким образом, в данном случае ее использование ничем не отличается от обычного.

Инициализацию также можно провести в точке определения полей безы­мянного класса:

II: innerclasses/Parcel9.java

II Безымянный внутренний класс, выполняющий инициализацию. II Более короткая версия программы Parcel5 java

public class Parcel9 {

II Для использования в безымянном внутреннем классе II аргументы должны быть неизменны (final); public Destination destination(final String dest) { return new Destination0 {

private String label = dest;

public String readLabelO { return label; }

}:

}

public static void main(String[] args) { Parcel9 p = new Parcel90; Destination d = p.destinationCTacMaHHfl").

}

Если вы определяете безымянный внутренний класс и хотите при этом ис­пользовать объекты, определенные вне этого внутреннего класса, компилятор требует, чтобы переданные на них ссылкй объявлялись неизменными (final), как это сделано аргументе destination(). Без такого объявления вы получите со­общение об ошибке при компиляции программы.

Пока мы ограничиваемся простым присваиванием значений полям, указан­ный подход работает. А если понадобится выполнить некоторые действия, свойственные конструкторам? В безымянном классе именованный конструктор определить нельзя (раз у самого класса нет имени!), но инициализация экземп­ляра (instance initialization) фактически позволяет добиться желаемого эф­фекта:

//. innerclasses/AnonymousConstructor.java

II Создание конструктора для безымянного внутреннего класса.

import static net.mindview.util.Print.*,

abstract class Base {

public Base(int i) {

print("Конструктор Base, i = " + i);

}

public abstract public void f();

}

public class AnonymousConstructor {

public static Base getBase(int i) { return new Base(i) {

{ рпгйС'Инициализация экземпляра"); } public void f() {

print ("Безымянный fO").

}

}.

}

public static void main(String[] args) { Base base = getBase(47); base.fO;

}).

}

} /* Output.

Конструктор Base, i = 47

Инициализация экземпляра

Безымянный f()

*///.-

В таком случае переменная i не обязана быть неизменной (final). И хотя i пе­редается базовому конструктору безымянного класса, она никогда не использу­ется напрямую внутри безымянного класса.

Вернемся к нашим объектам Parcel, на этот раз выполнив для них инициа­лизацию экземпляра. Отметьте, что параметры метода destination() должны быть объявлены неизменными, так как они используются внутри безымянно­го класса:

II- innerclasses/ParcellO.java

II Демонстрация "инициализации экземпляра" для

II конструирования безымянного внутреннего класса.                                     продолжение &

public class Parcel 10 { public Destination

destination(final String dest, final float price) { return new Destination() { private int cost,

// Инициализация экземпляра для каждого объекта. {

cost = Math round(price), if(cost > 100)

System out println("Превышение бюджета!"),

}

private String label = dest,

public String readLabelO { return label, }

}.

}

public static void main(String[] args) {

Parcel 10 p = new Parcel 100.

Destination d = p destination"Тасмания". 101 395F),

}

} /* Output- Превышение бюджета! */// -

Внутри инициализатора экземпляра виден код, недоступный при инициали­зации полей (то есть команда if). Поэтому инициализатор экземпляра фактиче­ски является конструктором безымянного внутреннего класса. Конечно, воз­можности его ограничены; перегружать такой инициализатор нельзя, и поэтому он будет присутствовать в классе только в единственном числе.

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

Снова о методе-фабрике

Посмотрите, насколько приятнее выглядит пример interfaces/Factories.java при использовании безымянных внутренних классов:

// innerclasses/Factories java import static net.mindview util Print *;

interface Service { void methodic), void method2(),

}

interface SemceFactory { Service getServiceO;

}

class Implementationl implements Service { private ImplementationlO {}

public void methodic) {printC"Implementationl methodl");} public void method2() {print("Implementationl method2");}

public static ServiceFactory factory = new ServiceFactoryO {

public Service getServiceO {

return new ImplementationlO;

class Implementation2 implements Service { private Implementation20 {}

public void methodlO {print("Implementation2 methodl"),) public void method2() {print("Implementation2 method2"),j public static ServiceFactory factory = new ServiceFactoryO {

public Service getServiceO {

return new Implementation2();

public class Factories {

public static void serviceConsumer(ServiceFactory fact) { Service s = fact.getServiceO; s methodlO; s method2();

}

public static void main(String[] args) {

serviceConsumer(Implementationl.factory); // Реализации полностью взаимозаменяемы: servi ceConsumer(Implementati on2.factory);

}

} /* Output- Implementationl methodl Implementationl method2 Implementation2 methodl Implementation2 method2 */// ~

Теперь конструкторы Implementationl и Implementation2 могут быть закрытыми, и фабрику необязательно оформлять в виде именованного класса. Кроме того, часто бывает достаточно одного фабричного объекта, поэтому в данном случае он создается как статическое поле в реализации Service. Наконец, итоговый син­таксис выглядит более осмысленно.

Пример interfaces/Games.java тоже можно усовершенствовать с помощью бе­зымянных внутренних классов:

//. innerclasses/Games.java

// Использование анонимных внутренних классов в библиотеке Game import static net.mindview.util.Print.*;

interface Game { boolean moveO; }interface GameFactory { Game getGameO; }

class Checkers implements Game { private Checkers О {} private int moves = 0;

private static final int MOVES = 3;                                                                  продолжение &

class Chess implements Game { private ChessO {} private int moves = 0; private static final int MOVES = 4; public boolean moveO {

print("Chess move " + moves); return ++moves != MOVES;

}

public static GameFactory factory = new GameFactoryO { public Game getGameO { return new ChessO; }

}:

}

public class Games {

public static void piayGame(GameFactory factory) { Game s = factory.getGameO; while(s. moveO)

}

public static void main(String[] args) { pi ayGame(Checkers.factory); piayGame(Chess.factory);

}

} /* Output: Checkers move 0 Checkers move 1 Checkers move 2 Chess move 0 Chess move 1 Chess move 2 Chess move 3 *///•-

Вспомните совет, данный в конце предыдущей главы: отдавать предпочте­ние классам перед интерфейсами. Если архитектура системы требует примене­ния интерфейса, вы это поймете. В остальных случаях не применяйте интер­фейсы без крайней необходимости.

public boolean moveО {

print("Checkers move " + moves); return ++moves != MOVES;

}

public static GameFactory factory = new GameFactoryO { public Game getGameO { return new Checkers О; }

Вложенные классы

Если связь между объектом внутреннего класса и объектом внешнего класса не нужна, можно сделать внутренний класс статическим (объявить его как static). Часто такой класс называют вложенным^[2] (nested). Чтобы понять смысл ключевого

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

•       для создания объекта статического внутреннего класса не нужен объект внешнего класса;

•       из объекта вложенного класса нельзя обращаться к не-статическим чле­нам внешнего класса.

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

//• i nnerclasses/Parcel 11.java

// Вложенные (статические внутренние) классы

public class Parcel 11 {

private static class PContents implements Contents { private int i = 11; public int valueO { return i; }

}

protected static class ParcelDestination implements Destination { private String label;

private Parcel Destination(String whereTo) { label = whereTo,

}

public String readLabelO { return label; }

// Вложенные классы могут содержать другие статические элементы;

public static void f() {}

static int x = 10;

static class AnotherLevel {

public static void f() {} static int x = 10;

}

}

public static Destination destination(String s) { return new ParcelDestination(s);

}

public static Contents contO {

return new Parcel Contents О,

}

public static void main(String[] args) { Contents с = contentsO, Destination d = destinationC'TacMaHHfl"),

}

} ///;-

В методе main() не требуется объекта класса Parcelll; вместо этого для вызова методов, возвращающих ссылки на Contents и Destination, используется обыч­ный синтаксис обращения к статическим членам класса.

Как было сказано ранее, в обычном (не-статическом) внутреннем классе для обращения к объекту внешнего класса используется специальная ссылка this. Во вложенном классе такая ссылка недействительна (по аналогии со статиче­скими методами).

Классы внутри интерфейсов

Обычно интерфейс не может содержать программный код, но вложенный класс может стать его частью. Любой класс, размещенный внутри интерфейса, авто­матически является public и static. Так как класс является статическим, он не на­рушает правил обращения с интерфейсом — этот вложенный класс просто ис­пользует пространство имен интерфейса. Во внутреннем классе даже можно реализовать окружающий интерфейс:

//• innerclasses/ClassInlnterface.java // {main: ClassInlnterfaceSTest}

public interface Classlnlnterface { void howdyO;

class Test implements Classlnlnterface { public void howdyO {

System. out.printlnCnpHBeT!");.

}

public static void main(String[] args) { new Test О .howdyO.

}

}

} /* Output Привет! *///•-

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

Ранее в книге я предлагал помещать в каждый класс метод main(), позволяю­щий при необходимости протестировать данный класс. Недостатком такого подхода является дополнительный скомпилированный код, увеличивающий размеры программы. Если для вас это нежелательно, используйте статический внутренний класс для хранения тестового кода:

//• innerclasses/TestBed.java

// Помещение тестового кода во вложенный класс

// {main: TestBedSTester}

public class TestBed {

public void f() { System.out.printlnC'fO"): } public static class Tester {

public static void main(String[] args) { TestBed t = new TestBedO; t.fO:

}

}

} /* Output: f() *///:-

При компиляции этого файла создается отдельный класс с именем TestBed$ Tester (для запуска тестового кода наберите команду java TestBed$Tester). Вы мо­жете использовать этот класс для тестирования, но включать его в окончатель­ную версию программы необязательно; файл TestBed$Tester.class можно просто удалить перед окончательной сборкой программы.

Доступ вовне из многократно вложенных классов

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

//: innerclasses/MultiNestingAccess.java // Вложенные классы могут обращаться ко всем членам всех // классов, в которых они находятся.

class MNA {

private void f() {} class A {

private void g() {} public class В {

void h() {

g();

f():

}

}

}

}

public class MultiNestingAccess {

public static void main(String[] args) { MNA mna = new MNA(); MNA.A mnaa = mna.new AO; MNA.А.В mnaab = mnaa.new BO; mnaab h();

}

} ///.-

Как видно из примера, в классе MNA.A.B методы f() и д() вызываются без до­полнительных описаний (несмотря на то, что они объявлены как private). Этот пример также демонстрирует синтаксис, который следует использовать при создании объектов внутренних классов произвольного уровня вложенности из другого класса. Синтаксис .new обеспечивает правильную область действия, и вам не приходится уточнять имя класса при вызове конструктора.

Внутренние классы: зачем?

К настоящему моменту мы подробно рассмотрели синтаксис и семантику рабо­ты внутренних классов, но это не дало ответа на вопрос, зачем они вообще нужны.

Что же заставило создателей Java добавить в язык настолько фундаментальное свойство?

Обычно внутренний класс наследует от класса или реализует интерфейс, а код внутреннего класса манипулирует объектом внешнего класса, в котором он был создан. Значит, можно сказать, что внутренний класс — это нечто вроде «окна» во внешний класс.

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

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

Без возможности внутренних классов наследовать реализацию более чем од­ного реального или абстрактного класса некоторые задачи планирования и про­граммирования становятся практически неразрешимыми. Поэтому внутренний класс выступает как «довесок» решения проблемы множественного наследова­ния. Интерфейсы берут на себя часть этой задачи, тогда как внутренние классы фактически обеспечивают «множественное наследование реализации». Други­ми словами, внутренние классы позволяют наследовать от нескольких не-ин- терфейсов.

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

//: innerclasses/MultiInterfaces.java

// Два способа реализации нескольких интерфейсов.

interface А {}

interface В {}

class X implements А, В {}

class Y implements A { В makeBO {

// Безымянный внутренний класс: return new ВО {};

}

}

public class MultiInterfaces { static void takesA(A a) {} static void takesB(B b) {} public static void main(String[] args) { X x = new X(); Y у = new Y(); takesA(x);

takesA(y), takesB(x), takesB(y makeBO).

}

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

Но если вместо интерфейсов имеются реальные или абстрактные классы и новый класс должен как-то реализовать функциональность двух других, при­дется прибегнуть к внутренним классам:

//: innerclasses/MultiImplementation.java // При использовании реальных или абстрактных классов // "множественное наследование реализации" возможно // только с применением внутренних классов package innerclasses;

class D {} abstract class E {}

class Z extends D {

E makeEO { return new E() {}, }

}

public class MultiImplementation { static void takesD(D d) {} • static void takesE(E e) {} public static void main(String[] args) { Z z = new Z(); takesD(z); takesE(z.makeEO);

}

} ///:-

Если нет необходимости решать задачу «множественного наследования реа­лизации», скорее всего, вы без особого труда напишите программу, не прибегая к особенностям внутренних классов. Однако внутренние классы открывают пе­ред вами ряд дополнительных возможностей:

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

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

•       Место создания объекта внутреннего класса не привязано к месту и вре­мени создания объекта внешнего класса.

• Внутренний класс не использует тип отношений классов «является тем-то», способных вызвать недоразумения; он представляет собой от­дельную сущность.

Например, если бы в программе Sequence.java отсутствовали внутренние классы, пришлось бы заявить, что «класс Sequence есть класс Selector», и при этом ограничиться только одним объектом Selector для конкретного объекта Sequence. А вы можете с легкостью определить второй метод, reverseSelector(), создающий объект Selector для перебора элементов Sequence в обратном порядке. Такую гибкость обеспечивают только внутренние классы.

Замыкания и обратные вызовы

Замыканием (closure) называется вызываемый объект, который сохраняет ин­формацию о контексте, он был создан. Из этого определения видно, что внут­ренний класс является объектно-ориентированным замыканием, поскольку он не только содержит информацию об объекте внешнего класса («место созда­ния»), но к тому же располагает ссылкой на весь объект внешнего класса, с по­мощью которой он может манипулировать всеми членами этого объекта, в том числе и закрытыми (private).

При обсуждении того, стоит ли включать в Java некое подобие указателей, самым веским аргументом «за» была возможность обратных вызовов (callback). В механизме обратного вызова некоторому стороннему объекту передается ин­формация, позволяющая ему затем обратиться с вызовом к объекту, который произвел изначальный вызов. Это очень мощная концепция программирова­ния, к которой мы еще вернемся. С другой стороны, при реализации обратного вызова на основе указателей вся ответственность за его правильное использо­вание возлагается на программиста. Как было показано ранее, язык Java ориен­тирован на безопасное программирование, поэтому указатели в него включены не были.

Замыкание, предоставляемое внутренним классом, — хорошее решение, го­раздо более гибкое и безопасное, чем указатель. Рассмотрим пример:

//: innerclasses/CalIbacks.java

// Использование внутренних классов

// для реализации обратных вызовов

package innerclasses;

import static net.mindview.util.Print.*;

interface Incrementable { void incrementO,

}

// Простая реализация интерфейса: class Call eel implements Incrementable { private int i = 0. public void incrementO { i++;

print(i);

class Mylncrement {

public void increment О { System, out. pri ntlnC'flpy гая операция") }; public static void f(MyIncrement mi) { mi.incrementО; }

}

// Если класс должен вызывать метод increment О // по-другому, необходимо использовать внутренний класс: class Callee2 extends Mylncrement { private int i = 0, private void increment О { super.increment(): i++;

print(i):

}

private class Closure implements Incrementable { public void increment О {

// Указывается метод внешнего класса;

// в противном случае возникает бесконечная рекурсия.

Са11ее2.this.increment();

}

}

Incrementable getCallbackReferenceO { return new ClosureO;

class Caller {

private Incrementable callbackReference;

Caller(Incrementable cbh) { callbackReference = cbh, }

void go() { callbackReference incrementO; }

}

public class Callbacks {

public static void main(String[] args) { Call eel cl = new CalleelO; Callee2 c2 = new Callee2(); Mylncrement.f(c2), Caller callerl = new Caller(cl); Caller caller2 = new Caller(c2.getCallbackReferenceO); callerl. goO; callerl.goO; caller2.go(); caller2.go();

}

} /* Output: Другая операция 1 1 2

Другая операция 2

Другая операция 3

*///:-

Этот пример также демонстрирует различия между реализацией интерфейса внешним или внутренним классом. Класс Calleel — наиболее очевидное реше­ние задачи с точки зрения программирования. Класс Callee2 наследует от класса Mylncrement, в котором уже есть метод increment(), выполняющий действие, ни­как не связанное с тем, что ожидает от него интерфейс Incrementable. Когда класс Mylncrement наследуется в Callee2, метод increment() нельзя переопреде­лить для использования в качестве метода интерфейса Incrementable, поэтому нам приходится предоставлять отдельную реализацию во внутреннем классе. Также отметьте, что создание внутреннего класса не затрагивает и не изменяет существующий интерфейс внешнего класса.

Все элементы, за исключением метода getCallbackReference(), в классе Callee2 являются закрытыми. Для любой связи с окружающим миром необходим ин­терфейс Incrementable. Здесь мы видим, как интерфейсы позволяют полностью отделить интерфейс от реализации.

Внутренний класс Closure просто реализует интерфейс Incrementable, предос­тавляя при этом связь с объектом Callee2 — но связь эта безопасна. Кто бы ни получил ссылку на Incrementable, он в состоянии вызвать только метод incre­mentO, и других возможностей у него нет (в отличие от указателя, с которым программист может вытворять все, что угодно).

Класс Caller получает ссылку на Incrementable в своем конструкторе (хотя пе­редача ссылки для обратного вызова может происходить в любое время), а по­сле этого использует ссылку для «обратного вызова» объекта Callee.

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

Внутренние классы и система управления

В качестве более реального пример использования внутренних классов мы рас­смотрим то, что я буду называть здесь системой управления (control frame­work).

Каркас приложения (application framework) — это класс или набор классов, разработанных для решения определенного круга задач. При работе с каркаса­ми приложений обычно используется наследование от одного или нескольких классов, с переопределением некоторых методов. Код переопределенных мето­дов адаптирует типовое решение, предоставляемое каркасом приложения, к ва­шим конкретным потребностям. Система управления представляет собой опре­деленный тип каркаса приложения, основным движущим механизмом которого является обработка событий. Такие системы называются системами, управляе­мыми по событиям (event-driven system). Одной из самых типичных задач в при­кладном программировании является создание графического интерфейса поль­зователя (GUI), всецело и полностью ориентированного на обработку событий.

Чтобы на наглядном примере увидеть, как с применением внутренних клас­сов достигается простота создания и использования библиотек, мы рассмотрим систему, ориентированную на обработку событий по их «готовности». Хотя в практическом смысле под «готовностью» может пониматься все, что угодно, в нашем случае она будет определяться по показаниям счетчика времени. Далее приводится общее описание управляющей системы, никак не зависящей от того, чем именно она управляет. Нужная информация предоставляется по­средством наследования, при реализации метода action().

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

//: innerclasses/control 1er/Event.java

// Общие для всякого управляющего события методы.

package innerclasses/controller;

public abstract class Event {

private long eventTime;

protected final long delayTime;

public Event(long delayTime) {

this.delayTime = delayTime; startO;

}

public void startO { // Позволяет перезапуск eventTime = System nanoTimeO + delayTime;

}

public boolean readyО {

return System.nanoTimeO >= eventTime;

}

public abstract void actionO; } ///:-

Конструктор просто запоминает время (от момента создания объекта), через которое должно выполняться событие Event, и после этого вызывает метод start(), который прибавляет к текущему времени интервал задержки, чтобы вы­числить время возникновения события. Метод start() отделен от конструктора, благодаря чему становится возможным «перезапуск» события после того, как его время уже истекло; таким образом, объект Event можно использовать много­кратно. Скажем, если вам понадобится повторяющееся событие, достаточно до­бавить вызов start() в метод action().

Метод ready() сообщает, что пора действовать — вызывать метод action(). Ко­нечно, метод ready() может быть переопределен любым производным классом, если событие Event активизируется не по времени, а по иному условию.

Следующий файл описывает саму систему управления, которая распоряжа­ется событиями и инициирует их. Объекты Event содержатся в контейнере List<Event>. На данный момент достаточно знать, что метод add() присоединяет объект Event к концу контейнера с типом List, метод size() возвращает количест­во элементов в контейнере, синтаксис foreach() осуществляет последовательную выборку элементов List, а метод remove() удаляет заданный элемент из контей­нера:

//: innerclasses/control 1er/Control1er.java // Обобщенная система управления package innerclasses.controller; import java.util.*;

public class Controller {

// Класс из пакета java.util для хранения событий Event: private List<Event> eventList = new ArrayList<Event>(); public void addEvent(Event c) { eventList.add(c): } public void run() {

while(eventList.size() > 0) {

for(Event e : new ArrayList<Event>(eventList)) if(e.readyO) {

System.out.println(e): e.actionO; eventList.remove(e):

}

}

} ///:-

Метод run() в цикле перебирает копию eventList в поисках событий Event, го­товых для выполнения. Для каждого найденного элемента он выводит инфор­мацию об объекте методом toString(), вызывает метод action(), а после этого уда­ляет событие из списка.

Заметьте, что в этой архитектуре совершенно неважно, что конкретно вы­полняет некое событие Event. В этом и состоит «изюминка» разработанной сис­темы; она отделяет постоянную составляющую от изменяющейся. «Вектором изменения» являются различные действия разнообразных событий Event, выра­жаемые посредством создания разных субклассов Event.

На этом этапе в дело вступают внутренние классы. Они позволяют добиться двух целей:

1.     Вся реализация системы управления создается в одном классе, с полной инкапсуляцией всей специфики данной реализации. Внутренние классы используются для представления различных разновидностей action(), не­обходимых для решения задачи.

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

Рассмотрим конкретную реализацию системы управления, разработанную для управления функциями оранжереи^[3]. Все события — включение света, воды и нагревателей, звонок и перезапуск системы — абсолютно разнородны. Однако система управления разработана так, что различия в коде легко изолируются. Внутренние классы помогают унаследовать несколько производных версий од­ного базового класса Event в пределах одного класса. Для каждого типа события от Event наследуется новый внутренний класс, и в его реализации action() запи­сывается управляющий код.

Как это обычно бывает при использовании каркасов приложений, класс GreenhouseControls наследует от класса Controller:

//: innerclasses/GreenhouseControls.java // Пример конкретного приложения на основе системы // управления, все находится в одном классе. Внутренние // классы дают возможность инкапсулировать различную // функциональность для каждого отдельного события, import innerclasses.control 1er.*,

public class GreenhouseControls extends Controller {

private boolean light = false,

public class LightOn extends Event {

public LightOndong delayTime) { super (delayTime). } public void actionO {

// Сюда помещается аппаратный вызов, выполняющий // физическое включение света, light = true;

}

public String toStringO { return "Свет включен"; }

}

public class LightOff extends Event {

public LightOffdong delayTime) { super(delayTime); } public void actionO {

// Сюда помещается аппаратный вызов, выполняющий // физическое выключение света light = false;

}

public String toStringO { return "Свет выключен", }

}

private boolean water = false;

public class WaterOn extends Event {

public WaterOn(long delayTime) { super(delayTime), } public void actionO {

// Здесь размещается код включения '// системы полива, water = true;

}

public String toStringO {

return "Полив включен";

}

}

public class WaterOff extends Event {

public WaterOffdong delayTime) { super(delayTime); } public void actionO {

// Здесь размещается код выключения // системы полива water = false;

}

public String toStringO {

return "Полив отключен";

}

}

private String thermostat = "День";

public class Thermostaticght extends Event {

public Thermostaticght(long delayTime) { super(delayTime);

}

public void actionO {

// Здесь размещается код управления оборудованием thermostat = "Ночь";

public String toStringO {

return "Термостат использует ночной режим";

}

}

public class ThermostatDay extends Event {

public ThermostatDay(long delayTime) { super(delayTime);

}

public void actionO {

// Здесь размещается код управления оборудованием thermostat = "День";

}

public String toStringO {

return "Термостат использует дневной режим";

}

}

// Пример метода actionO, вставляющего

// самого себя в список событий.

public class Bell extends Event {

public Bell(long delayTime) { super(delayTime); } public void actionO {

addEvent(new Bell(delayTime));

}

public String toStringO { return "Бам!"; }

}

public class Restart extends Event { private Event[] eventList;

public Restartdong delayTime. Event[] eventList) { super(delayTime); this.eventList = eventList; for(Event e : eventList) addEvent(e);

}

public void actionO {

for(Event e : eventList) {

e. start О; // Перезапуск каждый раз addEvent(e);

}

startO; // Возвращаем это событие Event addEvent(this);

}

public String toStringO {

return "Перезапуск системы";

}

}

public static class Terminate extends Event {

public Terminatedong delayTime) { super(delayTime); }

public void actionO { System.exit(0); }

public String toStringO { return "Отключение"; }

}

} ///;-

Заметьте, что поля light, thermostat и ring принадлежат внешнему классу GreenhouseControls, и все же внутренние классы имеют возможность обращаться к ним, не используя особой записи и не запрашивая особых разрешений. Боль­шинство методов action() требует управления оборудованием оранжереи, что, скорее всего, привлечет в программу сторонние низкоуровневые вызовы.

В основном классы Event похожи друг на друга, однако классы Bell и Restart представляют собой особые случаи. Bell выдает звуковой сигнал и добавляет себя в список событий, чтобы звонок позднее сработал снова. Заметьте, что внутренние классы действуют почти как множественное наследование: классы Bell и Restart имеют доступ ко всем методам класса Event, а также ко всем мето­дам внешнего класса GreenhouseControls.

Классу Restart передается массив объектов Event, которые он добавляет в контроллер. Так как Restart также является объектом Event, вы можете доба­вить этот объект в список событий в методе Restart.action(), чтобы система регу­лярно перезапускалась.

Следующий класс настраивает систему, создавая объект GreenhouseControls и добавляя в него разнообразные типы объектов Event. Это пример шаблона проектирования «команда» — каждый объект в EventList представляет собой за­прос, инкапсулированный в объекте:

//: с08:GreenhouseControl1er.java // Настраивает и запускает систему управления. // {Args: 5000}

import innerclasses.control 1er.*:

public class GreenhouseController {

public static void main(String[] args) {

GreenhouseControls gc = new GreenhouseControls(); // Вместо жесткого кодирования фиксированных данных // можно было бы считать информацию для настройки // из текстового файла: gc.addEvent(gc.new Bel 1 (900)): Event[] eventList = {

gc.new ThermostatNight(O), gc.new Light0n(200), gc.new LightOff(400), gc.new WaterOn(600), gc.new WaterOff(800), gc.new ThermostatDay(1400)

}:

gc.addEvent(gc.new Restart(2000, eventList)): if(args.length == 1) gc.addEvent(

new GreenHouseControls.Terminate( new Integer(args[0])));

gc.runO;

}

} * Output: Вам!

Термостат использует ночной режим

Свет включен

Свет выключен

Полив включен

Полив отключен

Термостат использует дневной режим Перезапуск системы Отключение ///:-

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

Этот пример поможет понять всю ценность механизма внутренних классов, особенно в случае с системами управления.

Наследование от внутренних классов

Так как конструктор внутреннего класса связывается со ссылкой на окружаю­щий внешний объект, наследование от внутреннего класса получается чуть сложнее, чем обычное. Проблема состоит в том, что «скрытая» ссылка на объ­ект объемлющего внешнего класса должна быть инициализирована, а в произ­водном классе больше не существует объемлющего объекта по умолчанию. Для явного указания объемлющего внешнего объекта применяется специальный синтаксис:

//: innerclasses/Inheritlnner.java // Наследование от внутреннего класса.

class Withinner { class Inner {}

}

public class Inheritlnner extends Withlnner.Inner { //! InheritlnnerO {} // He компилируется InheritInner(WithInner wi) { wi.super();

}

public static void main(String[] args) { Withlnner wi = new WithlnnerO; Inheritlnner ii = new Inheritlnner(wi);

}

} ///:-

Здесь класс Inheritlnner расширяет только внутренний класс, а не внешний. Но когда дело доходит до создания конструктора, предлагаемый по умолчанию конструктор не подходит, и вы не можете просто передать ссылку на внешний объект. Необходимо включить в тело конструктора выражение

ссылкаНаОбъемлющийКласс.super();

в теле конструктора. Оно обеспечит недостающую ссылку, и программа отком- пилируется.

Можно ли переопределить внутренний класс?

Что происходит, если вы создаете внутренний класс, затем наследуете от его внеш­него класса, а после этого заново описываете внутренний класс в производном

Можно ли переопределить внутренний класс? 273

классе? Другими словами, можно ли переопределить внутренний класс? Это было бы довольно интересно, но «переопределение» внутреннего класса, как если бы он был еще одним методом внешнего класса, фактически не имеет ни­какого эффекта:

//. innerclasses/BigEgg.java // Внутренний класс нельзя переопределить // подобно обычному методу, import static net.mindview util.Print.*:

class Egg {

private Yolk y; protected class Yolk {

public YolkO { printCEgg.YolkO"). }

}

public EggO {

printC'New EggO"): у = new YolkO:

public class BigEgg extends Egg { public class Yolk {

public YolkO { print("BigEgg YolkO"): }

}

public static void main(String[] args) { new BigEggO;

}

} /* Output New EggO Egg. YolkO *///•-

Конструктор по умолчанию автоматически синтезируется компилятором, а в нем вызывается конструктор по умолчанию из базового класса. Можно по­думать, что при создании объекта BigEgg должен использоваться «переопреде­ленный» класс Yolk, но это отнюдь не так, как видно из результата работы про­граммы.

Этот пример просто показывает, что при наследовании от внешнего класса ничего особенного с внутренними классами не происходит. Два внутренних класса — совершенно отдельные составляющие, с независимыми пространства­ми имен. Впрочем, возможность явного наследования от внутреннего класса со­хранилась:

//: innerclasses/BigEgg2.java

// Правильное наследование внутреннего класса,

i mport stati с net.mi ndvi ew.uti1.Pri nt.*;

class Egg2 {

protected class Yolk {

public YolkO { print("Egg2.YolkO"): } public void f() {

print("Egg2 Yolk.fO"):}

}

private Yolk у = new YolkO,                                                                            продолжение &

public Egg2() { print("New Egg2()"); } public void insertYolk(Yolk yy) { у = yy; } public void g() { y.f(); }

}

public class BigEgg2 extends Egg2 {

public class Yolk extends Egg2 Yolk {

public YolkO { print("BigEgg2.Yolk()"); }

public void f() { System.out.println("BigEgg2.Yolk.f()"); }

}

public BigEgg2() { insertYolk(new YolkO); } public static void main(String[] args) { Egg2 e2 = new BigEgg2(); e2.g();

}

} /* Output: Egg2. YolkO New Egg2() Egg2. YolkO BigEgg2. YolkO BigEgg2.Yolk.f() *///•-

Теперь класс BigEgg2.Yolk явно расширяет класс Egg2.Yolk и переопределяет его методы. Метод insertYolk() позволяет классу BigEgg2 повысить один из своих объектов Yolk до ссылки у в классе Egg2, поэтому при вызове y.f() в методе д() используется переопределенная версия f(). Второй вызов Egg2.Yolk() — это вы­зов конструктора базового класса из конструктора класса BigEgg2.Yolk. Мы так­же видим, что при вызове метода д() используется «обновленная» версия мето- даЮ.

Локальные внутренние классы

Как было замечено ранее, внутренние классы также могут создаваться в блоках кода — чаще всего в теле метода. Локальный внутренний класс не может иметь спецификатора доступа, так как он не является частью внешнего класса, но для него доступны все неизменные (final) переменные текущего блока и все члены внешнего класса. Следующий пример сравнивает процессы создания локально­го внутреннего класса и безымянного внутреннего класса:

//: innerclasses/LocalInnerClass.java // Хранит последовательность объектов, import static net.mindview.util.Print.*;

interface Counter { int nextO;

}

public class LocalInnerClass { private int count = 0; Counter getCounter(final String name) { // Локальный внутренний класс: class Local Counter implements Counter { public Local CounterО {

return new Local CounterО;

}

// To же самое с безымянным внутренним классом: Counter getCounter2(final String name) { return new CounterO {

// У безымянного внутреннего класса не может быть // именованного конструктора, «легальна» только

// инициализация экземпляром: {

print ("Counter О");

}

public int next О {

printnb(name): // неизменный аргумент return count++:

}

public static void main(String[] args) {

LocalInnerClass lie = new LocalInnerClassO: Counter

cl = lic.getCounter(" локальный"), c2 = lic.getCounter2(" безымянный"): for(int i = 0: i < 5: i++) print(cl.nextO): for(int i = 0: i < 5: i++) print(c2.next());

}

}

} /* Output: Local CounterO CounterO локальный 0 локальный 1 локальный 2 локальный 3 локальный 4 безымянный 5 безымянный 6 безымянный 7 безымянный 8 безымянный 9 *///:-

// У локального внутреннего класса // может быть собственный конструктор: pri nt("Local Counter()");

}

public int next О {

printnb(name): // неизменный аргумент return count++;

Объект Counter возвращает следующее по порядку значение. Он реализован и как локальный класс, и как безымянный внутренний класс, с одинаковым по­ведением и характеристиками. Поскольку имя локального внутреннего класса недоступно за пределами метода, доводом для применения локального класса вместо безымянного внутреннего может быть необходимость в именованном

конструкторе и (или) перегруженных конструкторах; безымянные внутренние классы допускают только инициализацию экземпляром.

Другая причина для использования локального внутреннего класса вместо безымянного внутреннего — необходимость создания более чем одного объекта такого класса.

Идентификаторы внутренних классов

Так как каждый класс компилируется в файл с расширением .class, содержащий полную информацию о создании его экземпляров (эта информация помещается в «мета-класс», называемый объектом Class), напрашивается предположение, что внутренние классы также создают файлы .class для хранения информации о своих объектах Class. Имена этих файлов-классов строятся по жестко задан­ной схеме: имя объемлющего внешнего класса, затем символ $ и имя внутрен­него класса. Например, для программы LocallnnerClass.java создаются следую­щие файлы с расширением .class:

Counter.class

LocalInnerClass$2.class

LocalInnerClass$lLocalCounter.class

LocalInnerClass.class

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

Хотя такая схема построения внутренних имен проста и прямолинейна, она вполне надежна и работает практически в любых ситуациях. Так как она явля­ется стандартной для языка Java, все получаемые файлы автоматически стано­вятся платформно-независимыми.

Резюме

Интерфейсы и внутренние классы — весьма нетривиальные концепции, и во мно­гих других объектно-ориентированных языках вы их не найдете. Например, в С++ нет ничего похожего. Вместе они решают те задачи, которые С++ пыта­ется решить с применением множественного наследования. Однако множест­венное наследование С++ создает массу проблем; по сравнению с ним интер­фейсы и внутренние классы Java гораздо более доступны.

Хотя сами по себе эти механизмы не так уж сложны, решение об их исполь­зовании принимается на уровне проектирования (как и в случае с полиморфиз­мом). Со временем вы научитесь сразу оценивать, где большую выгоду даст ин­терфейс, где внутренний класс, а где нужны обе возможности сразу. А пока достаточно хотя бы в общих чертах ознакомиться с их синтаксисом и семан­тикой.

^[1] Эта концепция внутренних классов сильно отличается от концепции вложенных классов С++, кото­рые представляют собой простой механизм для сокрытия имен. Вложенные классы С++ не имеют связи с объектом-оболочкой и прав доступа к его элементам.

^[2] Близкий аналог вложенных классов С++, за тем исключением, что в Java вложенные классы спо­собны обращаться к закрытым членам внешнего класса.

^[3] Я всегда решал эту задачу с особым удовольствием; она впервые появилась в одной из первых моих книгС++ Inside & Out, но Java-реализация выглядит гораздо элегантнее.

Коллекции объектов

Ограниченное количество объектов с фиксированным временем жизни характер­но разве что для относительно простых программ.

В основном ваши программы будут создавать новые объекты на основании критериев, которые станут известны лишь во время их работы. До начала вы­полнения программы вы не знаете ни количества, ни даже типов нужных вам объектов. Следовательно, использовать именованную ссылку для каждого из возможных объектов не удастся:

МуТуре aReference;

так как заранее неизвестно, сколько таких ссылок реально потребуется.

В большинстве языков существуют некоторые пути решения этой крайне насущной задачи. В Java предусмотрено несколько способов хранения объектов (или, точнее, ссылок на объекты). Встроенным типом является массив, который мы уже рассмотрели. Библиотека утилит Java (Java.utiL*) также содержит дос­таточно полный набор классов контейнеров (также известных, как классы кол­лекций, но, поскольку имя Collection (коллекция) используется для обозначения определенного подмножества библиотеки Java, я буду употреблять общий тер­мин «контейнер»). Контейнеры обладают весьма изощренными возможностями для хранения объектов и работы с ними, и с их помощью удается решить огром­ное количество задач.

Параметризованные и типизованные контейнеры

Одна из проблем, существовавших при работе с контейнерами до выхода Java SE5, заключалась в том, что компилятор позволял вставить в контейнер объект неверного типа. Для примера рассмотрим один из основных рабочих контейнеров

ArrayList, в котором мы собираемся хранить объекты Apple. Пока рассматривайте ArrayList как «автоматически расширяемый массив». Работать с ним несложно: создайте объект, вставляйте объекты методом add(), обращайтеь к ним мето­дом get(), используйте индексирование — так же, как для массивов, но без квад­ратных скобок. ArrayList также содержит метод size(), который возвращает теку­щее количество элементов в массиве.

В следующем примере в контейнере размещаются объекты Apple и Orange, которые затем извлекаются из него. Обычно компилятор Java выдает предупре­ждение, потому что в данном примере не используется параметризация, однако в Java SE5 существует специальная директива @SuppressWarnings для подавле­ния предупреждений. Директивы начинаются со знака @ и могут получать ар­гументы; в данном случае аргумент означает, что подавляются только «непро­веряемые» предупреждения:

//: hoiding/ApplesAndOrangesWithoutGenerics. java

// Простой пример работы с контейнером

// (компилятор выдает предупреждения).

// {ThrowsException}

import java.util.*;

class Apple {

private static long counter; private final long id = counter++; public long id() { return id; }

}

class Orange {}

public class ApplesAndOrangesWithoutGenerics { @SuppressWarni ngs("unchecked") public static void main(String[] args) {

ArrayList apples = new ArrayListO; for(int i = 0; i < 3; i++)

apples, add (new AppleO); // He препятствует добавлению объекта Orange: apples.add(new OrangeO); for(int i = 0; i < apples.size(). i++) ((Apple)apples.get(i)).id();

// Объект Orange обнаруживается только во время выполнения

}

}

///:-

Директивы Java SE5 будут рассмотрены позднее.

Apple и Orange — совершенно разные классы; они не имеют ничего общего, кроме происхождения от Object (напомню: если в программе явно не указан ба­зовый класс, то в этом качестве используется Object). Так как в ArrayList хранят­ся объекты Object, метод add() может добавлять в контейнер не только объекты Apple, но и Orange, без ошибок компиляции или времени выполнения. Но при вызове метода get() класса ArrayList вы вместо объекта Apple получаете ссылку на Object, которую необходимо преобразовать в Apple. Все выражение должно быть заключено в круглые скобки, чтобы преобразование было выполнено

Параметризованные и типизованные контейнеры 279

перед вызовом метода id() класса Apple. Во время выполнения, при попытке преобразования объекта Orange в Apple, произойдет исключение.

В главе «параметризованные типы» вы узнаете, что создание классов, исполь­зующих механизм параметризации, может быть довольно сложной задачей. С другой стороны, с применением готовых параметризованных классов проблем обычно не бывает. Например, чтобы определить объект ArrayList, предназначен­ный для хранения объектов Apple, достаточно использовать вместо имени ArrayList запись А г ray Li s t< A p p le>. В угловых скобках перечисляются параметры типов (их может быть несколько), указывающие тип объектов, хранящихся в данном экземпляре контейнера.

Механизм параметризации предотвращает занесение объектов неверного типа в контейнер на стадии компиляции. Рассмотрим тот же пример, но с ис­пользованием параметризации:

// hoiding/ApplesAndOrangesWithGenerics java import java.util.*;

public class ApplesAndOrangesWithGenerics { public static void main(String[] args) {

ArrayList<Apple> apples = new ArrayList<Apple>(), forCint i = 0; i < 3; i++)

apples, add (new AppleO); // Ошибка компиляции: // apples.add(new OrangeO); for(int i = 0; i < apples.size(); i++)

System, out. pri ntl n(appl es. get( i) .idO). // Использование синтаксиса foreach: for(Apple с • apples)

System.out.pri nt1n(с.i d());

}

} /* Output: 0 1 2 0 1 2

*///-

На этот раз компилятор не разрешит поместить объекты Orange в контейнер apples, поэтому вы получите ошибку на стадии компиляции (а не на стадии вы­полнения).

Также обратите внимание на то, что выборка данных из List не требует пре­образования типов. Поскольку контейнер знает тип хранящихся в нем элемен­тов, он автоматически выполняет преобразование при вызове get(). Таким обра­зом, параметризация не только позволяет компилятору проверять тип объектов, помещаемых в контейнеры, но и упрощает синтаксис работы с объек­тами в контейнере. Пример также показывает, что, если индексы элементов вам не нужны, для перебора можно воспользоваться синтаксисом foreach.

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

//: hoiding/GenericsAndUpcasting.java import java.util.*;

class   GrannySmith extends Apple {}

class   Gala extends Apple {}

class   Fuji extends Apple {}

class   Braeburn extends Apple {}

public class GenericsAndUpcasting {

public static void main(String[] args) {

ArrayList<Apple> apples = new ArrayList<Apple>();

apples.add(new GrannySmithO);

apples.add(new GalaO);

apples.add(new Fuji()):

apples.add(new BraeburnO);

for(Apple с : apples)

System.out.println(c);

}

} /* Output: (Sample) GrannySmi th@7d772e Gala@llb86e7 Fuji@35ce36 Braeburn@757aef *///:-

Мы видим, что в контейнер, рассчитанный на хранение объектов Apple, мож­но помещать объекты типов, производных от Apple.

В результатах, полученных с использованием метода toStringO объекта Ob­ject, выводится имя класса с беззнаковым шестнадцатеричным представлением хеш-кода объекта (сгенерированного методом hashCode()).

Основные концепции

В библиотеке контейнеров Java проблема хранения объектов делится на две концепции, выраженные в виде базовых интерфейсов библиотеки:

•       Коллекция: группа отдельных элементов, сформированная по некоторым правилам. Класс List (список) хранит элементы в порядке вставки, в клас­се Set (множество) нельзя хранить повторяющиеся элементы, а класс Queue (очередь) выдает элементы в порядке, определяемом спецификой очереди (обычно это порядок вставки элементов в очередь).

•       Карта: набор пар объектов «ключ-значение», с возможностью выборки по ключу. ArrayList позволяет искать объекты по порядковым номерам, поэтому в каком-то смысле он связывает числа с объектами. Класс Map (карта — также встречаются термины ассоциативный массив и словарь) позволяет искать объекты по другим объектам — например, получить объект значения по объекту ключа, по аналогии с поиском определе­ния по слову.

Хотя на практике это не всегда возможно, в идеале весь программный код должен писаться в расчете на взаимодействие с этими интерфейсами, а точный тип указывается только в точке создания. Следовательно, объект List может быть создан так:

List<Apple> apples = new ArrayList<Apple>():

Обратите внимание на восходящее преобразование ArrayList к List, в отличие от предыдущих примеров. Если позднее вы решите изменить реализацию, дос­таточно сделать это в точке создания:

List<Apple> apples = new LinkedList<Apple>();

Итак, в типичной ситуации вы создаете объект реального класса, повышаете его до соответствующего интерфейса, а затем используете интерфейс во всем остальном коде.

Такой подход работает не всегда, потому что некоторые классы обладают до­полнительной функциональностью. Например, LinkedList содержит дополни­тельные методы, не входящие в интерфейс List, а ТгееМар — методы, не входя­щие в Map. Если такие методы используются в программе, восходящее преоб­разование к обобщенному интерфейсу невозможно.

Интерфейс Collection представляет концепцию последовательности как спо­соба хранения группы объектов. В следующем простом примере интерфейсCollection (представленный контейнером ArrayList) заполняется объектами Integer, с последующим выводом всех элементов полученного контейнера:

//: hoiding/SimpleCol1ection.java

import java.util .*;

public class SimpleCollection {

public static void main(String[] args) {

Collection<Integer> с = new ArrayList<Integer>(); for(int i = 0; i < 10; i++)

c.add(i); // Автоматическая упаковка for(Integer i : c)

System.out.print(i + ". ");

}

} /* Output:

0. 1. 2. 3. 4, 5. 6. 7, 8-. 9.

*///•-

Поскольку в этом примере используются только методы Collection, подойдет объект любого класса, производного от Collection, но ArrayList является самым простейшим типом последовательности.

' Все коллекции поддерживают перебор в синтаксисе foreach, как в приведен­ном примере. Позднее в этой главе будет рассмотрена другая, более гибкая кон­цепция итераторов.

Добавление групп элементов

Семейства Arrays и Collections в java.util содержат вспомогательные методы для включения групп элементов в коллекции. Метод Arrays.asList() получает либо массив, либо список элементов, разделенных запятыми, и преобразует его в объект List. Метод Collections.addAUQ получает объект Collection и либо массив, либо список, разделенный запятыми, и добавляет элементы в Collection. Пример:

//• hoiding/AddingGroups java

// Добавление групп элементов в объекты Collection

import java.util *;

public class AddingGroups {

public static void main(String[] args) { Collection<Integer> collection =

new ArrayList<Integer>(Arrays.asList(l, 2, 3, 4, 5)); Integer[] morelnts = { 6. 7. 8. 9. 10 }; collection.addAll(Arrays.asList(morelnts)); // Работает намного быстрее, но таким способом // невозможно сконструировать Collection: Collections.addAll(collection, 11, 12, 13, 14, 15); Col lections.addAll(collection, morelnts); // Создает список на основе массива: List<Integer> list = Arrays.asList(16. 17, 18, 19, 20); list set(l, 99); // Можно - изменение элемента // list.add(21); // Ошибка времени выполнения - нижележащий // массив не должен изменяться в размерах

}

} ///:-

Конструктор Collection может получать другой объект Collection, используе­мый для его инициализации, поэтому для передачи исходных данных можно воспользоваться методом Arrays.asList(). Однако метод Collections.addAll() рабо­тает намного быстрее, и вы с таким же успехом можете сконструировать Collection без элементов, а затем вызвать Collections.addAll — этот способ счита­ется предпочтительным.

Методу Collection.addAll() в аргументе может передаваться только другой объект Collection, поэтому он уступает в гибкости методам Arrays.asList() и Collections.addAll(), использующим переменные списки аргументов.

Также можно использовать вывод Arrays.asList() напрямую, в виде List, но в этом случае нижележащим представлением будет массив, не допускающий изменения размеров. Вызов add() или delete() для такого списка приведет к по­пытке изменения размера массива, а это приведет к ошибке во время выполне­ния.

Недостаток Arrays.asList() заключается в том, что он пытается «вычислить» итоговый тип List, не обращая внимания на то, что ему присваивается. Иногда это создает проблемы:

//: hoiding/AsListInference.java // Arrays.asListO makes its best guess about type, import java.util.*;

class Snow {}

class Powder extends Snow {} class Light extends Powder {} class Heavy extends Powder {} class Crusty extends Snow {} class Slush extends Snow {}

public class AsListInference {

public static void main(String[] args) { List<Snow> snowl = Arrays.asList(

new CrustyO. new SlushO. new PowderO);

// He компилируется- // List<Snow> snow2 = Arrays.asList( // new LightO. new HeavyO); // Сообщение компилятора: //found java.util.List<Powder> // required, java util List<Snow>

II Collections.addAllО работает нормально:

List<Snow> snow3 = new ArrayList<Snow>():

Col 1 ecti ons. addAl 1 (snow3, new LightO. new HeavyO);

II Передача информации посредством уточнения // типа аргумента

List<Snow> snow4 = Arrays <Snow>asList( new LightO, new HeavyO),

}

} ///:-

При попытке создания snow2, Arrays.asList() создает List<Powder> вместо List <Snow>, тогда как Collections.addAll() работает нормально, потому что целевой тип определяется первым аргументом. Как видно из создания snow4, в вызов Arrays.asList() можно вставить «подсказку», которая сообщает компилятору фак­тический тип объекта List, производимого Arrays.asList().

С контейнерами Map дело обстоит сложнее, и стандартная библиотека Java не предоставляет средств их автоматической инициализации, кроме как по со­держимому другого объекта Map.

Вывод содержимого контейнеров

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

II: ell:Printi ngContai ners.java II Вывод контейнеров по умолчанию import java.util.*;

import static net.mindview.util.Print.*;

public class PrintingContainers {

static Collection fill(Collection<String> collection) { collection. addC'rat"): collection.addC'cat"); collection.adde'dog"): col lection.add("dog"); return collection;

}

static Map fill(Map<String,String> map) {

map. put ("rat", "Fuzzy");                                                                продолжение &

map.put("cat". "Rags"), тар.put("dog". "Bosco"); map.put("dog", "Spot"); return map;

}

public static void main(String[] args) {

pri nt(fi11(new ArrayLi st<Stri ng>())); print(fill(new LinkedList<String>())); pri nt(fi11(new HashSet<Stri ng>())); pri nt(fi11(new TreeSet<Stri ng>())); pri nt(fi11(new Li nkedHashSet<Stri ng>())); pri nt(fi11(new HashMap<Stri ng.Stri ng>())); print(fill(new TreeMap<String,String>())); print(fi11(new LinkedHashMap<String,String>()));

}

} /* Output: [rat, cat, dog, dog] [rat, cat. dog, dog] [dog, cat, rat] [cat, dog, rat] [rat. cat. dog]

{dog=Spot. cat=Rags, rat=Fuzzy} {cat=Rags, dog=Spot, rat=Fuzzy} {rat=Fuzzy, cat=Rags, dog=Spot} *///:-

Как уже было упомянуто, в библиотеке контейнеров Java существует две ос­новные категории, различающиеся прежде всего тем, сколько в одной ячейке контейнера «помещается» элементов. Коллекции (Collection) содержат только один элемент в каждой ячейке. К этой категории относятся список (List), где в определенной последовательности хранится группа элементов, множество (Set), в которое можно добавлять только по одному элементу определенного типа, и очередь (Queue). В контейнерах Map (карта) хранятся два объекта: ключ и связанное с ним значение.

Из выходных данных программы видно, что вывод по умолчанию (обеспечи­ваемый методом toStringO каждого контейнера) дает вполне приличные резуль­таты. Содержимое Collection выводится в квадратных скобках, с разделением элементов запятыми. Содержимое Map заключается в фигурные скобки, ключи и значения разделяются знаком равенства (ключи слева, значения справа).

Контейнеры ArrayList и LinkedList принадлежат к семейству List, и из выход­ных данных видно, что элементы в них хранятся в порядке вставки. Они разли­чаются не только скоростью выполнения тех или иных операций, но и тем, что LinkedList содержит больше операций, чем ArrayList.

HashSet, TreeSet и LinkedHashSet относятся к семейству Set. Из выходных дан­ных видно, что в множествах Set каждый элемент хранится только в одном эк­земпляре, а разные реализации Set используют разный порядок хранения эле­ментов. В HashSet порядок элементов определяется по довольно сложному алгоритму — пока достаточно знать, что этот алгоритм обеспечивает минималь­ное время выборки элементов, но порядок следования элементов на первый взгляд выглядит хаотично. Если порядок хранения для вас важен, используйте контейнер TreeSet, в котором объекты хранятся отсортированными по возраста­нию в порядке сравнения, или LinkedHashSet с хранением элементов в порядке добавления.

Карта (Map) позволяет искать объекты по ключу, как несложная база дан­ных. Объект, ассоциированный с ключом, называется значением. (Карты также называют ассоциативными массивами.)

В нашем примере используются три основные разновидности Map: HashMap, TreeMap и LinkedHashMap. Как и HashSet, HashMap обеспечивает максимальную скорость выборки, а порядок хранения его элементов не очевиден. TreeMap хра­нит ключи отсортированными по возрастанию, a LinkedHashMap хранит ключи в порядке вставки, но обеспечивает скорость поиска HashMap.

List

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

•        Базовый контейнер ArrayList, оптимизированный для произвольного дос­тупа к элементам, но с относительно медленнными операциями вставки (удаления) элементов в середине списка.

•        Контейнер LinkedList, оптимизированный для последовательного доступа, с быстрыми операциями вставки (удаления) в середине списка_; Произ­вольный доступ к элементам LinkedList выполняется относительно мед­ленно, но по широте возможностей он превосходит ArrayList.

В следующем примере используется библиотека typenfo.pets из главы «Ин­формация о типе». Она содержит иерархию классов домашних животных Pet, а также ряд вспомогательных средств для случайного построения объектов Pet. Пока достаточно знать, что (1) библиотека содержит класс Pet и производные типы, и (2) статический метод Pets.arrayList() возвращает контейнер ArrayList, за­полненный случайно выбранными объектами Pet.

//• hoi ding/ListFeatures.java import typeinfo.pets.*; import java.util.*;

import static net mindview util.Print.*:

public class ListFeatures {

public static void main(String[] args) { Random rand = new Random(47); List<Pet> pets = Pets.arrayList(7); printC'l: " + pets); Hamster h = new HamsterO; pets.add(h); // Автоматическое изменение размера print("2: " + pets); print("3: " + pets.contains(h)); pets.remove(h); // Удаление объекта

Pet p = pets.get(2);                                                                        продолжение &

print("4: " + р + " " + pets.indexOf(p));

Pet cymric = new CymricO;

print("5: " + pets.indexOf(cymric));

print("6: " + pets.remove(cymric));

// Точно заданный объект:

print("7: " + pets.remove(p));

print("8: " + pets);

pets.add(3. new MouseO); // Вставка no индексу

print("9: " + pets);

List<Pet> sub = pets.subListd, 4);

printC'subList: " + sub);

print("10: " + pets.containsAll(sub));

Col lections.sort(sub); // Сортировка "на месте"

print("sorted subList: " + sub);

// Для containsAllО порядок неважен:

printC'll: " + pets.containsAll(sub));

Col 1ections.shuffle(sub. rand); // Случайная перестановка

print("shuffled subList: " + sub).

print("12: " + pets.containsAll(sub));

List<Pet> copy = new ArrayList<Pet>(pets);

sub = Arrays.asList(pets.getd). pets.get(4));

printC'sub: " + sub);

copy.retainAll(sub);

print("13: " + copy);

copy = new ArrayList<Pet>(pets); // Получение новой копии copy remove(2); // Удаление по индексу print("14: " + copy);

copy.removeAll(sub); // Удаление заданных элементов print("15: " + copy);

copy.setd, new MouseO); // Замена элемента print("16: " + copy);

copy.addAll(2. sub); // Вставка в середину списка

pri nt("17: " + copy);

print("18: " + pets.isEmptyO);

pets.clearO; // Удаление всех элементов

print("19: " + pets);

print("20: " + pets isEmptyO);

pets.addAll(Pets.arrayList(4));

print("21: " + pets);

Object[] о = pets.toArrayO;

print("22: " + o[3]);

Pet[] pa = pets.toArray(new Pet[0]),

print("23: " + pa[3].id());

}

} /* Output

1: [Rat. Manx. Cymric. Mutt. Pug. Cymric. Pug]

2: [Rat. Manx. Cymric. Mutt. Pug. Cymric. Pug. Hamster]

3: true

4: Cymric 2

5: -1

6: false

7: true

8: [Rat. Manx. Mutt. Pug. Cymric. Pug] 9: [Rat. Manx. Mutt. Mouse. Pug. Cymric. Pug] subList: [Manx. Mutt. Mouse] 10: true

sorted subList: [Manx. Mouse. Mutt] 11: true

shuffled subList: [Mouse, Manx. Mutt] 12: true

sub: [Mouse. Pug] 13: [Mouse, Pug]

14: [Rat. Mouse. Mutt, Pug. Cymric, Pug]

15: [Rat. Mutt. Cymric. Pug]

16: [Rat. Mouse. Cymric. Pug]

17: [Rat. Mouse. Mouse. Pug. Cymric. Pug]

18: false

19: []

20: true

21: [Manx. Cymric. Rat. EgyptianMau] 22: EgyptianMau 23: 14 *///:-

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

В первой строке выводится исходный контейнер List с объектами Pets. В от­личие от массивов, List поддерживает добавление и удаление элементов с изме­нением размеров списка. Результат добавления Hamster виден в строке 2: объект появляется в конце списка.

Метод contains() проверяет, присутствует ли объект в списке. Чтобы удалить объект, передайте ссылку на него методу remove(). Кроме того, при наличии ссылки на объект можно узнать его индекс в списке при помощи метода indexOf(), как показано в строке 4.

При проверке вхождения элемента в List, проверке индекса элемента и уда­ления элемента из List по ссылке используется метод equals() (из корневого класса Object). Все объекты Pet считаются уникальными, поэтому несмотря на присутствие двух объектов Cymric в списке, если я создам новый объект Cymric и передам его indexOf(), результат будет равен -1 (элемент не найден), а вызов remove() вернет false. Для других классов метод equals() может быть оп­ределен иначе — например, объекты String считаются равными в случае совпа­дения содержимого.

В строках 7 и 8 из List успешно удаляется заданный объект. Строка 9 и предшествующий ей код демонстрируют вставку элемента в сере­дину списка. Метод subList() позволяет легко создать «срез» из подмножества элементов списка; естественно, при передаче его методу containsAll() большего списка будет получен истинный результат. Вызовы Collections.sort() и Collec- tions.shuffle() для sub не влияют на результат вызова containsAll().

Метод retainAll() фактически выполняет операцию «пересечения мно­жеств», то есть определения всех элементов сору, которые также присутствуют в sub. И снова поведение метода зависит от реализации equals().

В строке 14 представлен результат удаления элемента по индексу — это проще, чем удаление по ссылке на объект, потому что вам не придется беспоко­иться о поведении equals().

Работа метода removeAll() также зависит от equals(). Как подсказывает назва­ние, метод удаляет из List все объекты, входящие в List-аргумент.

Название метода set() выбрано неудачно, потому что оно совпадает с именем класса Set — возможно, лучше было бы назвать метод «replace», потому что он заменяет элемент с заданным индексом (первый аргумент) вторым аргументом.

В строке вывода 17 показано, что для List существует перегруженный метод addAll(), вставляющий новый список в середину исходного списка (вместо про­стого добавления в конец методом addAll(), унаследованным от Collection).

В строках 18-20 представлен результат вызова методов isEmpty() и clear(). Строки 22 и 23 демонстрируют, что любой объект Collection можно преобразо­вать в массив с использованием to Array ().

Итераторы

У любого контейнера должен существовать механизм вставки и выборки эле­ментов. В конце концов, контейнер предназначен именно для хранения объек­тов. При работе с List для вставки может использоваться метод add(), а для вы­борки — метод get() (впрочем, существуют и другие способы).

Если взглянуть на ситуацию с более высокого уровня, обнаруживается про­блема: чтобы использовать контейнер в программе, необходимо знать его точ­ный тип. Что, если вы начали использовать в программе контейнер List, а затем обнаружили, что в вашем случае будет удобнее применить тот же код к множе­ству (Set)? Или если вы хотите написать универсальный код, который не зави­сит от типа контейнера и может применяться к любому контейнеру?

С данной абстракцией хорошо согласуется концепция итератора (iterator). Итератор — это объект, обеспечивающий перемещение по последовательности объектов с выбором каждого объекта этой последовательности, при этом про­граммисту-клиенту не надо знать или заботиться о лежащей в ее основе струк­туре. Вдобавок, итератор обычно является так называемым «легковесным» (light­weight) объектом: его создание должно обходиться без заметных затрат ресур­сов. Из-за этого итераторы часто имеют ограничения; например, Iterator в Java поддерживает перемещение только в одном направлении. Его возможности не так уж широки, но с его помощью можно сделать следующее:

•        Запросить у контейнера итератор вызовом метода iterator(). Получен­ный итератор готов вернуть начальный элемент последовательности при первом вызове своего метода next().

•        Получить следующий элемент последовательности вызовом метода next().

•        Проверить, остались ли еще объекты в последовательности (метод hasNext()).

•        Удалить из последовательности последний элемент, возвращенный ите­ратором, методом remove().

Чтобы увидеть итератор в действии, мы снова воспользуемся иерархией Pets:

// holding/Simplelteration java import typeinfo pets *; import java util *.

public class Simplelteration {

public static void main(String[] args) {

List<Pet> pets = Pets arrayList(12); Iterator<Pet> it = pets iteratorO. whi 1 e(it hasNextO) {

Pet p = it nextO;

System.out pri nt(p id() + " " + p + " ");

}

System.out printlnO; // Более простой способ, for(Pet p • pets)

System out print(p id() + "+ p + " "); System, out. printlnO;

// Итератор также способен удалять элементы: it = pets. iteratorO. for(int i = 0: i < 6: i++) { it nextO: it.removeO.

}

System.out.pnntln(pets):

}

} /* Output-

0:Rat l:Manx 2:Cymric 3-Mutt 4-Pug 5:Cymric 6.Pug 7:Manx 8.Cymric 9:Rat 10:EgyptianMau 11.Hamster

0-Rat 1-Manx 2-Cymric 3:Mutt 4:Pug 5.Cymric 6:Pug 7:Manx 8:Cymric 9-Rat 10-EgyptianMau 11:Hamster

[Pug. Manx. Cymric. Rat. EgyptianMau. Hamster] *///•-

Мы видим, что с Iterator можно не беспокоиться о количестве элементов в последовательности. Проверка осуществляется методами hasNext() и next().

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

Iterator удаляет последний элемент, полученный при помощи next(), поэтому перед вызовом remove() необходимо вызвать next().

Теперь рассмотрим задачу создания метода display(), не зависящего от типа контейнера:

//: hoiding/CrossContaiпегIteration.java import typeinfo.pets.*, import java.util *;

public class CrossContainerlteration {

public static void display(Iterator<Pet> it) { while(it.hasNextO) {

Pet p = it nextO:

System.out.print(p.id() + ":" + p + " ");

}

System out.printlnO;

}

public static void main(String[] args) {                                                             продолжение &

ArrayList<Pet> pets = Pets.arrayList(8); LinkedList<Pet> petsLL = new LinkedList<Pet>(pets); HashSet<Pet> petsHS = new HashSet<Pet>(pets); TreeSet<Pet> petsTS = new TreeSet<Pet>(pets); di splay(pets.iterator()); display(petsLL iteratorO); di splay(petsHS.iterator()); di spl ay(petsTS. iteratorO);

}

} /* Output:

0:Rat 1-Manx 2-Cymric 3-Mutt 4:Pug 5:Cymric 6:Pug 7:Manx 0:Rat l.Manx 2:Cymric 3:Mutt 4:Pug 5:Cymric 6:Pug 7:Manx 4:Pug 6:Pug 3:Mutt l:Manx 5:Cymric 7:Manx 2:Cymric 0:Rat 5 Cymric 2:Cymric 7:Manx l:Manx 3:Mutt 6:Pug 4:Pug 0:Rat *///:-

В методе display() отсутствует информация о типе последовательности, и в этом проявляется истинная мощь итераторов: операция перемещения по по­следовательности отделяется от фактической структуры этой последовательно­сти. Иногда говорят, что итераторы унифицируют доступ к контейнерам.

Listlterator

Listlterator — более мощная разновидность Iterator, поддерживаемая только классами List. Если Iterator поддерживает перемещение только вперед, List- Iterator является двусторонним. Кроме того, он может выдавать индексы сле­дующего и предыдущего элементов по отношению к текущей позиции итерато­ра в списке и заменять последний посещенный элемент методом set(). Вызов listIterator() возвращает Listlterator, указывающий в начало List, а для создания итератора Listlterator, изначально установленного на элемент с индексом п, ис­пользуется вызов listlterator(n). Все перечисленные возможности продемонст­рированы в следующем примере:

//: hoiding/Listlteration java import typeinfo.pets.*, import java.util *;

public class Listlteration {

public static void main(String[] args) {

List<Pet> pets = Pets.arrayList(8); ListIterator<Pet> it = pets.listlteratorO; while(it.hasNextO)

System.out.print(it.next0 + " + it.nextlndexO + " + it.previousIndexO + ");

System.out.printi n(). // В обратном направлении: while(it.hasPreviousO)

System.out.print(it.previousO.id() + " "); System, out pri nti nO. System.out.printin(pets): it = pets.listlteratorO): while(it.hasNextO) { it.nextO:

i t.set(Pets.randomPet 0):

System out println(pets).

}

} /* Output.

Rat. 1. 0; Manx. 2. 1. Cymric. 3. 2; Mutt. 4. 3. Pug. 5. 4. Cymric. 6. 5. Pug. 7. 6. Manx. 8. 7. 7 6 5 4 3 2 1 0

[Rat. Manx. Cymric. Mutt. Pug. Cymric. Pug. Manx] [Rat. Manx. Cymric. Cymric. Rat. EgyptianMau. Hamster. EgyptianMau] *///•-

Метод Pets.randomPet() используется для замены всех объектов Pet в списке, начиная с позиции 3 и далее.

LinkedList

LinkedList тоже реализует базовый интерфейс List, как и ArrayList, но выполняет некоторые операции (например, вставку и удаление в середине списка) более эффективно, чем ArrayList. И наоборот, операции произвольного доступа выпол­няются им с меньшей эффективностью.

Класс LinkedList также содержит методы, позволяющие использовать его в качестве стека, очереди (Queue) или двусторонней очереди (дека).

Некоторые из этих методов являются псевдонимами или модификациями для получения имен, более знакомых в контексте некоторого использования. Например, методы getFirst() и element() идентичны — они возвращают начало (первый элемент) списка без его удаления и выдают исключение NoSuch- ElementException для пустого списка. Метод реек() представляет собой неболь­шую модификацию этих двух методов: он возвращает null для пустого списка.

Метод addFirst() вставляет элемент в начало списка. Метод offer() делает то же, что add() и addLast() — он добавляет элемент в конец списка. Метод removeLast() удаляет и возвращает последний элемент списка.

Следующий пример демонстрирует схожие и различающиеся аспекты этих методов:

// hoiding/LinkedListFeatures java import typeinfo pets *; import java util *;

import static net.mindview util Print.*;

public class LinkedListFeatures {

public static void main(String[] args) { LinkedList<Pet> pets =

new LinkedList<Pet>(Pets arrayList(5)); print(pets); // Идентично

print("pets.getFirst()• " + pets getFirstO).

print ("pets element О " + pets.elementO);

// Различие проявляется только для пустых списков:

print("pets peekO: " + pets.peekO);

// Идентично, удаление и возврат первого элемента.

print("pets removeO: " + pets.removeO);

print ("pets removeFirstO: " + pets.removeFirstO);

// Различие проявляется только для пустых списков:             продолжение

print ("pets pollO " + pets poll О). print(pets).

pets addFirst(new RatO).

print("After addFirstO " + pets).

pets offer(Pets randomPetO).

print("After offer() " + pets).

pets.add(Pets randomPetO).

print ("After addO " + pets).

pets addLast(new HamsterO).

print ("After addLastO " + pets).

print ("pets removeLastO " + pets removeLastO).

}

} /* Output

[Rat, Manx. Cymric. Mutt. Pug]

pets getFirstO. Rat

pets elementO- Rat

pets.peek О Rat

pets.removeО: Rat

pets removeFirstO: Manx

pets.poll О Cymric

[Mutt. Pug]

After addFirstO: [Rat. Mutt. Pug] After offerO: [Rat. Mutt. Pug. Cymric] After addO: [Rat. Mutt. Pug. Cymric. Pug] After addLastO* [Rat. Mutt. Pug. Cymric. Pug. Hamster] pets removeLastO. Hamster *///:-

Результат Pets.arrayList() передается конструктору LinkedList для заполнения. Присмотревшись к интерфейсу Queue, вы найдете в нем методы element(), offer(), peek(), poll() и remove(), добавленные в LinkedList для использования в реализации очереди (см. далее).

Стек

Стек часто называют контейнером, работающим по принципу «первым вошел, последним вышел» (LIFO). То есть элемент, последним занесенный в стек, бу­дет первым, полученным при извлечении из стека.

В классе LinkedList имеются методы, напрямую реализующие функциональ­ность стека, поэтому вы просто используете LinkedList, не создавая для стека но­вый класс. Впрочем, иногда отдельный класс для контейнера-стека лучше справ­ляется с задачей:

//. net/mi ndvi ew/uti1/Stack java // Создание стека из списка LinkedList. package net.mindview.util: import java.util.LinkedList:

public class Stack<T> {

private LinkedList<T> storage = new LinkedList<T>(); public void push(T v) { storage.addFirst(v); } public T peek О { return storage. getFirstO: } public T popO { return storage removeFirstO: } public boolean emptyО { return storage.isEmptyО: }

public String toStringO { return storage.toStringO. } } ///:-

Это простейший пример определения класса с использованием параметри­зации. Суффикс <Т> после имени класса сообщает компилятору, что тип явля­ется параметризованным по типу Т — при использовании класса на место Т бу­дет подставлен фактический тип. Фактически такое определение означает: «Мы определяем класс Stack для хранения объектов типа Т». Stack реализуется на базе LinkedList, также предназначенного для хранения типа Т. Обратите вни­мание: метод push() получает объект типа Т, а методы реек() и рор() возвращают объект типа Т. Метод реек() возвращает верхний элемент без извлечения из сте­ка, а метод рор() удаляет и возвращает верхний элемент. Простой пример использования нового класса Stack:

//• hoiding/StackTest.java import net.mindview util.*:

public class StackTest {

public static void main(String[] args) {

Stack<String> stack = new Stack<String>(): for(String s • "My dog has fleas" .splitC' "))

stack.push(s); whi led stack. emptyO)

System out pri nt(stack.pop() + " ");

}

} /* Output: fleas has dog My *///:-

Если вы хотите использовать класс Stack в своем коде, вам придется либо полностью указать пакет, либо изменить имя класса при создании объекта; в противном случае, скорее всего, возникнет конфликт с классом Stack из паке­та java.util. Пример использования имен пакетов при импортировании java. util.* в предыдущем примере:

//: holding/StackCollision.java import net.mindview.util.*:

public class StackCol1ision {

public static void main(String[] args) {

net.mindview.util.Stack<String> stack =

new net.mindview.util.Stack<String>(); for(String s : "My dog has fleas".splitC "))

stack.push(s): whi led stack, empty О)

System, out. pri nt (stack. popO + " "); System, out. printlnO; java.util.Stack<String> stack2 =

new java.util.Stack<String>(): for(String s : "My dog has fleas".splitC' "))

stack2.push(s); while( !stack2 emptyO)

System.out print(stack2.pop() + " ").

}

fleas has dog My fleas has dog My *///:-

В java.util нет общего интерфейса Stack — вероятно, из-за того, что имя было задействовано в исходной, неудачно спроектированной версии java. util.Stack для Java 1.0. Хотя класс java.util.Stack существует, LinkedList обеспечивает более качественную реализацию стека, и решение net.mindview.util. Stack является предпочтительным.

Множество

В множествах (Set) каждое значение может храниться только в одном экземп­ляре. Попытки добавить новый экземпляр эквивалентного объекта блокируются. Множества часто используются для проверки принадлежности, чтобы вы мог­ли легко проверить, принадлежит ли объект заданному множеству. Следова­тельно, важнейшей операцией Set является операция поиска, поэтому на прак­тике обычно выбирается реализация HashSet, оптимизированная для быстрого поиска.

Set имеет такой же интерфейс, что и Collection. В сущности, Set и является Collection, но обладает несколько иным поведением (кстати, идеальный пример использования наследования и полиморфизма: выражение разных концепций поведения). Пример использования HashSet с объектами Integer:

//• hoiding/SetOfInteger.java import java.util.*,

public class SetOfInteger {

public static void main(String[] args) { Random rand = new Random(47); Set<Integer> intset = new HashSet<Integer>(): for(int i = 0: i < 10000; i++)

i ntset.add(rand.nextInt(30)): System.out.printin(intset):

}

} /* Output:

[15, 8, 23, 16, 7, 22, 9, 21, 6, 1, 29, 14, 24, 4, 19, 26, 11, 18, 3, 12, 27, 17, 2, 13, 28, 20, 25, 10, 5, 0] *///:-

В множество включаются десять тысяч случайных чисел от 0 до 29; естест­венно, числа должны многократно повторяться. Но при этом мы видим, что в результатах каждое число присутствует только в одном экземпляре.

Также обратите внимание на непредсказуемый порядок следования чисел в выводе. Это объясняется тем, что HashSet использует хеширование для ускоре­ния выборки. Порядок, поддерживаемый HashSet, отличается от порядка TreeSet или LinkedHashSet, поскольку каждая реализация упорядочивает элементы по- своему. Если вы хотите, чтобы результат был отсортирован, воспользуйтесь TreeSet вместо HashSet:

// hoiding/SortedSetOfInteger java import java util.*.

public class SortedSetOfInteger {

public static void main(String[] args) { Random rand = new Random(47), SortedSet<Integer> intset = new TreeSet<Integer>(), for(int i = 0. i < 10000; i++)

i ntset.add(rand.nextInt(30)); System.out println(intset);

}

} /* Output-

[0. 1. 2. 3. 4. 5. 6, 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29] *///.-

Одной из наиболее распространенных операций со множествами является проверка принадлежности методом contains(), но существуют и другие опера­ции, которые напомнят вам диаграммы Венна из школьного курса:

// holding/SetOperations java import java.util.*.

import static net.mindview.util.Print.*;

public class SetOperations {

public static void main(String[] args) {

Set<String> setl = new HashSet<String>(); Col 1ecti ons.addAl1(setl.

"ABCDEFGHIJK L".splitC ")). setl.addCM");

printCH " + setl containsCH"));

printCN " + setl containsCN"));

Set<String> set2 = new HashSet<String>();

Col 1 ecti ons. addAl l(set2. "H I J К L" splitC "));

print("set2 in setl- " + setl containsAll(set2));

setl.removeCH");

print("setl. " + setl);

print("set2 in setl- " + setl.containsAll(set2)); setl removeAll(set2); printCset2 removed from setl: " + setl). Collections.addAll (setl. "X Y Z".splitC ")). printC'X Y Г added to setl. " + setl);

}

} /* Output H. true N- false

set2 in setl: true

setl: [D. К. С. B. L. G. I. M. A. F. J. E] set2 in setl- false

set2 removed from setl- [D. С. B. G. M. A. F. E] 'X Y Г added to setl: [Z. D. С. B. G. M. A. F. Y. X. E] *///.-

Имена методов говорят за себя. Информацию о других методах Set можно найти в документации JDK.

Карта

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

// holding/Statistics java

// Простой пример использования HashMap

import java util *.

public class Statistics {

public static void main(String[] args) { Random rand = new Random(47). Map<Integer,Integer> m =

new HashMap<Integer.Integer>(), for(int i = 0, i < 10000. i++) {

// Получение случайного числа от 0 до 20. int г = rand nextInt(20). Integer freq = m get(r). m.put(r. freq == null ? 1 freq +1).

}

System out println(m);

}

} /* Output

{15=497. 4=481. 19=464. 8=468. 11=531, 16=533, 18=478, 3=508, 7=471, 12=521, 17=509, 2=489, 13=506, 9=549, 6=519, 1=502, 14=477, 10=513, 5=503, 0=481} *///•-

В main() механизм автоматической упаковки преобразует случайно сгенери- рованое целое число в ссылку на Integer, которая может использоваться с HashMap (контейнеры не могут использоваться для хранения примитивов). Метод get() возвращает null, если элемент отсутствует в контейнере (то есть если число было сгенерировано впервые. В противном случае метод get() воз­вращает значение Integer, связанное с ключом, и последнее увеличивается на 1 (автоматическая упаковка снова упрощает вычисления, но в действительности при этом выполняются преобразования к Integer и обратно).

Следующий пример демонстрирует поиск объектов Pet по строковому опи­санию String. Он также показывает, как проверить присутствие некоторого клю­ча или значения в Map методами containsKey() и containsValue():

// holding/PetMap java import typeinfo.pets.*, import java util *;

import static net mindview util Print *;

public class PetMap {

public static void main(String[] args) {

Map<String,Pet> petMap = new HashMap<String.Pet>(). petMap put ("My Cat", new CatCMolly")). petMap put("My Dog", new Dog("Ginger")). petMap put ("My Hamster", new HamsterCBosco")). print(petMap).

Pet dog = petMap get("My Dog"), print(dog).

print(petMap containsKeyC'My Dog")), pri nt(petMap.contai nsValue(dog)).

}

} /* Output-

{My Cat=Cat Molly. My Hamster=Hamster Bosco. My Dog=Dog Ginger}

Dog Ginger

true

true

*///•-

Map, по аналогии с массивами и Collection, легко расширяются до нескольких измерений; достаточно создать Map со значениями типа Map (причем значения­ми этих Map могут быть другие контейнеры, и даже другие Map). Контейнеры легко комбинируются друг с другом, что позволяет быстро создавать сложные структуры данных. Например, если нам потребуется сохранить информацию о владельцах сразу нескольких домашних животных, для этого будет достаточ­но создать контейнер Map<Person,List<Pet»:

//. holding/MapOfList.java package holding; import typeinfo pets.*, import java.util.*.

import static net.mindview util Print *;

public class MapOfList {

public static Map<Person. List<? extends Pet»

petPeople = new HashMap<Person. Li st<? extends Pet»();

static {

petPeople put(new PersonC'Dawn").

Arrays asList(new Cymric("Molly").new Mutt("Spot"))). petPeople put(new Person("Kate").

Arrays asList(new CatC'Shackleton"),

new Cat("Elsie May"), new DogCMargrett"))); petPeople put(new Person("Marilyn"). Arrays asList(

new Pug("Louie aka Louis Snorkel stein Dupree"). new Cat("Stanford aka Stinky el Negro"), new CatC'Pinkola"))). petPeople put(new Person("Luke").

Arrays asList(new Rat("Fuzzy"). new Rat("Fizzy"))). petPeople put(new Person("Isaac").

Arrays asList(new RatCFreckly"))).

}

public static void main(String[] args) {

print ("People- " + petPeople keySetO). printOPets: " + petPeople valuesO); for(Person person . petPeople.keySet()) { print(person + " has-"); for(Pet pet • petPeople get(person))

printC " + pet);                продолжение & }

}

} /* Output

People [Person Luke, Person Marilyn. Person Isaac, Person Dawn. Person Kate] Pets [[Rat Fuzzy. Rat Fizzy], [Pug Louie aka Louis Snorkel stein Dupree. Cat Stanford aka Stinky el Negro, Cat Pinkola]. [Rat Freckly]. [Cymric Molly. Mutt Spot], [Cat Shackleton, Cat Elsie May, Dog Margrett]] Person Luke has Rat Fuzzy Rat Fizzy Person Marilyn has

Pug Louie aka Louis Snorkel stein Dupree Cat Stanford aka Stinky el Negro Cat Pinkola Person Isaac has Rat Freckly Person Dawn has. Cymric Molly Mutt Spot Person Kate has- Cat Shackleton Cat Elsie May Dog Margrett */// ~

Map может вернуть множество (Set) своих ключей, коллекцию (Collection) значений или множество (Set) всех пар «ключ-значение». Метод keySet() созда­ет множество всех ключей, которое затем используется в синтаксисе foreach для перебора Map.

Очередь

Очередь обычно представляет собой контейнер, работающий по принципу «пер­вым вошел, первым вышел»(FIFO). Иначе говоря, элементы заносятся в оче­редь с одного «конца» и извлекаются с другого в порядке их поступления. Оче­реди часто применяются для реализации надежной передачи объектов между разными областями программы.

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

//: hoiding/QueueDemo.java

// Восходящее преобразование LinkedList в Queue

import java.util.*;

public class QueueDemo {

public static void printQCQueue queue) { while(queue.peek() != null)

System out print(queue.remove() + " "), System out printin(),

}

public static void main(String[] args) {

Queue<Integer> queue = new LinkedList<Integer>();

Random rand = new Random(47); for(int i = 0; i < 10; i++)

queue.offer(rand.nextlnt(i + 10)); printQ(queue);

Queue<Character> qc = new LinkedList<Character>(); for(char с ; "Brontosaurus".toCharArrayO)

qc.offer(c); printQ(qc);

}

} /* Output;

8 1 1 1 5 14 3 1 0 1

Brontosaurus

*///;-

Метод offer(), один из методов Queue, вставляет элемент в конец очереди, а если вставка невозможна — возвращает false. Методы реек() и element() воз­вращают начальный элемент без его удаления из очереди, но реек() для пустой очереди возвращает null, a element() выдает исключение NoSuchElementException. Методы poll() и remove() удаляют и возвращают начальный элемент очереди, но poll() для пустой очереди возвращает null, a remove() выдает NoSuchElement­Exception.

Автоматическая упаковка преобразует результат int вызова nextlnt() в объект Integer, необходимый для queue, a char с — в объект Character, необхо­димый для qc. Интерфейс Queue сужает доступ к методам LinkedList так, что доступными остаются только соответствующие методы и у пользователя ос­тается меньше возможностей для вызова методов LinkedList (конечно, queue можно преобразовать обратно в LinkedList, но это создает дополнительные за­труднения).

PriorityQueue

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

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

При помещении объекта в PriorityQueue вызовом offer() объект сортируется в очереди. По умолчанию используется естественный порядок помещения объ­ектов в очередь, однако вы можете изменить его, предоставив собственную реа­лизацию Comparator. PriorityQueue гарантирует, что при вызове peek(), poll() или removeQ вы получите элемент с наивысшим приоритетом.

Создание приоритетной очереди для встроенных типов — Integer, String, Character и т. д. — является делом тривиальным. В следующем примере исполь­зуются те же значения, что и в предыдущем, но PriorityQueue выдает их в другом порядке:

//. hoiding/PriorityQueueDemo.java import java util *;

public class PriorityQueueDemo {

public static void main(String[] args) {

PriorityQueue<Integer> priorityQueue = new PriorityQueue<Integer>(); Random rand = new Random(47), for(int i = 0; i < 10; i++)

priorityQueue.offer(rand.nextInt(i + 10)); QueueDemo.pri ntQCpriori tyQueue);

List<Integer> ints = Arrays.asList(25, 22, 20.

18. 14. 9. 3. 1. 1, 2. 3. 9. 14, 18. 21. 23. 25); priorityQueue = new PriorityQueue<Integer>(ints); QueueDemo.pri ntQ(pri ori tyQueue); priorityQueue = new PriorityQueue<Integer>(

ints.sizeO. Collections reverseOrderO); pri ori tyQueue.addAl1(i nts). QueueDemo.pri ntQCpriori tyQueue);

String fact = "EDUCATION SHOULD ESCHEW 0BFUSCATI0N"; List<String> strings = Arrays.asList(fact.split("")); PriorityQueue<String> stringPQ =

new Pri ori tyQueue<Stri ng>(stri ngs); QueueDemo.printQ(stringPQ); stringPQ = new PriorityQueue<String>(

strings.sizeO. Col lections. reverseOrderO); stringPQ.addAl1(strings); QueueDemo.printQ(stringPQ);

Set<Character> charSet = new HashSet<Character>(); for(char с • fact toCharArray())

charSet.add(c); // Автоматическая упаковка PriorityQueue<Character> characterPQ =

new PriorityQueue<Character>(charSet); QueueDemo printQ(characterPQ).

}

} /* Output:

0   1 1 1 1 1 3 5 8 14

1   1 2 3 3 9 9 14 14 18 18 20 21 22 23 25 25 25 25 23 22 21 20 18 18 14 14 9 9 3 3 2 1 1

AABCCCDDEEEFHHIILNN0000SSSTTUUUW WUUUTTSSS0000NNLIIHHFEEEDDCCCBAA

ABCDEFH I LN0STUW *///:-

Мы видим, что дубликаты разрешены, а меньшие значения обладают более высокими приоритетами. Чтобы показать, как изменить порядок элементов по­средством передачи собственного объекта Comparator, при третьем вызове кон­структора PriorityQueue<Integer> и втором — PriorityQueue<String> используется

Comparator с обратной сортировкой, полученный вызовом Collections.reverse- Order() (одно из новшеств Java SE5).

В последней части добавляется HashSet для уничтожения дубликатов Charac­ter — просто для того, чтобы пример был чуть более интересным.

Integer, String и Character изначально работают с PriorityQueue, потому что они обладают «встроенным» естественным упорядочением. Если вы хотите исполь­зовать собственный класс с PriorityQueue, включите дополнительную реали­зацию естественного упорядочения или предоставьте собственный объект Comparator.

Collection и Iterator

Collection — корневой интерфейс, описывающий общую функциональность всех последовательных контейнеров. Его можно рассматривать как «вторичный ин­терфейс», появившийся вследствие сходства между другими интерфейсами. Кроме того, класс java.util. AbstractCollection предоставляет реализацию Collection по умолчанию, поэтому вы можете создать новый подтип AbstractCollection без избыточного дублирования кода.

Один из доводов в пользу интерфейсов заключается в том, что они позволя­ют создавать более универсальный код. Код, написанный для интерфейса, а не для его реализации, может быть применен к более широкому кругу объектов. Таким образом, если я пишу метод, которому при вызове передается Collection, этот ме­тод будет работать с любым типом, реализующим Collection, — следовательно, если новый класс реализует Collection, он будет совместим с моим методом. Од­нако интересно заметить, что стандартная библиотека С++ не имеет общего ба­зового класса для своих контейнеров — вся общность контейнеров обеспечива­ется итераторами. Казалось бы, в Java будет логично последовать примеру С++ и выражать сходство между контейнерами при помощи итераторов, а не Collection. Тем не менее эти два подхода взаимосвязаны, потому что реализация Collection также означает поддержку метода iterator():

//: hoiding/InterfaceVsIterator.java import typeinfo pets *, import java.util.*,

public class InterfaceVsIterator {

public static void display(Iterator<Pet> it) {. whileCit hasNextO) {

Pet p = it.nextO.

System out pri nt(p id() + " " + p + " ").

}

System.out.printi n();

}

public static void display(Collection<Pet> pets) { for(Pet p • pets)

System out print(p id() + " " + p + " "), System out printlnO.

}

public static void main(String[] args) {

List<Pet> petList = Pets arrayList(8).

Set<Pet> petSet = new HashSet<Pet>(petList). Map<String,Pet> petMap =

new LinkedHashMap<String.Pet>(). String[] names = ("Ralph. Eric, Robin. Lacey. " +

"Britney. Sam. Spot. Fluffy") splitC. "). for(int i = 0. i < names length. i++)

petMap.put(names[i]. petList get(i)). display(petList): display(petSet). display(petList iteratorO). displ ay (petSet iteratorO). System out println(petMap). System out. pri ntl n( petMap keySetO). displ ay (petMap valuesO). display(petMap.values О .iteratorO);

}

} /* Output-

0 Rat 1 Manx 2 Cymric 3.Mutt 4 Pug 5.Cymric 6 Pug 7 Manx 4:Pug 6 Pug 3 Mutt 1 Manx 5 Cymric 7 Manx 2:Cymric O-Rat O-Rat 1 Manx 2-Cymric 3-Mutt 4-Pug 5 Cymric 6 Pug 7 Manx 4-Pug 6 Pug 3 Mutt 1 Manx 5:Cymric 7.Manx 2 Cymric 0:Rat

{Ralph=Rat. Eric=Manx, Robin=Cymric. Lacey=Mutt. Britney=Pug. Sam=Cymric. Spot=Pug. Fluffy=Manx}

[Ralph. Eric. Robin. Lacey. Britney. Sam. Spot. Fluffy] 0:Rat l.Manx 2-Cymric 3-Mutt 4:Pug 5-Cymric 6:Pug 7 Manx 0:Rat 1 Manx 2-Cymric 3-Mutt 4.Pug 5:Cymric 6:Pug 7 Manx */// ~

Обе версии display() работают как с объектами Map, так и с подтипами Collection; при этом как Collection, так и Iterator изолируют методы display() от знания конкретной реализации используемого контейнера.

В данном случае два решения примерно равноценны. Использование Iterator становится предпочтительным при реализации постороннего класса, для которого реализация интерфейса Collection затруднена или нежелательна. Например, если мы создаем реализацию Collection наследованием от класса, со­держащего объекты Pet, нам придется реализовать все методы Collection, даже если они не будут использоваться в методе display(). Хотя проблема легко ре­шается наследованием от AbstractCollection, вам все равно придется реализо­вать iterator() вместе с size(), чтобы предоставить методы, не реализованные AbstractCollection, но используемые другими методами AbstractCollection:

// • hoidi ng/Col1ecti onSequence.java import typeinfo pets.*; import java.util.*;

public class CollectionSequence extends AbstractCollection<Pet> {

private Pet[] pets = Pets.createArray(8); public int sizeO { return pets.length; } public Iterator<Pet> iteratorO {

return new Iterator<Pet>() {

private int index = 0; public boolean hasNextO. {

return index < pets.length;

public Pet nextО { return pets[index++]; } public void removeО { // He реализован

throw new UnsupportedOperationExceptionO;

}

}:

}

public static void main(String[] args) {

CollectionSequence с = new Col 1ectionSequence(); InterfaceVsIterator.di splay(с); InterfaceVsIterator.di splay(c.i terator());

}

} /* Output:

0:Rat l:Manx 2:Cymric 3:Mutt 4:Pug 5:Cymric 6:Pug 7:Manx 0:Rat l:Manx 2:Cymric 3:Mutt 4:Pug 5:Cymric 6:Pug 7:Manx *///:-

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

Из приведенного примера видно, что при реализации Collection вы также реализуете iterator(), а простая отдельная реализация iterator() требует чуть меньших усилий, чем наследование от AbstractCollection. Но, если класс уже на­следует от другого класса, наследование еще и от AbstractCollection невозможно. В этом случае для реализации Collection придется реализовать все методы ин­терфейса, и тогда гораздо проще ограничиться наследованием и добавить воз­можность создания итератора:

//: hoidi ng/NonCol1ecti onSequence.java import typeinfo.pets.*; import java.util.*;

class PetSequence {

protected Pet[] pets = Pets.createArray(8);

}

public class NonCollectionSequence extends PetSequence { public Iterator<Pet> iteratorO {

return new Iterator<Pet>() {

private int index = 0; public boolean hasNextO {

return index < pets length;

}

public Pet nextO { return pets[index++]; } public void removeO { // He реализован

throw new UnsupportedOperationExceptionO;

}

}:

}

public static void main(String[] args) {

NonCollectionSequence nc = new NonCollectionSequence(); InterfaceVsIterator.display(nc.iteratorO);

}

} /* Output:

0:Rat l:Manx 2:Cymric 3:Mutt 4:Pug 5:Cymric 6:Pug 7:Manx *///:-

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

Синтаксис foreach и итераторы

До настоящего момента «синтаксис foreach» использовался в основном с масси­вами, но он также будет работать с любым объектом Collection. Некоторые при­меры уже встречались нам при работе с ArrayList, но можно привести и более об­щее подтверждение:

//: holding/ForEachCollections java

// Синтаксис foreach работает с любыми коллекциями

import java.util.*,

public class ForEachCollections {

public static void main(String[] args) {

Collection<String> cs = new LinkedList<String>(); Col lections.addAl1(cs,

"Take the long way home".splitC' ")); for(String s : cs)

System, out. pri nt(.. + s + ...... ),

}

} /* Output-

'Take' 'the' 'long' 'way' 'home' *///:-

Поскольку cs является Collection, этот пример показывает, что поддержка foreach является характеристикой всех объектов Collection.

Работа этой конструкции объясняется тем, что в Java SE5 появился новый интерфейс Iterable, который содержит метод iterator() для создания Iterator, и именно интерфейс Iterable используется при переборе последовательности в синтаксисе foreach. Следовательно, создав любой класс, реализующий Iterable, вы сможете использовать его в синтаксисе foreach:

//: hoidi ng/IterableClass.java // Anything Iterable works with foreach. import java.util.*;

public class IterableClass implements Iterable<String> { protected StringE] words = ("And that is how " +

"we know the Earth to be banana-shaped.").splitC "); public Iterator<String> iteratorO {

return new Iterator<String>() { private int index = 0; public boolean hasNextO {

return index < words length;

}

public String nextO { return words[index++]; } public void remove0 { // Not implemented

throw new UnsupportedOperationExceptionO,

};

public static void main(Stnng[] args) {

for(String s • new IterableClassO) System out print(s + " ");

}

} /* Output.

And that is how we know the Earth to be banana-shaped. *///:-

Метод iterator() возвращает экземпляр анонимной внутренней реализации Iterator<string>, последовательно доставляющей каждое слово в массиве. В main() мы видим, что IterableClass действительно работает в синтаксисе foreach.

В Java SE5 многие классы реализуют Iterable, прежде всего все классы Collection (но не Map). Например, следующий код выводит все переменные окру­жения (environment) операционной системы:

//: holding/Envi ronmentVariables.java import java util *;

public class EnvironmentVariables {

public static void main(String[] args) {

for (Map Entry entry System getenvO .entrySetO) { System.out.println(entry.getKey() + ": " + entry. getValueO);

}

}

} /* (Выполните, чтобы увидеть результат) *///:-

System.getenv() возвращает Map, entrySet() создает Set с элементами Map.Entry, a Set поддерживает Iterable и поэтому может использоваться в цикле foreach.

Синтаксис foreach работает с массивами и всем, что поддерживает Iterable, но это не означает, что массив автоматически поддерживает Iterable:

// ■ hoiding/ArraylsNotIterable.java import java.util.*;

public class ArraylsNotlterable {

static <T> void test(Iterable<T> ib) { for(T t • ib)

System.out.print(t + " ");

}

public static void main(String[] args) { test(Arrays.asList(l. 2, 3)); StringC] strings = { "А", "В". "С" }: // Массив работает в foreach, но не является Iterable: //! test(strings);

// его необходимо явно преобразовать к Iterable: testCArrays.asLi st(stri ngs));

}

} /* Output:1 2 3 А В С *///•-

Попытка передачи массива в аргументе Iterable завершается неудачей. Авто­матическое преобразование в Iterable не производится; его необходимо выпол­нять вручную.

Идиома «метод-адаптер»

Что делать, если у вас имеется существующий класс, реализующий Iterable, и вы хотите добавить новые способы использования этого класса в синтаксисе foreach? Допустим, вы хотите иметь возможность выбора между перебором спи­ска слов в прямом или обратном направлении. Если просто воспользоваться на­следованием от класса и переопределить метод iterator, то существующий метод будет заменен и никакого выбора не будет.

Одно из решений этой проблемы основано на использовании идиомы, кото­рую я называю «методом-адаптером». Термин «адаптер» происходит от одно­именного паттерна: вы должны предоставить интерфейс, необходимый для ра­боты синтаксиса foreach. Если у вас имеется один интерфейс, а нужен другой, проблема решается написанием адаптера. В данном случае требуется добавить к стандартному «прямому» итератору обратный, так что переопределение ис­ключено. Вместо этого мы добавим метод, создающий объект Iterable, который может использоваться в синтаксисе foreach. Как будет показано далее, это по­зволит нам предоставить несколько вариантов использования foreach:

//: hoiding/AdapterMethodldiom.java

// Идиома "метод-адаптер" позволяет использовать foreach

// с дополнительными разновидностями Iterable.

import java.util.*;

class ReversibleArrayList<T> extends ArrayList<T> {

public ReversibleArrayList(Collection<T> c) { super(c); }. public Iterable<T> reversedO {

return new Iterable<T>() {

public Iterator<T> iteratorO {

return new Iterator<T>() {

int current = sizeO - 1,

public boolean hasNextO { return current > -1;

}

public T nextO { return get (current--); } public void removeO { // He реализован throw new

UnsupportedOperationExceptionO;

}

} •

}

}:

}

}

public class AdapterMethodldiom {

public static void main(String[] args) { ReversibleArrayList<String> ral =

new ReversibleArrayList<String>(

Arrays.asList(To be or not to be".splitC' "))): // Получаем обычный итератор, полученный при помощи iteratorO: forCString s : ral)

System.out.print(s + " "); System.out printlnO;

// Передаем выбранный нами Iterable forCString s • ral .reversedO)

System.out.print(s + " "),

}

} /* Output To be or not to be be to not or be To */// ~

Если просто поместить объект ral в синтаксис foreach, мы получим (стан­дартный) «прямой» итератор. Но если вызвать для объекта reversed(), поведе­ние изменится.

Использовав этот прием, можно добавить в пример IterableClass.java два ме­тода-адаптера:

// hoidi ng/MultiIterableClass.java // Adding several Adapter Methods, import java util *;

public class MultilterableClass extends IterableClass { public Iterable<String> reversedO {

return new Iterable<String>() {

public Iterator<String> iteratorO {

return new Iterator<String>() {

int current = words length - 1,

public boolean hasNextO { return current > -1;

}

public String nextO { return words[current--];

}

public void removeО { // He реализован throw new

UnsupportedOperationException(),

}

}:

}

}.

}

public Iterable<String> randomizedO { return new Iterable<String>() {

public Iterator<String> iteratorO { List<String> shuffled =

new ArrayList<String>(Arrays.asList(words)); Collections.shuffleCshuffled, new Random(47)); return shuffled.iterator();

}

}:

}

public static void main(String[] args) {

MultilterableClass mic = new MultiIterableClassO; for (String s : mic. reversedO)

System out print(s + " "): System, out. pri ntlnO. for(String s : mic.randomizedO)

System out.print(s + " "); System.out.prmtlnO:             продолжение & for(String s : mic)

System.out.print(s + " ");

}

} /* Output:

banana-shaped, be to Earth the know we how is that And is banana-shaped. Earth that how the be And we know to And that is how we know the Earth to be banana-shaped *///:-

Из выходных данных видно, что метод Collections.shuffle не изменяет исход­ный массив, а только переставляет ссылки в shuffled. Так происходит только по­тому, что метод randomized() создает для результата Arrays.asList() «обертку» в виде ArrayList. Если бы операция выполнялась непосредственно с объектом List, полученным от Arrays.asList(), то это привело бы к изменению нижележаще­го массива:

//- hoiding/ModifyingArraysAsList.java import java util.*;

public class ModifyingArraysAsList {

public static void main(String[] args) {

Random rand = new Random(47);

Integer[] ia = { 1, 2, 3. 4, 5, 6. 7, 8. 9, 10 },

List<Integer> listl =

new ArrayList<Integer>(Arrays.asList(ia));

System.out.printIn("До перестановки. " + listl);

Col 1ecti ons.shuff1e(1i st1, rand);

System.out.println("После перестановки: " + listl);

System.out.printlnf'Массив: " + Arrays.toString(ia)),

List<Integer> list2 = Arrays.asList(ia);

System.out.println("До перестановки: " + list2);

Col 1 ecti ons. shuffled i st2. rand);

System.out.println("После перестановки: " + list2);

System.out.println("Массив: " + Arrays.toString(ia));

}

} /* Output:

До перестановки: [1, 2, 3. 4, 5. 6. 7, 8, 9, 10] После перестановки: [4. 6, 3, 1. 8, 7, 2, 5. 10. 9] Массив: [1, 2, 3. 4. 5. 6. 7, 8. 9. 10] До перестановки: [1, 2. 3, 4, 5, 6. 7. 8, 9, 10] После перестановки: [9, 1. 6. 3. 7, 2. 5, 10, 4, 8] Массив- [9. 1. 6. 3. 7, 2, 5. 10. 4. 8] *///:-

В первом случае вывод Arrays.asList() передается конструктору ArrayList(), а последний создает объект ArrayList, ссылающийся на элементы ia. Перестанов­ка этих ссылок не изменяет массива. Но, если мы используем результат Arrays.asList(ia) напрямую, перестановка изменит порядок ia. Важно учитывать, что Arrays.asList() создает объект List, который использует нижележащий массив в качестве своей физической реализации. Если с этим объектом List выполня­ются какие-либо изменяющие операции, но вы не хотите изменения исходного массива, создайте копию в другом контейнере.

Резюме

В Java существует несколько способов хранения объектов:

•       В массивах объектам назначаются числовые индексы. Массив содержит объекты заранее известного типа, поэтому преобразование типа при вы­борке объекта не требуется. Массив может быть многомерным и может использоваться для хранения примитивных типов. Тем не менее изме­нить размер созданного массива невозможно.

•       В Collection хранятся отдельные элементы, а в Map — пары ассоциирован­ных элементов. Механизм параметризации позволяет задать тип объек­тов, хранимых в контейнере, поэтому поместить в контейнер объект не­верного типа невозможно, и элементы не нуждаются в преобразовании типа при выборке. И Collection, и Map автоматически изменяются в разме­рах при добавлении новых элементов. В контейнерах не могут храниться примитивы, но механизм автоматической упаковки автоматически созда­ет объектные «обертки», сохраняемые в контейнере.

•       В контейнере List, как и в массиве, объектам назначаются числовые ин­дексы — таким образом, массивы и List являются упорядоченными кон­тейнерами.

•       Используйте ArrayList при частом использовании произвольного доступа к элементам или LinkedList при частом выполнении операций вставки и удаления в середине списка.

•       Поведение очередей и стеков обеспечивается контейнером LinkedList.

•       Контейнер Map связывает с объектом не целочисленный индекс, а другой объект. Контейнеры HashMap оптимизированы для быстрого доступа, а контейнер TreeMap хранит ключи в отсортированном порядке, но усту­пает по скорости HashMap. В контейнере LinkedHashMap элементы хранят­ся в порядке вставки, но хеширование обеспечивает быстрый доступ.

•       В контейнере Set каждый объект может храниться только в одном экзем­пляре. Контейнер HashSet обеспечивает максимальную скорость поиска, а в TreeSet элементы хранятся в отсортированном порядке. В контейнере LinkedHashSet элементы хранятся в порядке вставки.

•       Использовать старые классы Vector, Hashtable и Stack в новом коде не нужно.

Контейнеры Java — необходимый инструмент, которым вы будете постоянно пользоваться в своей повседневной работе; благодаря им ваш код станет более простым, мощным и эффективным. Возможно, на освоение некоторых аспектов контейнеров потребуется время, но вы быстро привыкнете к классам этой биб­лиотеки и начнете использовать их.

Обработка ошибок и исключения

Один из основополагающих принципов философии Java состоит в том, что «пло¬хо написанная программа не должна запускаться

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

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

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

Основные исключения

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

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

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

При возбуждении исключения происходит сразу несколько вещей. Во-пер- вых, создается объект, представляющий исключение, — точно так же, как и лю¬бой другой объект в Java (в куче, оператором new). Далее текущий поток испол¬нения (тот самый, где произошла ошибка) останавливается, и ссылка на объект, представляющий исключение, извлекается из текущего контекста. С этого мо¬мента включается механизм обработки исключений, который начинает поиск подходящего места программы для передачи исключения. Таким местом явля¬ется обработчик исключений, который пытается решить возникшую проблему так, чтобы программа могла снова попытаться выполнить проблемную опера¬цию или просто продолжила свое выполнение.

В качестве простого примера выдачи исключения представьте ссылку на объект t. Возможно, полученная вами ссылка не была инициализирована; стоит проверить это обстоятельство, прежде чем вызывать методы с использо¬ванием этой ссылки. Чтобы передать информацию об ошибке на более высо¬кий уровень, создайте объект, представляющий передаваемую информацию, и «запустите» его из текущего контекста. Тем самым вы возбудите исключение. Вот как это выглядит:

if(t — null)

throw new NullPointerException( );

Вырабатывается исключение, которое позволяет вам — в текущем контек¬сте — переложить с себя ответственность, не задумываясь о будущем. Ошибка, словно по волшебству, обрабатывается где-то в другом месте (вскоре мы узнаем, где именно).

Один из основополагающих аспектов исключений состоит в том, что при возникновении нежелательных ситуаций выполнение программы не продолжа¬ется по обычному пути. Исключения позволяют вам (в крайнем случае) остано¬вить программу и сообщить о возникших трудностях или (в идеале) разобрать¬ся с проблемой и вернуть программу в стабильное состояние.

Аргументы исключения

Исключения, как и любые объекты Java, создаются в куче оператором new, ко¬торый выделяет память и вызывает конструктор. У всех стандартных исключе¬ний существует два конструктора: стандартный (по умолчанию) и другой, со строковым аргументом, в котором можно разместить подходящую информа¬цию об исключении:

throw new NullPointerExceptionC't = null");

Переданная строка потом может быть извлечена различными способами, о чем будет рассказано позже.

Ключевое слово throw влечет за собой ряд довольно интересных действий. Как правило, сначала new используется для создания объекта, представляюще¬го условие происшедшей ошибки. Ссылка на указанный объект передается ко¬манде throw. Фактически этот объект «возвращается» методом, несмотря на то что для возвращаемого объекта обычно предусмотрен совсем другой тип. Та¬ким образом, упрощенно можно говорить об обработке исключений как об аль¬тернативном механизме возврата из исполняемого метода (впрочем, с этой ана¬логией не стоит заходить слишком далеко). Возбуждение исключений также позволяет выходить из простых блоков видимости. В обоих случаях возвраща¬ется объект исключения и происходит выход из текущего метода или блока.

Но все сходство с обычным возвратом из метода на этом заканчивается, по¬скольку при возврате из исключения вы попадаете совсем не туда, куда попали бы при нормальном вызове метода. (Обработчик исключения может находить¬ся очень «далеко» — на расстоянии нескольких уровней в стеке вызова — от ме¬тода, где возникла исключительная ситуация.)

Вообще говоря, можно возбудить любой тип исключений, происходящих от объекта Throwable (корневой класс иерархии исключений). Обычно для раз¬ных типов ошибок возбуждаются разные типы исключений. Информация о случившейся ошибке как содержится внутри объекта исключения, так и ука¬зывается косвенно в самом типе этого объекта, чтобы кто-то на более высоком уровне сумел выяснить, как поступить с исключением. (Нередко именно тип объекта исключения является единственно доступной информацией об ошибке, в то время как внутри объекта никакой полезной информации нет.)

Перехват исключений

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

Блок try

Если вы «находитесь» внутри метода и инициируете исключение (или это дела¬ет другой вызванный метод), этот метод завершит работу при возникновении исключения. Но если вы не хотите, чтобы оператор throw завершил работу ме¬тода, разместите в методе специальный блок для перехвата исключения — так называемый блок try. Этот блок представляет собой простую область действия, которой предшествует ключевое слово try:

try {

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

}

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

Обработчики исключений

Конечно, возбужденное исключение в конечном итоге должно быть где-то обра¬ботано. Этим местом является обработчик исключений, который создается для каждого исключения, которое вы хотите перехватить. Обработчики исключе¬ний размещаются прямо за блоком try и обозначаются ключевым словом catch:

try {

// Часть программы, способная возбуждать исключения } catch(Typel idl) {

// Обработка исключения Typel } catch(Туре2 id2) {

// Обработка исключения Туре2 } catch(ТуреЗ id3) {

// Обработка исключения ТуреЗ

}

//ИТ д.

Каждое предложение catch (обработчик исключения) напоминает малень¬кий метод, принимающий один и только один аргумент определенного типа. Идентификатор (idl, id2 и т. д.) может использоваться внутри обработчика точ¬но так же, как и метод распоряжается своими аргументами. Иногда этот иден¬тификатор остается невостребованным, так как тип исключения дает достаточ¬но информации для его обработки, но тем не менее присутствует он всегда.

Обработчики всегда следуют прямо за блоком try. При возникновении ис¬ключения механизм обработки исключений ищет первый из обработчиков ис¬ключений, аргумент которого соответствует текущему типу исключения. После этого он передает управление в блок catch, и таким образом исключение счита¬ется обработанным. После выполнения предложения catch поиск обработчиков исключения прекращается. Выполняется только одна секция catch, соответст¬вующая типу исключения; в этом отношении обработка исключений отличает¬ся от команды switch, где нужно дописывать break после каждого case, чтобы предотвратить исполнение всех прочих case.

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

Прерывание в сравнении с возобновлением

В теории обработки исключений имеется две основные модели. Модель преры¬вания (которое используется в Java и С++) предполагает, что ошибка настолько серьезна, что при возникновении исключения продолжить исполнение невоз¬можно. Кто бы ни возбудил исключение, сам факт его выдачи означает, что ис¬править ситуацию «на месте» невозможно и возвращать управление обратно не нужно.

Альтернативная модель называется возобновлением. Она подразумевает, что обработчик ошибок сделает что-то для исправления ситуации, после чего пред¬принимается попытка повторить неудавшуюся операцию в надежде на успеш¬ный исход. В таком случае исключение больше напоминает вызов метода — чтобы применить модель возобновления в Java, вам придется пойти именно по этому пути (то есть не возбуждать исключение, а вызвать метод, способный решить проблему). Также можно создать блок try внутри цикла while, который станет снова и снова обращаться к этому блоку, пока не будет достигнут нуж¬ный результат.

Исторически сложилось, что программисты, использующие операционные системы с поддержкой возобновления, со временем переходили к модели пре¬рывания, забывая другую модель. Хотя идея возобновления выглядит привле¬кательно, она не настолько полезна на практике. Основная причина кроется в обратной связи: обработчик ошибки часто должен знать, где произошло ис¬ключение и содержать специальный код для каждого отдельного места ошибки. А это усложняет написание и поддержку программ, особенно для больших сис¬тем, где исключения могут быть сгенерированы во многих различных местах.

Создание собственных исключений

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

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

//• exceptions/InheritingExceptions java

// Создание собственного исключения

class SimpleException extends Exception {}

public class InheritingExceptions {

public void f() throws SimpleException {

System.out.printin("Возбуждаем SimpleException из f()"). throw new SimpleException();

}

public static void main(String[] args) {

Inherit! ngExcepti ons sed = new InheritingExceptionsO;

try {

sed.fO; } catch(SimpleException e) {

System.out.println( Перехвачено!").

}

}

} /* Output

Возбуждаем SimpleException из f() Перехвачено! */// ~

Компилятор создает конструктор по умолчанию, который автоматически вызывает конструктор базового класса. Конечно, в этом случае вы лишаетесь конструктора вида SimpleException(String), но на практике он не слишком часто используется. Как вы еще увидите, наиболее важно в исключении именно имя класса, так что в основном исключений, похожих на созданное выше, будет дос¬таточно.

В примере результаты работы выводятся на консоль. Впрочем, их также можно направить в стандартный поток ошибок, что достигается использовани¬ем класса System.err. Обычно это правильнее, чем выводить в поток System.out, который может быть перенаправлен. При выводе результатов с помощью System, err пользователь заметит их скорее, чем при выводе в System.out.

Также можно создать класс исключения с конструктором, получающим ар¬гумент String:

//: exceptions/Full Constructors java

class MyException extends Exception { public MyException() {}

public MyException(String msg) { super(msg); }

}

public class Full Constructors {

public static void f() throws MyException {

System.out рппШГВозбуждаем MyException из fO"). throw new MyException();

}

public static void g() throws MyException {

System, out. pri ntl n( "Возбуждаем MyException из g(D; throw new MyException("Создано в g()");

}

public static void main(String[] args) { try {

f();

} catch(MyException e) {

e.printStackTrace(System.err);

}

try {

g();

} catch(MyException e) {

e.pri ntStackTrace(System.err):

}

}

} /* Output:

Возбуждаем MyException из f() продолжение &

MyException

at Ful1 Constructors.f(Ful1 Constructors.java:11) at Full Constructors main(FullConstructors.java-19) Возбуждаем MyException из g() MyException Создано в g()

at Full Constructors g(Ful1 Constructors java:15) at FullConstructors.main(FullConstructors.java 24)

III-

Изменения незначительны — появилось два конструктора, определяющие способ создания объекта MyException. Во втором конструкторе используется конструктор родительского класса с аргументом String, вызываемый ключевым словом super.

В обработчике исключений вызывается метод printStackTrace() класса Throwable (базового для Exception). Этот метод выводит информацию о последо¬вательности вызовов, которая привела к точке возникновения исключения. В нашем примере информация направляется в System.out, но вызов по умолча¬нию направляет информацию в стандартный поток ошибок:

e.printStackTraceO,

Регистрация исключений

Вспомогательное пространство имен java.utiLlogging позволяет зарегистриро¬вать информацию об исключениях в журнале. Базовые средства регистрации достаточно просты:

II exceptions/LoggingExceptions.java // Регистрация исключений с использованием Logger import java.util.logging *; import java.io *;

class LoggingException extends Exception { private static Logger logger =

Logger getLogger("LoggingException"); public LoggingException() {

StringWriter trace = new StringWriter(); printStackTrace(new PrintWriter(trace)), 1ogger.severe(trace.toStri ng()),

public class LoggingExceptions {

public static void main(String[] args) { try {

throw new LoggingException(); } catch(LoggingException e) {

System.err.println("Перехвачено " + e),

}

try {

throw new LoggingExceptionO: } catch(LoggingException e) {

System.err.println("Перехвачено " + e),

} /* Output (85Х match)

Aug 30, 2005 4:02:31 РМ LoggingException <init> SEVERE LoggingException

at LoggingExceptions.main(LoggingExceptions.java:19)

Перехвачено LoggingException

Aug 30, 2005 4.02.31 PM LoggingException <init>

SEVERE LoggingException

at Loggi ngExcepti ons.mai n(Loggi ngExcepti ons.j ava:24)

Перехвачено LoggingException */// -

Статический метод Logger.getLogger() создает объект Logger, ассоциируемый с аргументом String (обычно имя пакета и класса, к которому относятся ошиб¬ки); объект передает свой вывод в System.err. Простейший способ записи ин¬формации в Logger заключается в вызове метода, соответствующего уровню ошибки; в нашем примере используется метод severe(). Нам хотелось бы создать String для регистрируемого сообщения из результатов трассировки стека, но ме¬тод printStackTrace() по умолчанию не создает String. Для получения String необ¬ходимо использовать перегруженную версию printStackTrace() с аргументом java.io.PrintWriter (за подробными объяснениями обращайтесь к главе «Ввод/вы¬вод»). Если передать конструктору PrintWriter объект java.io. StringWriter, для по¬лучения вывода в формате String достаточно вызвать toString().

Подход LoggingException чрезвычайно удобен (вся инфраструктура регистра¬ции встроена в само исключение, и все работает автоматически без вмешательст¬ва со стороны клиента), однако на практике чаще применяется перехват и реги¬страция «сторонних» исключений, поэтому сообщение должно генерироваться в обработчике исключения:

//: exceptions/LoggingExceptions2.java // Регистрация перехваченных исключений, import java.util.logging.*; import java.io.*:

public class LoggingExceptions2 { private static Logger logger =

Logger.getLogger("Loggi ngExcepti ons2"): static void logException(Exception e) {

StringWriter trace = new StringWriter(); e.printStackTrace(new PrintWriter(trace)): 1ogger.severe(trace.toStri ng());

}

public static void main(String[] args) { try {

throw new NullPointerException(); } catch(NullPointerException e) { logException(e):

}

}

} /* Output: (90* match)

Aug 30, 2005 4:07:54 PM LoggingExceptions2 logException

SEVERE: java.lang.NullPointerException продолжение &

at LoggingExceptions2 main(LoggingExceptions2 java:16)

*///.-

На этом процесс создания собственных исключений не заканчивается — ис¬ключение можно снабдить дополнительными конструкторами и элементами:

//: exceptions/ExtraFeatures.java // Дальнейшее расширение классов исключений, import static net.mindview.util.Print.*:

class MyException2 extends Exception { private int x; public MyException2() {} public MyException2(String msg) { super(msg): } public MyException2(String msg, int x) { super(msg): this.x = x:

}

public int valО { return x: } public String getMessageO {

return "Подробное сообщение: "+ x + " " + super getMessageO:

public class ExtraFeatures {

public static void f() throws MyException2 { print("MyException2 в f()"), throw new MyException2():

}

public static void g() throws MyException2 {

System out.println("MyException2 в g()"); throw new MyException2("Возбуждено в g()");

}

public static void h() throws MyException2 {

System out.println("MyException2 в h()"): throw new MyException2("Возбуждено в h()", 47);

}

public static void main(String[] args) { try {

f():

} catch(MyException2 e) {

e.printStackTrace(System.out);

}

try {

g():

} catch(MyException2 e) {

e.printStackTrace(System out):

}

try {

h():

} catch(MyException2 e) {

e.printStackTrace(System.out):

System out.printlnC'e.valO = " + e.valO):

}

}

} /* Output: MyException2 в f()

MyException2: Подробное сообщение: 0 null

at ExtraFeatures.f(ExtraFeatures.java•22)

at ExtraFeatures.main(ExtraFeatures.java.34) MyException2 в g()

MyException2: Подробное сообщение: 0 Возбуждено в g()

at ExtraFeatures.g(ExtraFeatures.java:26) at ExtraFeatures.main(ExtraFeatures.java:39) MyException2: Подробное сообщение: 47 Возбуждено в h() at ExtraFeatures.h(ExtraFeatures.java:30) at ExtraFeatures.main(ExtraFeatures.java:44)

e.valO = 47 *///:-

Было добавлено поле данных х вместе с методом, считывающим его значе¬ние, а также дополнительный конструктор для инициализации х. Переопреде¬ленный метод Throwable.getMessage() выводит более содержательную информа¬цию об исключении. Метод getMessage() для классов исключений — аналог toStringO в обычных классах.

Так как исключение является просто видом объекта, расширение возможно¬стей классов исключений можно продолжить. Однако следует помнить, что все эти программисты, использующие ваши библиотеки, могут попросту проигно¬рировать все «украшения» — нередко программисты ограничиваются провер¬кой типа исключения (как чаще всего бывает со стандартными исключениями Java).

Спецификации исключений

В языке Java желательно сообщать программисту, вызывающему ваш метод, об исключениях, которые данный метод способен возбуждать. Пользователь, вызывающий метод, сможет написать весь необходимый код для перехвата воз¬можных исключений. Конечно, когда доступен исходный код, программист- клиент может пролистать его в поиске предложений throw, но библиотеки не всегда поставляются с исходными текстами. Чтобы библиотека не превраща¬лась в «черный ящик», в Java добавили синтаксис (обязательный для использо¬вания), при помощи которого вы сообщаете клиенту об исключениях, возбуж¬даемых методом, чтобы он сумел правильно обработать их. Этот синтаксис называется спецификацией исключений (exception specification), входит в объяв¬ление метода и следует сразу за списком аргументов.

Спецификация исключений состоит из ключевого слова throws, за которым перечисляются все возможные типы исключений. Примерное определение ме¬тода будет выглядеть так:

void f() throws TooBig. TooSmall. DivZero { //...

Однако запись

void f() { // ...

означает, что метод не вырабатывает исключений. (Кроме исключений, произ¬водных от RuntimeException, которые могут быть возбуждены практически в лю¬бом месте — об этом еще будет сказано.)

Обойти спецификацию исключений невозможно — если ваш метод возбуж¬дает исключения и не обрабатывает их, компилятор предложит либо обрабо¬тать исключение, либо включить его в спецификацию. Жестким контролем за соблюдением правил сверху донизу Java гарантирует правильность исполь¬зования механизма исключений во время компиляции программы.

Впрочем, «обмануть» компилятор все же можно: вы вправе объявить о воз¬буждении исключения, которого на самом деле нет. Компилятор верит вам на слово и заставляет пользователей метода поступать так, как будто им и в са¬мом деле необходимо перехватывать исключение. Таким образом можно «заре¬зервировать» исключение на будущее и уже потом возбуждать его, не изменяя описания готовой программы. Такая возможность может пригодиться и для создания абстрактных базовых классов и интерфейсов, в производных классах которых может возникнуть необходимость в возбуждении исключений.

Исключения, которые проверяются и навязываются еще на этапе компиля¬ции программы, называют контролируемыми (checked).

Перехват произвольных исключений

Можно создать универсальный обработчик, перехватывающий любые типы ис¬ключения. Осуществляется это перехватом базового класса всех исключений Exception (существуют и другие базовые типы исключений, но класс Exception является базовым практически для всех программных исключительных ситуа¬ций):

catch(Exception е) {

System.out рппШСПерехвачено исключение");

}

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

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

• String getMessage(), String getLocalizedMessage() возвращают подробное со¬общение об ошибке (или сообщение, локализованное для текущего контекста);

• String toString() возвращает короткое описание объекта Throwable, вклю¬чая подробное сообщение, если оно присутствует;

• void printStackTrace(), void printStackTrace(PrintStream), void printStack- Trace(java.io.PrintWriter) выводят информацию об объекте Throwable и трассировку стека вызовов для этого объекта. Трассировка стека вызо¬вов показывает последовательность вызова методов, которая привела к точке возникновения исключения. Первый вариант отправляет ин¬формацию в стандартный поток ошибок, второй и третий — в поток по

вашему выбору (в главе «Ввод/вывод» вы поймете, почему типов пото¬ков два);

• Throwable fiUInStackTrace() записывает в объект Throwable информацию о текущем состоянии стека. Метод используется при повторном возбужде¬нии ошибок или исключений.

Вдобавок в вашем распоряжении находятся методы типа Object, базового для Throwable (и для всех остальных классов). При использовании исключений мо¬жет пригодиться метод getClass(), который возвращает информацию о классе объекта. Эта информация заключена в объекте типа Class. Например, вы можете узнать имя класса вместе с информацией о пакете методом getName() или полу¬чить только имя класса методом getSimpleName().

Рассмотрим пример с использованием основных методов класса Exception:

//. exceptions/ExceptionMethods.java // Демонстрация методов класса Exception, import static net.mindview.util.Print.*;

public class ExceptionMethods {

public static void main(String[] args) { try {

throw new Exception("Мое исключение"); } catch(Exception e) {

print("Перехвачено"). print("getMessage():" + e.getMessageO); print("getLocalizedMessage()." +

e.getLocali zedMessage());

print ("toStringO." + e); print("printStackTrace():"); e.printStackTrace(System.out);

}

}

} /* Output. Перехвачено

getMessageO :Moe исключение

getLocalizedMessage().Мое исключение

toStringO.java.lang.Exception: Мое исключение

printStackTraceO:

java lang Exception: Мое исключение

at ExceptionMethods main(ExceptionMethods.java 8)

*///:-

Как видите, методы последовательно расширяют объем выдаваемой инфор¬мации — всякий последующий фактически является продолжением предыду¬щего.

Трассировка стека

Информацию, предоставляемую методом printStackTrace(), также можно полу¬чить напрямую вызовом getStackTrace(). Метод возвращает массив элементов трассировки, каждый из которых представляет один кадр стека. Нулевой эле¬мент представляет вершину стека, то есть последний вызванный метод после¬довательности (точка, в которой был создан и инициирован объект Throwable).

Соответственно, последний элемент массива представляет «низ» стека, то есть первый вызванный элемент последовательности. Рассмотрим простой пример:

//: exceptions/WhoCalled.java

// Программный доступ к данным трассировки стека

public class WhoCalled { static void f() {

// Выдача исключения для заполнения трассировочных данных try {

throw new ExceptionO; } catch (Exception e) {

for(StackTraceElement ste : e.getStackTraceO)

System.out.pri nt1n(ste.getMethodName()):

}

}

static void g() { f(): } static void h() { g(); } public static void main(String[] args) { f():

System.out.printlnC ");

g():

System, out. printlnC'-- "):

h();

}

} /* Output: f

main

f g

main

f g

h

main *///:-

Повторное возбуждение исключения

В некоторых ситуациях требуется заново возбудить уже перехваченное исклю¬чение; чаще всего это происходит при использовании Exception для перехвата всех исключений. Так как ссылка на текущее исключение уже имеется, вы по¬просту возбуждаете исключение по этой ссылке:

catch(Exception е) {

System, out. pri nti пСБыло возбуждено исключение"): throw e:

}

При повторном возбуждении исключение передается в распоряжение обра¬ботчика более высокого уровня. Все остальные предложения catch текущего блока try игнорируются. Вся информация из объекта, представляющего исклю¬чение, сохраняется, и обработчик более высокого уровня, перехватывающий подобные исключения, сможет ее извлечь.

Если вы просто заново возбуждаете исключение, информация о нем, выво¬димая методом printStackTrace(), будет по-прежнему относиться к месту воз¬никновения исключения, но не к месту его повторного возбуждения. Если вам понадобится использовать новую трассировку стека, вызовите метод fi LLI n S ta с kT г а с e (), который возвращает исключение (объект Throwable), созданное на базе старого с помещением туда текущей информации о стеке. Вот как это выглядит:

// exceptions/Rethrowing.java // Демонстрация метода fillInStackTraceO

public class Rethrowing {

public static void f() throws Exception {

System.out.рппШССоздание исключения в f(D; throw new Exception ("возбуждено из f(D;

}

public static void g() throws Exception { try {

f().

} catch(Exception e) {

System, out. pri ntl n("B методе g(), e printStackTraceO"). e printStackTrace(System.out); throw e,

}

}

public static void h() throws Exception { try {

f():

} catch(Exception e) {

System out.printlnC'B методе h(), e.printStackTrace()"),

e printStackTrace(System.out),

throw (Exception)e fill InStackTraceO,

}

}

public static void main(String[] args) { try {

go.

} catch(Exception e) {

System, out pri ntl n( "main- printStackTraceO"). e.printStackTrace(System out);

}

try {

hO.

} catch(Exception e) {

System out.printlnCmairr printStackTraceO"); e printStackTrace(System out);

}

}

} /* Output

Создание исключения в fO

java lang Exception thrown from f()

at Rethrowing.f(Rethrowing.java 7) at Rethrowing g(Rethrowing java:11) at Rethrowi ng.mai n(Rethrowi ng.java:29) main. printStackTraceO

java.lang.Exception: thrown from f() продолжение &

at Rethrowing.f(Rethrowing.java.7) at Rethrowing.g(Rethrowing java.11) at Rethrowing.main(Rethrowing.java 29) Создание исключения в f() В методе h(). e.printStackTraceO java.lang.Exception, thrown from f()

at Rethrowi ng.f(Rethrowi ng.java•7) at Ret h rowi ng. h (Reth rowi ng. j a va: 20) at Rethrowing main(Rethrowing.java-35) main- printStackTraceO java lang.Exception: thrown from f()

at Ret h rowi ng. h (Ret h rowi ng. j a va • 24) at Rethrowi ng.mai n(Rethrowi ng.java:35)

*///:-

Строка с вызовом fiUInStackTrace() становится новой точкой выдачи исклю¬чения.

Выдаваемое исключение также может отличаться от исходного. В этом слу¬чае эффект получается примерно таким же, как при использовании fillln- StackTrace() — информация о месте зарождения исключения теряется, а остает¬ся информация, относящаяся к новой команде throw.

//: exceptions/RethrowNew java // Повторное возбуждение объекта, // отличающегося от первоначального

class OneException extends Exception {

public OneException(String s) { super(s); }

}

class TwoException extends Exception {

public TwoException(String s) { super(s), }

}

public class RethrowNew {

public static void f() throws OneException {

System.out printin("создание исключения в f(D; throw new OneException("из f()");

}

public static void main(String[] args) { try {

try {

f().

} catch(OneException e) {

System out.printin(

"Во внутреннем блоке try.

e printStackTraceO"). .

e.printStackTrace(System.out);

throw new TwoException("из внутреннего блока try"),

}

} catch(TwoException e) {

System.out.printin(

"Во внешнем блоке try, e.printStackTraceO"), e.printStackTrace(System.out),

}

}

создание исключения в f()

Во внутреннем блоке try, е.printStackTraceO

OneException- thrown from fO

at RethrowNew.f(RethrowNew.java•15) at Reth rowNew.ma i n(Reth rowNew.j ava•20) Во внешнем блоке try, e.printStackTraceO TwoException из внутреннего блока try

at RethrowNew main(RethrowNew.java 25)

*///.-

О последнем исключении известно только то, что оно поступило из внутрен¬него блока try, но не из метода f().

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

Цепочки исключений

Зачастую необходимо перехватить одно исключение и возбудить следующее, не потеряв при этом информации о первом исключении — это называется цепоч¬кой исключений (exception chaining). До выпуска пакета JDK 1.4 программистам приходилось самостоятельно писать код, сохраняющий информацию о преды¬дущем исключении, однако теперь конструкторам всех подклассов Throwable может передаваться объект-причина (cause). Предполагается, что причиной яв¬ляется изначальное исключение и передача ее в новый объект обеспечивает трассировку стека вплоть до самого его начала, хотя при этом создается и воз¬буждается новое исключение.

Интересно отметить, что единственными подклассами класса Throwable, при¬нимающими объект-причину в качестве аргумента конструктора, являются три основополагающих класса исключений: Error (используется виртуальной маши¬ной (JVM) для сообщений о системных ошибках), Exception и RuntimeException. Для организации цепочек из других типов исключений придется использовать метод initCause(), а не конструктор.

Следующий пример демонстрирует динамическое добавление полей в объ¬ект DynamicFields во время работы программы:

//. exceptions/DynamicFields.java // Динамическое добавление полей в класс. // Пример использования цепочки исключений, import static net mindview.util Print *;

class DynamicFieldsException extends Exception {}

public class DynamicFields { private Object[][] fields; public DynamicFields(int initialSize) {

fields = new 0bject[initialSize][2]. for(int i = 0. i < initialSize. i++)

fields[i] = new Object[] { null, null };

}

public String toStringO {

StringBuilder result = new StringBuilderO. . Л

продолжение &

for(Objected obj : fields) {

result.append(obj[0]); result.append("• "); result.append(obj[l]); result.append("\n");

}

return result.toStringO;

}

private int hasField(String id) {

for(int i = 0; i < fields.length; i++) if(id.equals(fields[1][0])) return i;

return -1:

}

private int

getFieldNumber(String id) throws NoSuchFieldException { int fieldNum = hasField(id); if(fieldNum == -1)

throw new NoSuchFieldException0; return fieldNum;

}

private int makeField(String id) {

for(int i = 0; i < fields.length; i++) 1f(f1elds[i][0] == null) { fields[1][0] « id; return i;

}

// Пустых полей нет. Добавим новое:

Object[][]tmp = new Object[fields.length + 1][2];

for(int i = 0; i < fields.length; i++)

tmp[i] = fields[i]; for(int i = fields.length; i < tmp.length; i++) tmp[i] = new Object[] { null, null }; fields = tmp;

// Рекурсивный вызов с новыми полями: return makeField(id);

}

public Object

getField(String id) throws NoSuchFieldException { return fields[getFieldNumber(id)][l];

}

public Object setField(String id. Object value)

throws DynamicFieldsException { if(value == null) {

// У большинства исключений нет конструктора.

// принимающего объект-«причину».

// В таких случаях следует использовать

// метод initCauseO, доступный всем подклассам

// класса Throwable.

DynamicFieldsException dfe =

new DynamicFieldsExceptionO; dfe.i ni tCause(new Nul1Poi nterExcepti on О); throw dfe;

}

int fieldNumber = hasField(id); if(fieldNumber == -1)

fieldNumber = makeField(id); Object result = null;

try {

result = getField(id). 11 Получаем старое значение } catchCNoSuchFieldException e) {

// Используем конструктор с «причиной» throw new RuntimeException(e),

}

fields[fieldNumber][l] = value; return result;

}

public static void main(String[] args) {

DynamicFields df = new DynamicFields(3); print(df); try {

df setFieldC'd". "Значение d"); df setField("число", 47); df.setField("4Haio2\ 48); print(df);

df.setFieldC'd". "Новое значение d"), df setField("4HOio3". 11). printCdf: " + df).

printCdf getField(\"d\")) " + df getFieldCd")); Object field = df setFieldC'd". null). // Исключение } catch(NoSuchFieldException e) {

e printStackTrace(System out); } catch(DynamicFieldsException e) {

e.printStackTrace(System.out);

}

}

} /* Output: null null null: null' null: null d: Значение d число: 47 число2: 48

df- d- Новое значение d число: 47 число:2 48 числоЗ- 11

Значение df .getFieldCd") . Новое значение d Dynami cFi eldsExcepti on

at DynamicFields.setField(DynamicFields.java:64) at DynamicFields main(DynamicFields java:94) Caused by: java.lang.NullPointerException

at DynamicFields.setField(DynamicFields.java 66) )

Каждый объект DynamicFields содержит массив пар Object-Object. Первый объ¬ект содержит идентификатор поля (String), а второй объект — значение поля, которое может быть любого типа, кроме неупакованных примитивов. При соз¬дании объекта необходимо оценить примерное количество полей. Метод setField() либо находит уже существующее поле с заданным именем, либо создает новое поле и сохраняет значение. Когда пространство для полей заканчивается, метод наращивает его, создавая массив размером на единицу больше и копи¬руя в него старые элементы. При попытке размещения пустой ссылки null ме¬тод инициирует исключение DynamicFieldsException, создавая объект нужного типа и передавая методу initCause() в качестве причины исключение NullPointer- Exception.

Для возвращаемого значения метод setField() использует старое значение поля, получая его методом getField(), который может возбудить исключение NoSuchFieldException. Если метод getField() вызывает программист-клиент, то он ответственен за обработку возможного исключения NoSuchFieldException, однако, если последнее возникает в методе setField(), это является ошибкой программы; соответственно, полученное исключение преобразуется в исключение Runtime- Exception с помощью конструктора, принимающего аргумент-причину.

Для создания результата toStringO использует объект StringBuilder. Этот класс будет подробно рассмотрен при описании работы со строками.

Стандартные исключения Java

Класс Java Throwable описывает все объекты, которые могут возбуждаться как исключения. Существует две основные разновидности объектов Throwable (то есть ветви наследования). Тип Error представляет системные ошибки и ошибки времени компиляции, которые обычно не перехватываются (кроме нескольких особых случаев). Тип Exception может быть возбужден из любого метода стандартной библиотеки классов Java или пользовательского метода в случае неполадок при исполнении программы. Таким образом, для програм¬мистов интерес представляет прежде всего тип Exception.

Лучший способ получить представление об исключениях — просмотреть до¬кументацию JDK. Стоит сделать это хотя бы раз, чтобы получить представле¬ние о различных видах исключений, но вскоре вы убедитесь в том, что наиболее принципиальным различием между разными исключениями являются их имена. К тому же количество исключений в Java постоянно растет, и едва ли имеет смысл описывать их в книге. Любая программная библиотека от стороннего про¬изводителя, скорее всего, также будет иметь собственный набор исключений. Здесь важнее понять принцип работы и поступать с исключениями сообразно.

Основной принцип заключается в том, что имя исключения относительно полно объясняет суть возникшей проблемы. Не все исключения определены в пакете java.lang, некоторые из них созданы для поддержки других библиотек, таких как util, net и io, как можно видеть из полных имен их классов или из ба¬зовых классов. Например, все исключения, связанные с вводом/выводом (I/O), унаследованы от java.io.IOException.

Особый случай: RuntimeException

Вспомним первый пример в этой главе:

if(t == null)

throw new NullPointerExceptionO;

Только представьте, как ужасно было бы проверять таким образом каждую ссылку, переданную вашему методу. К счастью, делать это не нужно — такая проверка автоматически выполняется во время исполнения Java-программы, и при попытке использования null-ссылок автоматически возбуждается Null- PointerException.Таким образом, использованная в примере конструкция избы¬точна.

Есть целая группа исключений, принадлежащих к этой категории. Они все¬гда возбуждаются в Java автоматически, и вам не придется включать их в спе¬цификацию исключений. Все они унаследованы от одного базового класса RuntimeException, что дает нам идеальный пример наследования: семейство классов, имеющих общие характеристики и поведение. Вам также не придется создавать спецификацию исключений, указывающую на возбуждение методом RuntimeException (или любого унаследованного от него исключения), так как эти исключения относятся к неконтролируемым (unchecked). Такие исключения означают ошибки в программе, и фактически вам никогда не придется перехва¬тывать их — это делается автоматически. Проверка RuntimeException привела бы к излишнему загромождению программы. И хотя вам обычно не требуется пе¬рехватывать RuntimeException, возможно, вы посчитаете нужным возбуждать не¬которые из них в своих собственных библиотеках программ.

Что же происходит, когда подобные исключения не перехватываются? Так как компилятор не заставляет перечислять такие исключения в спецификациях, можно предположить, что исключение RuntimeException проникнет прямо в ме¬тод mainQ, и не будет перехвачено. Чтобы увидеть все в действии, испытайте следующий цример:

//: exceptions/NeverCaught java

// Игнорирование RuntimeExceptions.

// {ThrowsException}

public class NeverCaught {

static void f() {

throw new RuntimeException("H3 f(D;

}

static void g() { f();

}

public static void mainCString[] args) {

g():

}

} ///.-

Можно сразу заметить, что RuntimeException (и все от него унаследованное) является специальным случаем, так как компилятор не требует для него специ¬фикации исключения. Выходные данные выводятся в System.err:

Exception in thread "main" java.lang.RuntimeException- Из f() at NeverCaught.f(NeverCaught.java:7) at NeverCaught.g(NeverCaught.java:10) at NeverCaught.main(NeverCaught.java-13)

Мы приходим к ответу на поставленный вопрос: если RuntimeException доби¬рается до main() без перехвата, то работа программы завершается с вызовом ме¬тода printStackTraceO.

Помните, что только исключения типа RuntimeException (и производных классов) могут игнорироваться во время написания текста программы, в то вре¬мя как остальные действия компилятор осуществляет в обязательном порядке. Это объясняется тем, что RuntimeException является следствием ошибки про¬граммиста, например:

• ошибки, которую невозможно предвидеть (к примеру, получение null- ссылки в вашем методе, переданной снаружи);

• ошибки, которую вы как программист должны были проверить в вашей программе (подобной ArraylndexOutOfBoundsException, с проверкой разме¬ра массива). Ошибки первого вида часто становятся причиной ошибок второго вида.

В подобных ситуациях исключения оказывают неоценимую помощь в отла¬дочном процессе.

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

Завершение с помощью finally

Часто встречается ситуация, когда некоторая часть программы должна выполнять¬ся независимо от того, было или нет возбуждено исключение внутри блока try. Обычно это имеет отношение к операциям, не связанным с освобождением памя¬ти (так как это входит в обязанности сборщика мусора). Для достижения желае¬мой цели необходимо разместить блок finally  после всех обработчиков исключе¬ний. Таким образом, полная конструкция обработки исключения выглядит так:

try {

// Защищенная секция: рискованные операции, // которые могут породить исключения А, В. или С } catch(A al) {

// Обработчик для ситуации А } catch(B Ы) {

// Обработчик для ситуации В } catch(C cl) {

// Обработчик для ситуации С } finally {

// Действия, производимые в любом случае

}

Чтобы продемонстрировать, что блок finally выполняется всегда, рассмотрим следующую программу:

//: exceptions/FinallyWorks.java // Блок finally выполняется всегда

class ThreeException extends Exception {}

public class FinallyWorks { static int count = 0; public static void main(String[] args) { while(true) { try {

// Операция постфиксного приращения, в первый раз 0: if(count++ == 0)

throw new ThreeExceptionO; System.out.println("Нет исключения"); } catch(ThreeException e) {

System.out.pri ntln("ThreeExcepti on"); } finally {

System.out.println("B блоке finally"); if(count == 2) break; // вне цикла "while"

}

}

}

} /* Output: ThreeException В блоке finally Нет исключения В блоке finally *///-

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

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

Для чего нужен блок finally?

В языках без сборки мусора и без автоматических вызовов деструкторов  блок finally гарантирует освобождение ресурсов и памяти независимо от того, что случилось в блоке try. В Java существует сборщик мусора, поэтому с освобожде¬нием памяти проблем не бывает. Также нет необходимости вызывать деструк¬торы, их просто нет. Когда же нужно использовать finally в Java?

Блок finally необходим тогда, когда в исходное состояние вам необходимо вернуть что-то другое, а не память. Это может быть, например, открытый файл или сетевое подключение, часть изображения на экране или даже какой-то фи¬зический переключатель, вроде смоделированного в следующем примере:

//: exceptions/Switch.java

import static net mindview.util.Print.*;

class Switch {

private boolean state = false; public boolean readO { return state, } public void on() { state = true, print(this); } public void offО { state = false, print(this), } public String toStringO { return state ? "on" • "off"; } } ///.-

//. exceptions/OnOffException]..java

public class OnOffExceptionl extends Exception {} lll-

ll . exceptions/0n0ffException2.java

public class 0n0ffException2 extends Exception {} III ~

//• exceptions/OnOffSwitch java 11 Для чего нужно finally?

public class OnOffSwitch {

private static Switch sw = new SwitchO; static void f()

throws OnOffExceptionl, 0n0ffException2 {} public static void main(String[] args) { try {

sw.onO;

// Код, способный возбуждать исключения... f();

sw off(): } catch(OnOffExceptionl e) {

System.out.pri ntin("OnOffExcepti onl"); sw.offO; } catch(OnOffException2 e) {

System.out.pri ntin("OnOffExcepti on2"); sw.offO:

}

}

} /* Output-

on

off

*///:-

Наша цель — убедиться в том, что переключатель был выключен по завер¬шении метода main(), поэтому в конце блока try и в конце каждого обработчика исключения помещается вызов sw.off(). Однако в программе может возникнуть неперехватываемое исключение, и тогда вызов sw.off() будет пропущен. Однако благодаря finally завершающий код можно поместить в одном определенном месте:

II: exceptions/WithFinally.java 11 Finally гарантирует выполнение завершающего кода.

public class WithFinally {

static Switch sw = new SwitchO; public static void main(String[] args) { try {

sw.onO;

// Код, способный возбуждать исключения. OnOffSwitch.fO; } catch(OnOffExceptionl e) {

System out.printing"OnOffExceptionl"); } catch(OnOffException2 e) {

System out println( OnOffException2"); } finally {

sw.offO;

}

}

} /* Output:

on

off

*///:-

Здесь вызов метода sw.off() просто перемещен в то место, где он гарантиро¬ванно будет выполнен.

Даже если исключение не перехватывается в текущем наборе условий catch, блок finally отработает перед тем, как механизм обработки исключений продол¬жит поиск обработчика на более высоком уровне:

//: exceptions/AlwaysFinally.java

// Finally выполняется всегда

import static net.mindview.util Print.*:

class FourException extends Exception {}

public class AlwaysFinally {

public static void main(String[] args) {

print("Входим в первый блок try"), try {

print("Входим во второй блок try"): try {

throw new FourExceptionO, } finally {

print("finally во втором блоке try"):

}

} catch(FourException e) { System.out.println(

"Перехвачено FourException в первом блоке try"):

} finally {

System.out.println("finally в первом блоке try"):

}

}

} /^Output-

Входим в первый блок try Входим во второй блок try finally во втором блоке try Перехвачено FourException в первом блоке try finally в первом блоке try *///:-

Блок finally также исполняется при использовании команд break и continue. Заметьте, что комбинация finally в сочетании с break и continue с метками снима¬ет в Java всякую необходимость в операторе goto.

Использование finally с return

Поскольку секция finally выполняется всегда, важные завершающие действия будут выполнены даже при возврате из нескольких точек метода:

//• excepti ons/Multi pleReturns java import static net.mindview util Print.*;

public class MultipleReturns {

public static void f(int i) {

pri nt("Инициализация. требующая завершения"), try {

print("Точка 1"), if(i == 1) return, print("Точка 2"); if(i == 2) return, print("Точка 3"), if(i == 3) return, print("Конец"), return; } finally {

ргШС'Завершение"),

}

}

public static void main(String[] args) { for (int i =1, i <=4; i++) f(i).

}

} /* Output;

Инициализация, требующая завершения

Точка 1

Завершение

Инициализация, требующая завершения Точка 1 Точка 2 Завершение

Инициализация, требующая завершения

Точка 1

Точка 2

Точка 3

Завершение

Инициализация, требующая завершения

Точка 1

Точка 2

Точка 3

Конец

Завершение *///;-

Из выходных данных видно, что выполнение finally не зависит от того, в ка¬кой точке защищенной секции была выполнена команда return.

Проблема потерянных исключений

К сожалению, реализация механизма исключений в Java не обошлась без изъяна. Хотя исключение сигнализирует об аварийной ситуации в программе и никогда

Использование finally с return 335

не должно игнорироваться, оно может быть потеряно. Это происходит при ис¬пользовании finally в конструкции определенного вида:

//: exceptions/LostMessage.java // Как теряются исключения.

class VeryImportantException extends Exception { public String toStringO {

return "Очень важное исключение!";

}

}

class HoHumException extends Exception { public String toStringO {

return "Второстепенное исключение";

}

}

public class LostMessage {

void fO throws VerylmportantException {

throw new VerylmportantExceptionO;

}

void disposeO throws HoHumException { throw new HoHumExceptionO;

}

public static void main(String[] args) { try {

LostMessage 1m = new LostMessageO; try {

lm.fO; } finally {

lm. disposeO; } catch(Exception e) {

System.out.println(e);

}

}

} /* Output:

Второстепенное исключение *///:-

В выводе нет никаких признаков VerylmportantException, оно было просто за¬мещено исключением HoHumException в предложении finally. Это очень серьез¬ный недочет, так как потеря исключения может произойти в гораздо более скрытой и трудно диагностируемой ситуации, в отличие от той, что показана в примере. Например, в С++ подобная ситуация (возбуждение второго исключе¬ния без обработки первого) рассматривается как грубая ошибка программиста. Возможно, в новых версиях Java эта проблема будет решена (впрочем, любой метод, способный возбуждать исключения — такой, как dispose() в приведенном примере — обычно заключается в конструкцию try-catch).

Еще проще потерять исключение простым возвратом из finally:

И: exceptions/ExceptionSi1encer.java

public class ExceptionSilencer {

public static void main(String[] args) { try {

throw new RuntimeExceptionO: } finally {

// Команда 'return' в блоке finally // прерывает обработку исключения return;

}

}

} ///.-

Запустив эту программу, вы увидите, что она ничего не выводит — несмотря на исключение.

Ограничения при использовании исключений

В переопределенном методе можно возбуждать только те исключения, которые были описаны в методе базового класса. Это полезное ограничение означает, что программа, работающая с базовым классом, автоматически сможет работать и с объектом, произошедшим от базового (конечно, это фундаментальный прин¬цип ООП), включая и исключения.

Следующий пример демонстрирует виды ограничений (во время компиля¬ции), наложенные на исключения:

//: exceptions/Stormylnning java // Переопределенные методы могут возбуждать только // исключения, описанные в версии базового класса, // или исключения, унаследованные от исключений // базового класса.

class BaseballException extends Exception {} class Foul extends BaseballException {} class Strike extends BaseballException {}

abstract class Inning {

public InningO throws BaseballException {} public void event О throws BaseballException { // Реальное исключение не возбуждается

}

public abstract void atBatO throws Strike. Foul;

public void walkO {} // He возбуждает контролируемых исключений

}

class StormException extends Exception {} class RainedOut extends StormException {} class PopFoul extends Foul {}

interface Storm {

public void event() throws RainedOut; public void rainHardO throws RainedOut;

}

public class Stormylnning extends Inning implements Storm { // Можно добавлять новые исключения для конструкторов. // но нужно учитывать и исключения базового конструктора; public StormyInning()

throws RainedOut. BaseballException {}

public StormyInning(String s)

throws Foul. Baseball Exception {} // Обычные методы должны соответствовать базовым: //! void walkO throws PopFoul {} // Ошибка компиляции // Интерфейс не МОЖЕТ добавлять исключения к // существующим методам базового класса: //! public void event О throws RainedOut {} // Если метод не был определен в базовом // классе, исключение допускается, public void rainHardO throws RainedOut {} // Метод может не возбуждать исключений вообще. // даже если базовая версия это делает: public void eventО {} // Переопределенные методы могут возбуждать // унаследованные исключения: public void atBatO throws PopFoul {} public static void main(String[] args) { try {

Stormy Inning si = new Stormy I nningO; si atBatO: } catch(PopFoul e) {

System.out.println("Pop foul"); } catch(RainedOut e) {

System.out printlnCRained out"): } catch(BaseballException e) {

System.out.println("Обобщенное исключение ");

}

// Strike не возбуждается в производной версии, try {

// Что произойдет при восходящем преобразовании? Inning i = new StormylnningO: i. atBatO:

// Необходимо перехватывать исключения из // базовой версии метода: } catch(Strike е) {

System.out.println("Strike"); } catch(Foul e) {

System.out.println("Foul"): } catch(RainedOut e) {

System.out.println("Rained out"): } catch(BaseballException e) {

System.out.println("Обобщенное исключение"):

}

}

} III-

В классе Inning и конструктор, и метод event() объявляют, что будут возбуж¬дать исключения, но в действительности этого не делают. Это допустимо, по¬скольку подобный подход заставляет пользователя перехватывать все виды ис¬ключений, которые потом могут быть добавлены в переопределенные версии метода event(). Данный принцип распространяется и на абстрактные методы, что и показано для метода atBat().

Интерфейс Storm интересен тем, что содержит один метод (event()), уже опре¬деленный в классе Inning, и один уникальный. Оба метода возбуждают новый тип исключения RainedOut. Когда класс Stormylnning расширяет Inning и реализует интерфейс Storm, выясняется, что метод event() из Storm не способен изменить тип исключения для метода event() класса Inning. Опять-таки это вполне разум¬но, так как иначе вы бы никогда не знали, перехватываете ли нужное исключе¬ние в случае работы с базовым классом. Конечно, когда метод, описанный в ин¬терфейсе, отсутствует в базовом классе (как rainHard()), никаких проблем с возбуждением исключений нет.

Метод StormyInning.walk() не компилируется из-за того, что он возбуждает исключение, тогда как Inning.walk() такого не делает. Если бы это позволялось, вы могли бы написать код, вызывающий метод Inning.walk() и не перехватываю¬щий никаких исключений, а потом при подстановке объекта класса, производ¬ного от Inning, возникли бы исключения, нарушающие работу программы. Таким образом, принудительно обеспечивая соответствие спецификаций исключений в производных и базовых версиях методов, Java добивается взаимозаменяемо¬сти объектов.

Переопределенный метод event() показывает, что метод производного класса может вообще не возбуждать исключений, даже если это делается в базовой версии. Опять-таки это нормально, так как не влияет на уже написанный код — подразумевается, что метод базового класса возбуждает исключения. Аналогич¬ная логика применима для метода atBat(), возбуждающего исключение PopFoul, производное от Foul, которое возбуждается базовой версией atBat(). Итак, если вы пишете код, работающий с Inning и вызывающий atBat(), то он должен пере¬хватывать исключение Foul. Так как PopFoul наследует от Foul, обработчик ис¬ключения для Foul перехватит и PopFoul.

Последний интересный момент встречается в методе main(). Мы видим, что при работе именно с объектом Stormylnning компилятор заставляет перехваты¬вать только те исключения, которые характерны для этого класса, но при восхо¬дящем преобразовании к базовому типу компилятор заставляет перехватывать исключения из базового класса. Все эти ограничения значительно повышают ясность и надежность кода обработки исключений .

Хотя компилятор заставляет описывать исключения при наследовании, спе¬цификация исключений не является частью объявления (сигнатуры) метода, которое состоит только из имени метода и типов аргументов. Соответственно, нельзя переопределять методы только по спецификациям исключений. Вдоба¬вок, даже если спецификация исключения присутствует в методе базового класса, это вовсе не гарантирует его существования в методе производного класса. Данная практика сильно отличается от правил наследования, по кото¬рым метод базового класса обязательно присутствует и в производном классе. Другими словами, «интерфейс спецификации исключений» для определенного метода может сузиться в процессе наследования и переопределения, но никак не расшириться — и это прямая противоположность интерфейсу класса во вре¬мя наследования.

Конструкторы

При программировании обработки исключений всегда спрашивайте себя: «Ес¬ли произойдет исключение, будет ли все корректно завершено?» Чаще все идет более или менее безопасно, но с конструкторами возникает проблема. Конст¬руктор приводит объект в определенное начальное состояние, но может начать выполнять какое-либо действие — такое как открытие файла — которое не бу¬дет правильно завершено, пока пользователь не освободит объект, вызвав спе¬циальный завершающий метод. Если исключение произойдет в конструкторе, эти финальные действия могут быть исполнены ошибочно. А это означает, что при написании конструкторов необходимо быть особенно внимательным.

Казалось бы, блок finally решает все проблемы. Но в действительности все сложнее — ведь finally выполняется всегда, и даже тогда, когда завершающий код не должен активизироваться до вызова какого-то метода. Если сбой в кон¬структоре произойдет где-то на середине, может оказаться, что часть объекта, освобождаемая в finally, еще не была создана.

В следующем примере создается класс, названный InputFile, который откры¬вает файл и позволяет читать из него по одной строке. Он использует классы FileReader и BufferedReader из стандартной библиотеки ввода/вывода Java, кото¬рая будет изучена далее, но эти классы достаточно просты, и у вас не возникнет особых сложностей при работе с ними:

// exceptions/InputFile java // Специфика исключений в конструкторах import java io *.

public class InputFile {

private BufferedReader in,

public InputFi1eCString fname) throws Exception { try {

in = new BufferedReader(new FileReader(fname)); // Остальной код, способный возбуждать исключения } catch(FileNotFoundException e) {

System out рппШС'Невозможно открыть " + fname); // Файл не открывался, поэтому не может быть закрыт throw е; } catch(Exception е) {

// При других исключениях файл должен быть закрыт try {

in.closeO; } catch(IOException e2) {

System out.println("in.close() исполнен неудачно");

}

throw e; // Повторное возбуждение } finally {

// He закрывайте файл здесь!!!

}

}

public String getLineO { String s, try {

s = in. readLine(); продолжение & } catch(IOException е) {

throw new RuntimeExceptionC'readLineO исполнен неудачно");

}

return s;

}

public void disposeO { try {

in.closeO;

System.out.printlnC'disposeO успешен"); } catch(IOException e2) {

throw new RuntimeExceptionC'in.closeO исполнен неудачно");

}

}

} ///:-

Конструктор InputFile получает в качестве аргумента строку (String) с име¬нем открываемого файла. Внутри блока try он создает объект FileReader для это¬го файла. Класс FileReader не особенно полезен сам по себе, поэтому мы встраи¬ваем его в созданный BufferedReader, с которым и работаем, — одно из преиму¬ществ InputFile состоит в том, что он объединяет эти два действия.

Если при вызове конструктора FileReader произойдет сбой, возбуждается ис¬ключение FileNotFoundException. В этом случае закрывать файл не нужно, так как он и не открывался. Все остальные блоки catch обязаны закрыть файл, так как он уже был открыт во время входа в них. (Конечно, все было бы сложнее в случае, если бы несколько методов могли возбуждать FileNotFoundException. В таких ситуациях обычно требуется несколько блоков try.) Метод close() тоже может возбудить исключение, которое также проверяется и перехватывается — несмотря на то, что вызов находится в другом блоке catch — с точки зрения компилятора Java это всего лишь еще одна пара фигурных скобок. После вы¬полнения всех необходимых локальных действий исключение возбуждается за¬ново; ведь вызывающий метод не должен считать, что объект был благополучно создан.

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

Метод getLine() возвращает объект String со следующей строкой из файла. Он вызывает метод readLine(), способный возбуждать исключения, но они пере¬хватываются; *гаким образом, сам getLine() исключений не возбуждает. При про¬ектировании обработки исключений вы выбираете между полной обработкой исключения на определенном уровне, его частичной обработкой и передачей да¬лее того же (или другого) исключения и, наконец, простой передачей далее. Там, где это возможно, передача исключения значительно упрощает про¬граммирование. В данной ситуации метод getLine() преобразует исключение в RuntimeException, чтобы указать на ошибку в программе.

Метод dispose() должен вызываться пользователем при завершении работы с объектом InputFile. Он освобождает системные ресурсы (такие, как открытые файлы), закрепленные за объектами BufferedReader и (или) FileReader. Делать это следует только тогда, когда работа с объектом InputFile действительно будет завершена. Казалось бы, подобные действия удобно разместить в методе fina- lize(), но, как упоминалось в главе 5, вызов этого метода не гарантирован (и даже если вы знаете, что он будет вызван, то неизвестно, когда). Это один из недостатков Java: все завершающие действия, кроме освобождения памяти, не производятся автоматически, так что вам придется информировать пользо¬вателя о том, что он ответственен за их выполнение.

Самый безопасный способ использования класса, который способен выдать исключение при конструировании и требует завершающих действий, основан на использовании вложенных блоков try:

//: exceptions/Cleanup.java

// Гарантированное освобождение ресурсов.

public class Cleanup {

public static void main(String[] args) { try {

InputFile in = new InputFileC'Cleanup java"); try {

String s; int i = 1;

whileC(s = in getLineO) != null) ; // Построчная обработка .. } catch(Exception e) {

System.out.println("Перехвачено Exception в main"). e.printStackTrace(System.out); } finally {

in.disposeO;

}

} catch(Exception e) {

System out println("Сбой при конструировании InputFile"):

}

}

} /* Output:

disposeO успешен

*///:-

Присмотритесь к логике происходящего: конструирование объекта InputFile фактически заключено в собственный блок try. Если попытка завершается не¬удачей, мы входим во внешнюю секцию catch и метод dispose() не вызывается. Но, если конструирование прошло успешно, мы хотим обеспечить гарантиро¬ванное завершение, поэтому сразу же после конструирования создается новый блок try. Блок finally, выполняющий завершение, связывается с внутренним блоком try; таким образом, блок finally не выполняется при неудачном конст¬руировании и всегда выполняется, если конструирование прошло удачно.

Эта универсальная идиома применяется и в тех ситуациях, когда конструк¬тор не выдает исключений. Основной принцип: сразу же после создания объекта, требующего завершения, начинается конструкция try-finally:

//: exceptions/Cleanupldiom java

// За каждым освобождаемым объектом следует try-finally

class NeedsCleanup { // Конструирование не может завершиться неудачно private static long counter = 1,

private final long id = counter++, Л

продолжение &

pub.lic void disposeO {

System out printin("NeedsCleanup " + id + " завершен");

class ConstructionException extends Exception {}

class NeedsCleanup2 extends NeedsCleanup { // Возможны сбои при конструировании, public NeedsCleanup2() throws ConstructionException {}

public class Cleanupldiom {

public static void main(String[] args) { // Секция 1-

NeedsCleanup ncl = new NeedsCleanupO; try {

// .. } finally {

ncl.disposeO.

// Секция 2;

// Если сбои при конструировании исключены, // объекты можно группировать. NeedsCleanup nc2 = new NeedsCleanupO; NeedsCleanup псЗ = new NeedsCleanupO; try {

// .. } finally {

nc3 disposeO; // Обратный порядок конструирования nc2.disposeO;

// Секция 3-

// Если при конструировании возможны сбои, каждый объект // защищается отдельно; try {

NeedsCleanup2 nc4 = new NeedsCleanup20; try {

NeedsCleanup2 nc5 = new NeedsCleanup2(); try {

// ...

} finally {

nc5.disposeO;

}

} catch(ConstructionException e) { // Конструктор nc5

System.out.println(e), } finally {

nc4 disposeO;

}

} catch(ConstructionException e) { // Конструктор nc4 System.out.println(e);

}

}

} /* Output; NeedsCleanup 1 завершен NeedsCleanup 3 завершен

Идентификация исключений 343

NeedsCleanup 2 завершен NeedsCleanup 5 завершен NeedsCleanup 4 завершен */// ~

Секция 1 метода main() весьма прямолинейна: за созданием завершаемого объекта следует try-finally. Если конструирование не может завершиться неуда¬чей, наличие catch не требуется. В секции 2 мы видим, что конструкторы, кото¬рые не могут завершиться неудачей, могут группироваться как для конструиро¬вания, так и для завершения.

Секция 3 показывает, как поступать с объектами, при конструировании ко¬торых возможны сбои и которые нуждаются в завершении. Здесь программа усложняется, потому что каждое конструирование должно заключаться в от¬дельную копию try-catch и за ним должна следовать конструкция try-finally, обеспечивающая завершение.

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

Идентификация исключений

Механизм обработки исключений ищет в списке «ближайший» подходящий обработчик в порядке их следования. Когда соответствие обнаруживается, ис¬ключение считается найденным и дальнейшего поиска не происходит.

Идентификация исключений не требует обязательного соответствия между исключением и обработчиком. Объект порожденного класса подойдет и для об¬работчика, изначально написанного для базового класса:

//: exceptions/Human.java // Перехват иерархии исключений.

class Annoyance extends Exception {} class Sneeze extends Annoyance {}

public class Human {

public static void main(String[] args) { // Перехват точного типа try {

throw new SneezeO; } catch(Sneeze s) {

System out println("Перехвачено Sneeze"). } catch(Annoyance a) {

System 0ut.println("nepexBa4eH0 Annoyance"),

}

// Перехват базового типа try {

throw new SneezeO. } catch(Annoyance a) {

System out рпп^пС'Перехвачено Annoyance").

}

}

Перехвачено Sneeze Перехвачено Annoyance *///•-

Исключение Sneeze будет перехвачено в первом блоке catch, который ему со¬ответствует — конечно, это будет первый блок. Но, если удалить первый блок catch, оставив только проверку Annoyance, программа все равно работает, пото¬му что она перехватывает базовый класс Sneeze. Другими словами, блок catch (Annoyance а) поймает Annoyance или любой другой класс, унаследованный от не¬го. Если вы добавите новые производные исключения в свой метод, программа пользователя этого метода не потребует изменений, так как клиент перехваты¬вает исключения базового класса.

Если вы попытаетесь «замаскировать» исключения производного класса, по¬местив сначала блок catch базового класса:

try {

throw new SneezeO;

} catch(Annoyance a) { // ..

} catch(Sneeze s) { II...

}

компилятор выдаст сообщение об ошибке, так как он видит, что блок catch для исключения Sneeze никогда не выполнится.

Альтернативные решения

Система обработки исключений представляет собой «черный ход», позволяю¬щий программе нарушить нормальную последовательность выполнения ко¬манд. «Черный ход» открывается при возникновении «исключительных ситуа¬ций», когда обычная работа далее невозможна или нежелательна. Исключения представляют собой условия, с которыми текущий метод справиться не в со¬стоянии. Причина, по которой возникают системы обработки исключений, кро¬ется в том, что программисты не желали иметь дела с громоздкой проверкой всех возможных условий возникновения ошибок каждой функции. В результа¬те ошибки ими просто игнорировались. Стоит отметить, что вопрос удобства программиста при обработке ошибок стоял на первом месте для разработчиков Java.

Основное правило при использовании исключений гласит: «Не обрабаты¬вайте исключение, если вы не знаете, что с ним делать». По сути, отделение кода, ответственного за обработку ошибок, от места, где ошибка возникает, яв¬ляется одной из главных целей обработки исключений. Это позволяет вам скон¬центрироваться на том, что вы хотите сделать в одном фрагменте кода, и на том, как вы собираетесь поступить с ошибками в совершенно другом месте програм¬мы. В результате основной код не перемежается с логикой обработки ошибок, что упрощает его сопровождение и понимание. Исключения также сокращают объем кода, так как один обработчик может обслуживать несколько потенци¬альных источников ошибок.

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

try {

// ^ делает что-то полезное

} са^И(6бязывающееИсключение е) {} // Проглотили!

Программисты (и я в том числе, в первом издании книги), не долго думая, делали самое бросающееся в глаза и «проглатывали» исключение — зачастую непреднамеренно, но, как только дело было сделано, компилятор был удовле¬творен, поэтому пока вы не вспоминали о необходимости пересмотреть и ис¬править код, не вспоминали и об исключении. Исключение происходит, но безвозвратно теряется. Из-за того что компилятор заставляет вас писать код для обработки исключений прямо на месте, это кажется самым простым реше¬нием, хотя на самом деле ничего хуже и придумать нельзя.

Ужаснувшись тем, что я так поступил, во втором издании книги я «испра¬вил» проблему, распечатыв в обработчике трассировку стека исключения (и сейчас это можно видеть — в подходящих местах — в некоторых примерах данной главы). Хотя это и полезно при отслеживании поведения исключений, трассировка фактически означает, что вы так и не знаете, что же делать с ис¬ключением в данном фрагменте кода. В этом разделе мы рассмотрим некоторые тонкости и осложнения, порождаемые контролируемыми исключениями, и ва¬рианты работы с последними.

Несмотря на кажущуюся простоту, проблема не только очень сложна, но и к тому же неоднозначна. Существуют твердые приверженцы обеих точек зрения, которые считают, что верный ответ (их) очевиден и просто бросается в глаза. Вероятно, одна из точек зрения основана на несомненных преимущест¬вах перехода от слабо типизированного языка (например, С до выхода стандар¬та ANSI) к языку с строгой статической проверкой типов (то есть с проверкой во время компиляции), подобному С++ или Java. Преимущества такого перехо¬да настолько очевидны, что строгая статическая проверка типов кажется пана¬цеей от всех бед. Я надеюсь поставить под вопрос ту небольшую часть моей эво¬люции, отличающуюся абсолютной верой в строгую статическую проверку типов: без сомнения, большую часть времени она приносит пользу, но сущест¬вует неформальная граница, за которой такая проверка становится препятстви¬ем на вашем пути (одна из моих любимых цитат такова: «Все модели неверны, но некоторые полезны»).

Предыстория

Обработка исключений зародилась в таких системах, как PL/1 и Mesa, а затем мигрировала в CLU, Smalltalk, Modula-3, Ada, Eiffel, С++, Python, Java и в поя¬вившиеся после Java языки Ruby и С#. Конструкции Java сходны с конст¬рукциями С++, кроме тех аспектов, в которых решения С++ приводили к проблемам.

Обработка исключений была добавлена в С++ на довольно позднем этапе стандартизации. Модель исключений в С++ в основном была заимствована из CLU. Впрочем, в то время существовали и другие языки с поддержкой обра¬ботки исключений: Ada, Smalltalk (в обоих были исключения, но отсутствовали их спецификации) и Modula-З (в котором существовали и исключения, и их спецификации).

Следуя подходу CLU при разработке исключений С++, Страуструп считал, что основной целью является сокращение объема кода восстановления после ошибки. Вероятно, он видел немало программистов, которые не писали код об¬работки ошибок на С, поскольку объем этого кода был устрашающим, а разме¬щение выглядело нелогично. В результате все происходило в стиле С: ошибки в коде игнорировались, а с проблемами справлялись при помощи отладчиков. Чтобы исключения реально заработали, С-программисты должны были писать «лишний» код, без которого они обычно обходились. Таким образом, объем но¬вого кода не должен быть чрезмерным. Важно помнить об этих целях, говоря об эффективности контролируемых исключений в Java.

С++ добавил к идее CLU дополнительную возможность: спецификации ис¬ключений, то есть включение в сигнатуру метода информации об исключениях, возникающих при вызове. В действительности спецификация исключения не¬сет двойной смысл. Она означает: «Я возбуждаю это исключение в коде, а вы его обрабатываете». Но она также может означать: «Я игнорирую исключение, которое может возникнуть в моем коде; обеспечьте его обработку». При осве¬щении механизмов исключений мы концентрировались на «обеспечении обра¬ботки», но здесь мне хотелось бы поближе рассмотреть тот факт, что зачастую исключения игнорируются, и именно этот факт может быть отражен в специ¬фикации исключения.

В С++ спецификация исключения не входит в информацию о типе функ¬ции. Единственная проверка, осуществляемая во время компиляции, относится к согласованному использованию исключений: к примеру, если функция или метод возбуждает исключения, то перегруженная или переопределенная версия должна возбуждать те же самые исключения. Однако, в отличие от Java, компи¬лятор не проверяет, действительно ли функция или метод возбуждают данное исключение, или полноту спецификации (то есть описывает ли она все исклю¬чения, возможные для этого метода). Если возбуждается исключение, не входя¬щее в спецификацию, программа на С++ вызывает функцию unexpected() из стандартной библиотеки.

Интересно отметить, что из-за использования шаблонов (templates) специ¬фикации исключений отсутствуют в стандартной библиотеке С++. В Java суще¬ствуют ограничения на использование параметризованных типов со специфи¬кациями исключений.

Перспективы

Во-первых, язык Java, по сути, стал первопроходцем в использовании контро¬лируемых исключений (несомненно из-за спецификаций исключений С++ и того факта, что программисты на С++ не уделяли им слишком много внима¬ния). Это был эксперимент, повторить который с тех пор пока не решился еще ни один язык.

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

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

В прошлом я твердо считал, что для разработки надежных программ необхо¬димы и контролируемые исключения, и строгая статическая проверка типов. Однако опыт, полученный лично и со стороны1, с языками, более динамичны¬ми, чем статичными, привел меня к мысли, что на самом деле главные преиму¬щества обусловлены следующими аспектами:

1. Унификация модели сообщения об ошибках посредством исключений (независимо от того, заставляет ли компилятор программиста их обраба¬тывать).

2. Проверка типов, не привязанная к тому, когда она проводится — на ста¬дии компиляции или во время работы программы.

Вдобавок снижение ограничений времени компиляции весьма положитель¬но отражается на продуктивности программиста. С другой стороны, для ком¬пенсации чрезмерной жесткости статической проверки типов необходимы реф¬лексия и параметризация, как вы убедитесь в некоторых примерах книги.

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

«Хороший язык программирования помогает программистам писать хоро¬шие программы. Ни один из языков программирования не может запретить сво¬им пользователям писать плохие программы ».

В любом случае исчезновение когда-либо из Java контролируемых исключе¬ний весьма маловероятно. Это слишком радикальное изменение языка, и защит¬ники их в Sun весьма сильны. История Sun неотделима от политики абсолютной обратной совместимости — фактически любое программное обеспечение Sun ра¬ботает на любом оборудовании Sun, как бы старо оно ни было. Но, если вы чув¬ствуете, что контролируемые исключения становятся для вас препятствием (особенно если вас заставляют обрабатывать исключение, а вы не знаете, как с ним поступить), существует несколько вариантов.

Передача исключений на консоль

В несложных программах, как во многих примерах данной книги, простейшим решением является передача исключения за пределы метода main(), на консоль. К примеру, при открытии файла для чтения (подробности вы вскоре узнаете) необходимо открыть и закрыть поток FilelnputStream, который возбуждает ис¬ключения. В небольшой программе можно поступить следующим образом (по¬добный подход характерен для многих примеров книги):

//• excepti ons/Mai nExcepti on.java

import java io *;

public class MainException {

// Передаем все исключения на консоль, public static void main(String[] args) throws Exception { // Открываем файл: FilelnputStream file =

new FilelnputStreamC'MainException.java");

// Используем файл // Закрываем файл- file.closeO.

}

} ///:-

Заметьте, что main() — такой же метод, как и все прочие; он тоже может иметь спецификацию исключений, и здесь типом исключения является Excep¬tion, базовый класс всех контролируемых исключений. Передавая его на кон¬соль, вы освобождаетесь от необходимости написания предложений try-catch в теле метода main().

Преобразование контролируемых исключений в неконтролируемые

Рассмотренный выше подход хорош при написании метода main(), но в более общих ситуациях не слишком полезен. Подлинная проблема возникает при на¬писании тела самого обычного метода, когда при вызове другого метода вы чет¬ко сознаете: «Понятия не имею, что делать с исключением дальше, но „съедать" мне его не хочется, так же как и печатать банальное сообщение». Проблема ре¬шается при помощи цепочек исключений. Управляемое исключение просто «заворачивается» в класс RuntimeException примерно так:

try {

// .. делаем что-нибудь полезное } са!сИ(НеЗнаюЧтоДелатьСЭтимКонтролируемымИсключением е) { throw new RuntimeException(e);

}

Решение идеально подходит для тех случаев, когда вы хотите «подавить» контролируемое исключение: вы не «съедаете» его, вам не приходится описы¬вать его в своей спецификации исключений, и благодаря цепочке исключений вы не теряете информацию об исходном исключении.

Описанная методика позволяет игнорировать исключение и пустить его «всплывать» вверх по стеку вызова без необходимости писать блоки try-catch и (или) спецификации исключения. Впрочем, при этом вы все равно можете пе¬рехватить и обработать конкретное исключение, используя метод getCause(), как показано ниже:

// exceptions/TurnOffChecking.java // "Подавление" контролируемых исключений, import java io *;

import static net mindview.util.Print.*;

class WrapCheckedException {

void throwRuntimeException(int type) { try {

switch(type) {

case 0: throw new FileNotFoundExceptionO; case 1: throw new IOExceptionO; case 2- throw new RuntimeExceptionCTfle Я?"). default: return;

}

} catch(Exception e) {

// Превращаем в неконтролируемое: throw new RuntimeException(e);

}

}

}

class SomeOtherException extends Exception {}

public class TurnOffChecking {

public static void main(String[] args) {

WrapCheckedException wee = new WrapCheckedExceptionO: // Можно вызвать throwRuntimeExceptionO без блока try, // и позволить исключению RuntimeException покинуть метод- wee. throwRuntimeExceptionO); // Или перехватить исключение: for (int i =0; i <4; i++) try {

if(i < 3)

wee throwRuntimeException(i);

else

throw new SomeOtherExceptionO: } catch(SomeOtherException e) {

print("SomeOtherException. " + e); } catch(RuntimeException re) {

try { продолжение &

throw re.getCauseO, } catch(FileNotFoundException e) {

print("FileNotFoundException. " + e); } catch(IOException e) {

print("IOException- " + e); } catch(Throwable e) {

print("Throwable. " + e);

}

}

}

} /* Output-

Fi1eNotFoundException: java.iо.Fi1eNotFoundException

IOException: java.io.IOException

Throwable: java.lang.RuntimeException. Где Я?

SomeOtherExcepti on: SomeOtherExcepti on

*///:-

Метод WrapCheckedException.throwRuntimeException() содержит код, генери¬рующий различные типы исключений. Они перехватываются и «заворачивают¬ся» в объекты RuntimeException, становясь таким образом «причиной» этих ис¬ключений.

При взгляде на класс TurnOffChecking нетрудно заметить, что вызвать метод throwRuntimeException() можно и без блока try, поскольку он не возбуждает ни¬каких контролируемых исключений. Но когда вы будете готовы перехватить исключение, у вас будет возможность перехватить любое из них — достаточно поместить свой код в блок try. Начинаете вы с перехвата исключений, которые, как вы знаете, могут явно возникнуть в коде блока try, — в нашем случае первым делом перехватывается SomeOtherException. В конце вы перехватываете Runtime- Exception и заново возбуждаете исключение, являющееся его причиной (получая последнее методом getCause(), «завернутое» исключение). Так извлекаются из¬начальные исключения, обрабатываемые в своих предложениях catch.

Методика «заворачивания» управляемых исключений в объекты Runtime- Exception встречается в некоторых примерах книги. Другое возможное реше¬ние — создание собственного класса, производного от RuntimeException. Пере¬хватывать такое исключение не обязательно, но, если вы захотите, такая возможность существует.

Основные правила обработки исключений

Используйте исключения для того, чтобы:

• обработать ошибку на текущем уровне (избегайте перехватывать исклю¬чения, если вы не знаете, как с ними поступить);

• исправить проблему и снова вызвать метод, возбудивший исключение;

• предпринять все необходимые действия и продолжить выполнение без повторного вызова метода;

• попытаться найти альтернативный результат вместо того, который дол¬жен был бы произвести вызванный метод;

• сделать все возможное в текущем контексте и заново возбудить это же исключение, перенаправив его на более высокий уровень;

• сделать все, что можно в текущем контексте, и возбудить новое исключе¬ние, перенаправив его на более высокий уровень;

• завершить работу программы;

• упростить программу (если используемая вами схема обработки исклю¬чений делает все только сложнее, значит, она никуда не годится);

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

Резюме

Исключения являются неотъемлемой частью программирования на Java; суще¬ствует некий барьер, который невозможно преодолеть без умения работать с ними. По этой причине исключения были представлены именно в этой части книги — многими библиотеками (скажем, библиотекой ввода/вывода) просто невозможно нормально пользоваться без обработки исключений.

Одно из преимуществ обработки исключений состоит в том, что она позво¬ляет сосредоточиться на решаемой проблеме, а затем обработать все ошибки в описанном коде в другом месте. Хотя исключения обычно описываются как средство передачи информации и восстановления после ошибок на стадии вы¬полнения, я сильно сомневаюсь, что «восстановление» часто реализуется на практике. По моей оценке, это происходит не более чем в 10% случаев, и даже тогда в основном сводится к раскрутке стека к заведомо стабильному со¬стоянию вместо реального выполнения действий по восстановлению. На мой взгляд, ценность исключений в основном обусловлена именно передачей ин¬формации. Java фактически настаивает, что программа должна сообщать обо всех ошибках в виде исключений, и именно это обстоятельство обеспечивает Java большое преимущество перед языками вроде С++, где программа может сообщать об ошибках разными способами (а то и не сообщать вовсе).

Оглавление

Содержание

Введение в объекты

Все является объектом

Операторы

Управляющие конструкции

Инициализация и завершение

Управление доступом

Повторное использование классов

Полиморфизм

Внутренние классы

Коллекции объектов