// 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. Права доступа к полям и методам класса
Класс
Пакет
Пакет и подклассы
Все классы
private
+
"package"
protected
*
public
Особенность доступа к 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 и список интерфейсов-предков через запятую. Таким образом, интерфейсы могут порождаться от интерфейсов, образуя свою, независимую от классов, иерархию, причем в ней допускается множественное наследование интерфейсов. В этой иерархии нет корня (общего предка).
Страницы: 1, 2, 3, 4