Выбрать главу

// для получения переменного списка параметров.

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 останутся недоступными. Чтобы импортировать все классы, укажите * вместо имени класса, как это делается почти во всех при­мерах книги: