Интерфейсы, обратные вызовы, внутренние классы

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Интерфейсы, обратные вызовы, внутренние классы

Интерфейсы, обратные вызовы, внутренние классы

9

Факультет "Информатика и системы управления"

Методические указания к лабораторной работе

по курсу "Распределенные системы обработки информации"

Интерфейсы, обратные вызовы, внутренние классы

Москва 2004 г.

Оглавление

• Цель работы 3
• Задание для домашней подготовки 3
• Задание к лабораторной работе 3
• Содержание отчета 3
• Контрольные вопросы. 4
• Литература. 5
• Приложение 1. Пакеты и интерфейсы 6
• Приложение 2. Вложенные классы 22
• Приложение 3. Интерфейсы и обратные вызовы 28
• Цель работы
• Получить первичные знания об интерфейсах, обратных вызовах и внутренних классах языка Java. Научиться писать программы, использующие интерфейсы, обратные вызовы и внутренние классы.

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

В стандартную библиотеку Java API входят сотни классов. Каждый программист в ходе работы добавляет к ним десятки своих. Классов. Множество классов становится необозримым. Уже давно принять классы объединять в библиотеки. Но библиотеки классов, кроме стандартной, не являются частью языка.

Разработчики Java включили в язык дополнительную конструкцию -- пакеты (packages). Все классы Java распределяются по пакетам. Кроме классов пакеты могут включать в себя интерфейсы и вложенные подпакеты (subpackages). Образуется древовидная структура пакетов и подпакетов.

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

Каждый пакет образует одно пространство имен (namespace). Это означает, что все имена классов, интерфейсов и подпакетов в пакете должны быть уникальны. Имена в разных пакетах могут совпадать, но это будут разные программные единицы. Таким образом, ни один класс, интерфейс или подпакет не может оказаться сразу в двух пакетах. Если надо использовать два класса с одинаковыми именами из разных пакетов, то имя класса уточняется именем пакета: пакет.класс. Такое уточненное имя называется полным именем класса.

Пакетами пользуются еще и для того, чтобы добавить к уже имеющимся правам доступа к членам класса private, protected и public еще один, "пакетный" уровень доступа.

Если член класса не отмечен ни одним из модификаторов private, protected, public, то, по умолчанию, к нему осуществляется пакетный доступ, а именно, к такому члену может обратиться любой метод любого класса из того же пакета. Пакеты ограничивают и доступ к классу целиком -- если класс не помечен модификатором public, то все его члены, даже открытые, public, не будут видны из других пакетов.

Пакет и подпакет

Чтобы создать пакет надо просто в первой строке Java-файла с исходным кодом записать строку package имя;, например:

package mypack;

Тем самым создается пакет с указанным именем mypack и все классы, записанные в этом файле, попадут в пакет mypack. Повторяя эту строку в начале каждого исходного файла, включаем в пакет новые классы.

Имя подпакета уточняется именем пакета. Чтобы создать подпакет с именем, например, subpack, следует в первой строке исходного файла написать;

package mypack.subpack;

и все классы этого файла и всех файлов с такой же первой строкой попадут в подпакет subpack пакета mypack.

Можно создать и подпакет подпакета, написав что-нибудь вроде

package mypack.subpack.sub;

и т. д. сколько угодно раз.

Поскольку строка package имя; только одна и это обязательно первая строка файла, каждый класс попадает только в один пакет или подпакет.

Компилятор Java может сам создать каталог с тем же именем mypack, a в нем подкаталог subpack, и разместить в них class-файлы с байт-кодами.

Полные имена классов А и В будут выглядеть так: mypack.A, mypack.subpack.В.

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

com.sun.developer

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

Безымянный пакет служит обычно хранилищем небольших пробных или промежуточных классов. Большие проекты лучше хранить в пакетах. Например, библиотека классов Java 2 API хранится в пакетах java, javax, org.omg. Пакет Java содержит только подпакеты applet, awt, beans, io, lang, math, net, rmi, security, sql, text, util и ни одного класса. Эти пакеты имеют свои подпакеты, например, пакет создания графического интерфейса пользователя (ГИП) и графики java.awt содержит подпакеты color, datatransfer, dnd, event, font, geometry, image, print.

Конечно, состав пакетов меняется от версии к версии.

Права доступа к членам класса

Рассмотрим большой пример. Пусть имеется пять классов, размещенных в двух пакетах, как показано на рис. П.1.

Рис. П.1. Размещение наших классов по пакетам

В файле Base.java описаны три класса: inpi, Base и класс Derivedpi, расширяющий класс Base. Эти классы размещены в пакете pi. В классе Base определены переменные всех четырех типов доступа, а в методах f() классов inp1 и Derivedp1 сделана попытка доступа ко всем полям класса вазе. Неудачные попытки отмечены комментариями. В комментариях помещены сообщения компилятора. Листинг 3.1 показывает содержимое этого файла.

Листинг П.1. Файл Base.java с описанием пакета p1

package p1;

class Inp1{

public void f () {

Base b = new Base();

// b.priv = 1; // "priv has private access in p1.Base"

b.pack = 1;

b.prot = 1;

b.publ = 1;

}

}

public class Base{

private int priv = 0;

int pack = 0;

protected int prot = 0;

public int publ = 0;

}

class Derivedpi extends Base{

public void f(Base a) {

// a.priv = 1; // "priv hаs private access in pi.Base"

a.pack = 1;

a.prot = 1;

a.publ = 1;

// priv = 1; // "priv has private access in pi.Base"

pack = 1;

prot = 1;

publ = 1;

}

}

Как видно из листинга П.1, в пакете недоступны только закрытые, private, поля другого класса.

В файле Inp2.java описаны два класса: Inp2 и класс Derivedp2, расширяющий класс Base. Эти классы находятся в другом пакете р2. В этих классах тоже сделана попытка обращения к полям класса Base. Неудачные попытки прокомментированы сообщениями компилятора. Листинг П.2 показывает содержимое этого файла.

Напомним, что класс Base должен быть помечен при своем описании в пакете p1 модификатором public, иначе из пакета р2 не будет видно ни одного его члена.

Листинг П.2. Файл Inp2.java с описанием пакета р2

package p2;

import pl.Base;

class Inp2{

public static void main(String[] args){

Base b = new Base();

// b.priv = 1; // "priv has private access in pl.Base"

// b.pack = 1; // "pack is not public in pl.Base;

// cannot be accessed from outside package"

// b.prot = 1; //„"prot has protected access in pi.Base"

b.publ = 1;

}

}

class Derivedp2 extends Base{

public void, f (Base a){

// a.priv = 1; // "priv has private access in. p1.Base"

// a.pack = 1; // "pack, is not public in pi.Base; cannot

//be accessed from outside package"

// a.prot = 1; // "prot has protected access in p1.Base"

a.publ = 1;

// priv = 1; // "priv has private access in pi.Base"

// pack = 1; // "pack is not public in pi.Base; cannot

// be accessed from outside package"

prot = 1;

publ = 1;

super.prot = 1;

}

}

Здесь, в другом пакете, доступ ограничен в большей степени.

Из независимого класса можно обратиться только к открытым, public, полям класса другого пакета. Из подкласса можно обратиться еще и к защищенным, protected, полям, но только унаследованным непосредственно, а не через экземпляр суперкласса.

Все указанное относится не только к полям, но и к методам. Подытожим все сказанное в табл. П.1.

Таблица П.1. Права доступа к полям и методам класса

Особенность доступа к protected-полям и методам из чужого пакета отмечена звездочкой.

Размещение пакетов по файлам

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

Обратимся к тому же примеру. Пусть в каталоге D:\jdkl.3\MyProgs\ch3 есть пустой подкаталог classes и два файла -- Base.java и Inp2.java, -- содержимое которых показано в листингах П.1 и П.2. Рис. П.2 демонстрирует структуру каталогов уже после компиляции.

Мы можем проделать всю работу вручную.

1. В каталоге classes создаем подкаталоги р1 и р2.

2. Переносим файл Base.java в каталог р1 и делаем р1 текущим каталогом.

3. Компилируем Base.java, получая в каталоге р1 три файла: Base.class, Inpl.class, Derivedpl.class.

4. Переносим файл Inp2java в каталог р2.

5. Снова делаем текущим каталог classes.

6. Компилируем второй файл, указывая путь p2\Inp2.java.

7. Запускаем программу java p2.inp2.

Вместо шагов 2 и 3 можно просто создать три class-файла в любом месте, а потом перенести их в каталог pi. В class-файлах не хранится никакая информация о путях к файлам.

Смысл действий 5 и 6 в том, что при компиляции файла Inp2.java компилятор уже должен знать класс p1.Base, а отыскивает он файл с этим классом по пути p1.Base.class, начиная от текущего каталога.

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

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

1. Вызываем компилятор с ключом -d путь, указывая параметром путь начальный каталог для пакета:

javac -d classes Base.java

Компилятор создаст в каталоге classes подкаталог р1 и поместит туда три class-файла.

2. Вызываем компилятор с еще одним ключом -classpath путь, указывая параметром путь каталог classes, в котором находится подкаталог с уже откомпилированным пакетом pi:

javac -classpath classes -d classes Inp2.java

Компилятор, руководствуясь ключом -d, создаст в каталоге classes подкаталог р2 и поместит туда два class-файла, при создании которых он "заглядывал" в каталог pi, руководствуясь ключом -classpath.

3. Делаем текущим каталог classes.

4. Запускаем профамму java p2.inp2.

Рис. П.2. Структура каталогов

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

На рис. П.2 отображена структура каталогов после компиляции.

Импорт классов и пакетов

Во второй строке листинга П.2 новый оператор import. Для чего он нужен?

Дело в том, что компилятор будет искать классы только в одном пакете, именно, в том, что указан в первой строке файла. Для классов из другого пакета надо указывать полные имена. В нашем примере они короткие, и мы могли бы писать в листинге П.2 вместо Base полное имя p1.Base.

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

Правила использования оператора import очень просты: пишется слово import и, через пробел, полное имя класса, завершенное точкой с запятой. Сколько классов надо указать, столько операторов import и пишется.

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

import p1.*;

Напомним, что импортировать можно только открытые классы, помеченные модификатором public. Пакет java.lang (стандартная библиотека классов) просматривается всегда, его необязательно импортировать. Остальные пакеты стандартной библиотеки надо указывать в операторах import либо записывать полные имена классов.

Подчеркнем, что оператор import вводится только для удобства программистов и слово "импортировать" не означает никаких перемещений классов.

Замечание

Оператор import не эквивалентен директиве препроцессора include в С/С++. Он не подключает никакие файлы.

Java-файлы

Теперь можно описать структуру исходного файла с текстом программы на языке Java.

· В первой строке файла может быть необязательный оператор package.

· В следующих строках могут быть необязательные операторы import.

· Далее идут описания классов и интерфейсов.

Еще два правила.

· Среди классов файла может быть только один открытый public-класс.

· Имя файла должно совпадать с именем открытого класса, если последний существует.

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

Соглашение. Рекомендует открытый класс,, если он имеется в файле, описывать первым.

Интерфейсы

В Java получить расширение можно только от одного класса, каждый класс В или С происходит из неполной семьи, как показано на рис. П.4, а. Все классы происходят только от "Адама", от класса Оbject. Но часто возникает необходимость породить класс D от двух классов В и С, как показано на рис. П.4, б. Это называется множественным наследованием (multiple inheritance). В множественном наследовании нет ничего плохого. Трудности возникают, если классы В и С сами порождены от одного класса А, как показано на рис. П.4 в. Это так называемое "ромбовидное" наследование.

Рис. П.4. Разные варианты наследования

Пусть в классе А определен метод f (), к которому мы обращаемся из некоего метода класса D. Можем ли мы быть уверены, что метод f () выполняет то, что написано в классе А, т. е. это метод A.f ()? Может, он переопределен в классах В и С? Если так, то каким вариантом мы пользуемся: B.f() или С.f()? Конечно, можно определить экземпляры классов и обращаться к методам этих экземпляров, но это совсем другой разговор.

В разных языках программирования этот вопрос решается по-разному, главным образом, уточнением имени метода f().

Создатели языка Java запретили множественное наследование вообще. При расширении класса после слова extends можно написать только одно имя суперкласса. С помощью уточнения super можно обратиться только к членам непосредственного суперкласса.

Но что делать, если все-таки при порождении надо использовать несколько предков? Например, у нас есть общий класс автомобилей Automobile, от которого можно породить класс грузовиков Truck и класс легковых автомобилей Саг. Но вот надо описать пикап Pickup. Этот класс должен наследовать свойства и грузовых, и легковых автомобилей.

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

Интерфейс (interface), в отличие от класса, содержит только константы и заголовки методов без их реализации.

Интерфейсы размещаются в тех же пакетах и подпакетах, что и классы, и компилируются тоже в class-файлы.

Описание интерфейса начинается со слова interface, перед которым может стоять модификатор public, означающий, как и для класса, что интерфейс доступен всюду. Если же модификатора public нет, интерфейс будет виден только в своем пакете.

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

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

Все константы и методы в интерфейсах всегда открыты, не надо даже указывать модификатор public.

Вот какую схему можно предложить для иерархии автомобилей:

interface Automobile{ . . . }

interface Car extends Automobile{ . . . }

interface Truck extends Automobile{ . . . }

interface Pickup extends Car, Truck{ . . . }

Таким образом, интерфейс -- это только набросок, эскиз. В нем указано, что делать, но не указано, как это делать.

Как же использовать интерфейс, если он полностью абстрактен, в нем нет ни одного полного метода?

Использовать нужно не интерфейс, а его реализацию (implementation). Реализация интерфейса -- это класс, в котором расписываются методы одного или нескольких интерфейсов. В заголовке класса после его имени или после имени его суперкласса, если он есть, записывается слово implements и, через запятую, перечисляются имена интерфейсов.

Вот как можно реализовать иерархию автомобилей:

interface Automobile{ . . . }

interface Car extends Automobile! . . . }

class Truck implements Automobile! . . . }

class Pickup extends Truck implements Car{ . . . }

или так:

interface Automobile{ . . . }

interface Car extends Automobile{ . . . }

interface Truck extends Automobile{ . . . }

class Pickup implements Car, Truck{ . . . }

Реализация интерфейса может быть неполной, некоторые методы интерфейса расписаны, а другие -- нет. Такая реализация -- абстрактный класс, его обязательно надо пометить модификатором abstract.

Как реализовать в классе Рickup метод f(), описанный и в интерфейсе саг, и в интерфейсе Truck с одинаковой сигнатурой? Ответ простой -- никак. Такую ситуацию нельзя реализовать в классе Pickup. Программу надо спроектировать по-другому.

Итак, интерфейсы позволяют реализовать средствами Java чистое объектно-ориентированное проектирование, не отвлекаясь на вопросы реализации проекта.

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

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

Листинг П.3 показывает, как можно собрать с помощью интерфейса «хор» домашних животных.

Листинг П.3. Использование интерфейса для организации полиморфизма

interface Voice{

void voice();

}

class Dog implements Voice{

public void voice (){

System.out.println("Gav-gav!");

}

}

class Cat implements Voice{

public void voice (){

System.out.println("Miaou!");

}

}

class Cow implements Voice{

public void voice(){

System.out.println("Mu-u-u!");

}

}

public class Chorus{

public static void main(String[] args){

Voiced singer = new Voice[3];

singer[0] = new Dog();

singer[1] = new Cat();

singer[2] = new Cow();

for(int i = 0; i < singer.length; i++)

singer[i].voice();

}

}

Здесь используется интерфейс voice .

Что же лучше использовать: абстрактный класс или интерфейс? На этот вопрос нет однозначного ответа.

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

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

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

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

Наконец, можно использовать интерфейсы просто для определения констант, как показано в листинге П.4.

Листинг П.4. Система управления светофором

interface Lights{

int RED = 0;

int YELLOW = 1;

int GREEN = 2;

int ERROR = -1;

}

class Timer implements Lights{

private int delay;

private static int light = RED;

Timer(int sec)(delay = 1000 * sec;}

public int shift(){

int count = (light++) % 3;

try{

switch(count){

case RED: Thread.sleep(delay); break;

case YELLOW: Thread.sleep(delay/3); break;

case GREEN: Thread.sleep(delay/2); break;

}

}catch(Exception e){return ERROR;}

return count;

}

}

class TrafficRegulator{

private static Timer t = new Timer(1);

public static void main(String[] args){

for (int k = 0; k < 10; k++)

switch(t.shift()){

case Lights.RED: System.out.println("Stop!"); break;

case Lights.YELLOW: System.out.println("Wait!"); break;

case Lights.GREEN: System.out.println("Go!"); break;

case Lights.ERROR: System.err.println("Time Error"); break;

default: System.err.println("Unknown light."); return;

}

}

}

Здесь, в интерфейсе Lights, определены константы, общие для всего проекта.

Класс Timer реализует этот интерфейс и использует константы напрямую как свои собственные. Метод shift () этого класса подает сигналы переключения светофору с разной задержкой в зависимости от цвета. Задержку осуществляет метод sleep() класса Thread из стандартной библиотеки, которому передается время задержки в миллисекундах. Этот метод нуждается в обработке исключений try{} catch() {}.

Класс TrafficReguiator не реализует интерфейс Lights и пользуется полными именами Lights.RED и т.д. Это возможно потому, что константы RED, YELLOW и GREEN по умолчанию являются статическими.

Приложение 2. Вложенные классы

В теле класса можно сделать описание другого, вложенного (nested) класса. А во вложенном классе можно снова описать вложенный, внутренний (inner) класс и т. д. Можно ли из вложенного класса обратиться к членам внешнего класса? Можно, для того это все и задумывалось.

· А можно ли в таком случае определить экземпляр вложенного класса, не определяя экземпляры внешнего класса? Нет, нельзя, сначала надо определить хоть один экземпляр внешнего класса, матрешка ведь!

· А если экземпляров внешнего класса несколько, как узнать, с каким экземпляром внешнего класса работает данный экземпляр вложенного класса? Имя экземпляра вложенного класса уточняется именем связанного с ним экземпляра внешнего класса. Более того, при создании вложенного экземпляра операция new тоже уточняется именем внешнего экземпляра.

Все вложенные классы можно разделить на вложенные классы-члены класса (member classes), описанные вне методов, и вложенные локальные классы (local classes), описанные внутри методов и/или блоков. Локальные классы, как и все локальные переменные, не являются членами класса.

Классы-члены могут быть объявлены статическим модификатором static. Поведение статических классов-членов ничем не отличается от поведения обычных классов, отличается только обращение к таким классам. Поэтому они называются вложенными классами верхнего уровня (nestee tep-level classes), хотя статические классы-члены можно вкладывать друг в друга. В них можно объявлять статические члены. Используются они обычно для того, чтобы сгруппировать вспомогательные классы вместе с основным классом.

Все нестатические вложенные классы называются внутренними (inner). В них нельзя объявлять статические члены.

Локальные классы, как и все локальные переменные, известны только в блоке, в котором они определены. Они могут быть безымянными (anonymous classes).

Пример.

Листинг Вложенные классы

class Nested{

static private int pr; // Переменная pr объявленa статической

// чтобы к ней был доступ из статических классов А и АВ

String s = "Member of Nested";

// Вкладываем статический класс.

static class .А{ // Полное имя этого класса -- Nested.A

private int a=pr;

String s = "Member of A";

// Во вложенньм класс А вкладываем еще один статический класс

static class AB{ // Полное имя класса -- Nested.А.АВ

private int ab=pr;

String s = "Member of AB";

}

}

//В класс Nested вкладываем нестатический класс

class В{ // Полное имя этого класса -- Nested.В

private int b=pr;

String s = "Member of B";

// В класс В вкладываем еще один класс

class ВС{ // Полное имя класса -- Nested.В.ВС

private int bc=pr;

String s = "Member of ВС";

}

void f(final int i){ // Без слова final переменные i и j

final int j = 99; // нельзя использовать в локальном классе D

class D{ // Локальный класс D известен только внутри f()

private int d=pr;

String s = "Member of D";

void pr(){

// Обратите внимание на то, как различаются

// переменные с одним и тем же именем "s"

System.out.println(s + (i+j)); // "s" эквивалентно "this.s"

System.out.println(B.this.s);

System.out.println(Nested.this.s);

// System.out.println(AB.this.s); // Нет доступа

// System.out.println(A.this.s); // Нет доступа

}

}

D d = new D(); // Объект определяется тут же, в методе f()

d.pr(); // Объект известен только в методе f()

}

}

void m(){

new Object(){ // Создается объект безымянного класса,

// указывается конструктор его суперкласса

private int e = pr;

void g(){

System.out.println("From g()) ;

}

}.g(); // Тут же выполняется метод только что созданного объекта

}

}

public class NestedClasses{

public static void main(String[] args){

Nested nest = new Nested(); // Последовательно раскрываются

// три матрешки

Nested.A theA = nest.new A(); // Полное имя класса и уточненная

// операция new. Но конструктор только вложенного класса

Nested.A.AB theAB = theA.new AB(); // Те же правила. Операция

// new уточняется только одним именем

Nested.В theB = nest.new B(); // Еще одна матрешка

Nested.В.ВС theBC = theB.new BC();

theB.f(999); // Методы вызываются обычным образом

nest.m();

}

}

Дадим пояснения.

· Как видите, доступ к полям внешнего класса Nested возможен отовсюду, даже к закрытому полю pr. Именно для этого в Java и введены вложенные классы. Остальные конструкции введены вынужденно, для того чтобы увязать концы с концами.

· Язык Java позволяет использовать одни и те же имена в разных областях видимости -- пришлось уточнять константу this именем класса: Nested.this, В.this.

· В безымянном классе не может быть конструктора, ведь имя конструктора должно совпадать с именем класса, -- пришлось использовать имя суперкласса, в примере это класс object. Вместо конструктора в безымянном классе используется блок инициализации экземпляра.

· Нельзя создать экземпляр вложенного класса, не создав предварительно экземпляр внешнего класса, -- пришлось подстраховать это правило уточнением операции new именем экземпляра внешнего класса-- nest.new, theA.new, theB.new.

· При определении экземпляра указывается полное имя вложенного класса, но в операции new записывается просто конструктор класса.

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

Можно ли наследовать вложенные классы? Можно.

· Как из подкласса обратиться к методу суперкласса? Константа super уточняется именем соответствующего суперкласса, подобно константе this.

· А могут ли вложенные классы быть расширениями других классов? Могут.

Механизм вложенных классов станет понятнее, если посмотреть, какие файлы с байт-кодами создал компилятор:

· Nested$l$D.class -- локальный класс о, вложенный в класс Nested;

· NestedSl.class -- безымянный класс;

· Nested$A$AB.class -- класс Nested.A.AB;

· Nested$A.class -- класс Nested.А;

· Nested$B$BC.class -- класс Nested.B.BC;

· NestedSB.class -- класс Nested.B;

· Nested.class -- внешний класс Nested;

· NestedClasses.class - класс с методом main ().

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

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

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

В каких же случаях создавать вложенные классы? В теории ООП вопрос о создании вложенных классов решается при рассмотрении отношений "быть частью" и "являться".

Отношения "быть частью" и "являться"

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

Определив, какие классы будут написаны в вашей программе, и сколько их будет, подумайте, как спроектировать взаимодействие классов? Вырастить пышное генеалогическое дерево классов-наследников или расписать матрешку вложенных классов?

Теория ООП советует прежде всего выяснить, в каком отношении находятся ваши классы P и Q -- в отношении "класс Q является экземпляром класса P" ("a class Q is a class р") или в отношении "класс Q -- часть класса P" ("a class Q has a class P").

Например: "Собака является животным" или "Собака -- часть животного"? Ясно, что верно первое отношение "is-a", поэтому мы и определили класс Dog как расширение класса Pet.

Отношение "is-a" -- это отношение "обобщение-детализация", отношение большей или меньшей абстракции, и ему соответствует наследование классов.

Отношение "has-a" -- это отношение "целое-часть", ему соответствует вложение.