Імпорт-вирази

Як буде розглянуто нижче, область видимості оголошення типу - пакет, у якому він розташовується. Це означає, що всередині даного пакету допускається звернення до типу за його простим ім'ям. З усіх інших пакетів необхідно звертатися за складеним іменем, тобто повне ім'я пакету плюс просте ім'я типу, розділені крапкою. Оскільки пакети можуть мати досить довгі імена, а тип може багаторазово використовуватися в модулі компіляції, таке обмеження може призвести до ускладнення вихідного коду й труднощам у розробці.

Для вирішення цієї проблеми вводяться import-вирази, які дозволяють імпортувати типи в модуль компіляції й далі звертатися до них за простими іменами. Існує два види таких виразів:

- імпорт одному типу;

- імпорт пакета.

Важливо підкреслити, що імпорт виразів є, по суті, підказкою для компілятора. Він користується ними, щоб для кожного простого імені типу з іншого пакета отримати його повне ім'я, яке й потрапляє в скомпільований код. Це означає, що таких виразів може бути дуже багато, включаючи й ті, що імпортують невживані пакети й типи, алі це ніяк не відіб'ється ні на розмірі, ні на якості бінарного коду. Також, байдуже, звертатися до типу за його повним ім'ям, або включити його в імпорт-вираз і звертатися по простому імені - результат буде один й той самий.

Вирази імпорту мають ефект тільки всередині модуля компіляції, у якому вони оголошені. Всі оголошення типів вищого рівня, що знаходяться в цьому ж модулі, можуть однаково користуватися імпортованими типами.

Вираз, що імпортує один тип, записується за допомогою ключового слова import і повного імені типу. Наприклад:

import java.net.URL;

Вираз, що імпортує пакет, включає в собі повне ім'я пакету наступним чином:

import java.awt .*;

Цей вираз робить доступними всі типи, що знаходяться в пакеті java.awt, за їх простому імені. Спроба імпортувати пакет, недоступний на момент компіляції, викличе помилку. Оскільки пакет java.lang містить типи, без яких неможливо створити жодну програму, він неявним чином імпортується в кожен модуль компіляції. Таким чином, всі типи з цього пакету доступні за їх простими іменами без будь-яких додаткових зусиль. Спроба імпортувати даний пакет ще раз буде проігнорована.

Допускається одночасно імпортувати пакет і який- небудь тип з нього:

6 Унікальність імен пакетів

Оскільки Java створювалась як мова, призначена для розповсюдження додатків через Internet, а додатки складаються зі структури пакетів, необхідно докласти деяких зусиль, щоб не стався конфлікт імен. Імена двох використовуваних пакетів можуть збігтися після значного часу після їх створення. Виправити такий стан звичайному програмісту буде вкрай важко.

Тому творці Java пропонують наступний спосіб унікального іменування пакетів. Якщо програма створюється розробником, у якого є Internet-сайт, або ж він працює на організацію, у якої є сайт, і доменне ім'я такого сайту, наприклад, company.com, то імена пакетів повинні починатися з цих же слів, виписаних у зворотному порядку : com.company. Подальші вкладені пакети можуть носити назви підрозділів компанії, пакетів, прізвища розробників, імена комп'ютерів і т.д.

Таким чином, пакет верхнього рівня завжди записується ASCII-літерами в нижньому регістрі й може мати одне з наступних імен:

- трьохбуквені com, edu, gov, mil, net, org, int (цей список розширюється);

- дволітерні, що позначають імена країн, такі як ru, su, de, uk та інші.

Якщо ім'я сайту суперечить вимогам до ідентифікаторів Java, то можна зробити наступні кроки:

- якщо в імені стоїть заборонений символ, наприклад, тире, те його можна замінити знаком підкреслення;

- якщо ім'я збігається з зарезервованим словом, можна в кінці додати знак підкреслення;

- якщо ім'я починається з цифри, можна на початку додати знак підкреслення.

Приклади назв пакетів, складених за такими правилами:

Однак, звичайно, ніхто не вимагає, щоб Java-пакети були обов'язково доступні на Internet-сайті, який дав їм ім'я. Швидше була зроблена спроба скористатися існуючою системою імен замість того, щоб створювати нову для іменування бібліотек.

7 Призначення модифікаторів доступу

Дуже часто права доступу розцінюються як якийсь елемент безпеки коду: мовляв, необхідно захищати класи від «неправильного» використання. Наприклад, якщо в класі Human (чоловік) є поле age (вік людини), то який-небудь програміст навмисно або через незнання може присвоїти цьому полю від'ємне значення, після чого об'єкт стані працювати неправильно, можуть з'явитися помилки. Для захисту такого поля age необхідно оголосити його private.

Це досить поширена крапка зору, проте треба визнати, що вона далека від істини. Основним змістом розмежування прав доступу є забезпечення невід'ємної властивості об'єктної моделі - інкапсуляції, тобто приховування реалізації.

Тобто, функціональність класу необхідно розділяти на відкритий інтерфейс, що описує дії, які будуть використовувати зовнішні типи, і на внутрішню реалізацію, яка застосовується тільки всередині самого класу. Зовнішній інтерфейс надалі модифікувати неможливо, або дуже складно, для великих систем, тому його потрібно продумувати особливо ретельно. Деталі внутрішньої реалізації можуть бути змінені на будь-якому етапі, якщо вони не змінюють логіку роботи всього класу. Завдяки такому підходу реалізується одна з базових характеристик об'єктної моделі - інкапсуляція, і забезпечується важлива переваги технології ООП - модульність.

Таким чином, модифікатори доступу вводяться не для захисту типу від зовнішнього користувача, а, навпаки, для захисту, або позбавлення, користувача від зайвих залежностей від деталей внутрішньої реалізації. Що ж стосується неправильного застосування класу, то його творцям потрібно прагнути до того, щоб клас був простий у застосуванні, тоді таких проблем не виникне, адже програміст не стане навмисно писати код, який породжує помилки в його програмі.

Звичайно, таке розбиття на зовнішній інтерфейс і внутрішню реалізацію не завжди очевидний, й, часто умовний. Для полегшення завдання технічних дизайнерів класів в Java уведено не два (public і private), а чотири рівня доступу.

<== попередня сторінка	\|	наступна сторінка ==>
Оголошення пакету	\|	Розмежування доступу в Java

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.021 сек.