Най-важният фактор в обектно-ориентирана развитие е разделянето на променливите компоненти на константа.
Това е особено важно за библиотеки. потребител

Най-желаната цел може да се постигне определени споразумения: например, библиотека програмист се съгласява да не се отстранят съществуващите методи в класа, защото тя може да наруши структурата на клиента код програмист. В същото време, че обратният проблем е много по-остър. Например, като създател на библиотеката се знае кои от полетата с данни, използвани от клиента програмист? Същото важи и за метода, който е само част от изпълнението на този клас, които не са предназначени за директна употреба като клиент програмист. И ако създателят на библиотеката ще трябва да се премахне старата и да го замени с прилагането на новото? Променете всяко от полетата на класа могат да попречат на клиента код програмист. Оказва се, че създателят на библиотеката "ръце са вързани", а той дори не е имал право промяната.

За решаване на проблемите, идентифицирани в Java спецификатори за достъп (спецификатори за достъп), чрез която създателя на библиотека показва, че на разположение на клиента програмист и кое не е. Нива на достъп (до минимум всички) са дадени от следните ключови думи: обществен, защитени. достъп в рамките на пакета (без ключова дума), така и частни. В предишния параграф, може да създаде впечатление, че основателят на библиотеката е най-добре да се запази всичко възможно "тайна", и отворени само тези методи, които, според вас, трябва да използвате клиент-програмиста. И това е абсолютно вярно, въпреки че изглежда странно за хората, чиито програми на други езици (особено по отношение на C) «свикнали» за липса на ограничения. До края на тази глава, ясно ще видите полезността на механизма за контрол на достъпа в Java.

Въпреки това, концепцията за библиотечни компоненти и контрол върху достъпа до тези компоненти - това не е всичко. Остава да се разбере как компоненти са свързани в едно цяло библиотека. В Java, този проблем е решен по ключова дума пакет (пакет) и спецификатори за достъп зависят от това дали класовете са в една и съща или в различни пакети. Така че, за да започнете, ние погледнете как библиотека компоненти са поставени в опаковките. След това ще бъде в състояние да разбират напълно смисъла на спецификатори за достъп.

Пакет като библиотека модул

Пакетът съдържа група класове, обединени в едно пространство от имена.
Така например, в обхвата на доставката включва Java програма библиотека, опаковани в имена на космически java.util. Един клас java.util нарича ArrayList. За да използвате този клас в програмата, можете да използвате пълното си име java.util.ArrayList. Въпреки това, пълното име е твърде тромава, така че програмата е по-удобно да се използва вноса на ключовите думи. Ако искате да използвате само един клас, можете да го въведете директно в вноса на директива:

Сега към класа ArrayList могат да бъдат достъпни, без да уточнява напълно квалифициран име, но други класове java.util пакет остават недостъпни. За да импортирате всички класове, въведете * вместо името на класа, както се прави в почти всички примери книгата:

механизъм за внос именно пространство дава възможност да се контролира. Имената на клас от членовете са изолирани един от друг. Метод F () на клас А не противоречи F на метод () с същото определение (списък аргумент) клас Б. А какво да кажем имената на класа? Да предположим, че класът на стека е създаден на компютъра, на който някой друг вече е бил определен клас, наречен Stack. Потенциалните конфликти на имена - основната причина, че толкова важно за управление на пространството от имена в Java и възможността за създаване на уникални идентификатори за всички класове.

До този момент повечето от примерите в книгата, записани в отделни файлове и предназначени за местна употреба, така че имената на опаковката могат да бъдат пренебрегнати. (Поставен в "пакета по подразбиране" В този случай, имената на класа.) Разбира се, това също е решение, и този подход ще бъде приложен в книгата, където е възможно. Но, ако се създаде библиотека или програма, която използва други програми на Java на същата машина, трябва да помислите за предотвратяване на името конфликти.

Изходният файл в Java често е наричан компилиран модул. Името на всяка компилация единица трябва да завършва с .java наставката. и в него може да бъде открит (публичен) клас, който има същото име като файла (с главна буква, но без .java разширение). Всеки компилация единица може да съдържа не повече от един отворен клас, в противен случай компилаторът ще докладва за грешка. Останалата част от класовете на дялове, ако те са там, скрит от външния свят - те не са отворени (обществени) и се считат за "спомагателни" по отношение на главницата отворен клас.

В резултат на това съставянето за всеки клас са дефинирани във файла .java. Той създава клас със същото име, но с .class разширението. По този начин, когато се съберат няколко .java файлове, може да получи брой файлове от .class на Ras-разширение. Ако сте програмирани в компилиран език, то вероятно е свикнал с факта, че компилаторът генерира изходни файлове (обикновено с разширение OBJ), които след това се комбинират със свръзката за производство на изпълним файл или библиотека. Java не работи. Работната програма е съвкупност от хомогенни .class файлове. които са обединени в пакет и се пресова в буркан файл (Javajar полезност). В Java интерпретатора е отговорен за намирането, зареждане и тълкуване на тези файлове.

Библиотеката е и набор от файлове с класове. Всеки файл има един клас rublіs с произволен брой класове, които не разполагат с квалификант обществеността. Ако искате да се декларира, че всички тези компоненти (съхраняват в отделни файлове .java и .class) са свързани помежду си, да се използва пакета за ключова дума.

Това означава, че тази компилация единица е част от достъп библиотека име. С други думи, вие показвате, че отворения клас в единицата компилация принадлежи mypackage и ако някой иска да го използва, той ще трябва да напълно да изгори или името на класа, или директива внос с достъп (дизайн, посочена по-горе). Имайте предвид, че правилата на имена Java пакети са написани само с малки букви.

Да предположим, че даден файл, наречен MyClass.java. Тя може да съдържа един и само един отворен клас (обществени), последният трябва да се нарича MyClass (главни и малки букви):

Сега, ако някой иска да използва MyClass или някакви други класове за свободен достъп от опаковката. той ще трябва да се използва вноса на ключовите думи. че имената на достъпа станаха достъпни. Има и друг вариант - да напиша пълното име на класа: