Cel mai important factor al dezvoltării orientate pe obiecte este separarea componentelor variabile de constante.
Acest lucru este deosebit de important pentru biblioteci. utilizator
Scopul dorit poate fi atins prin anumite înțelegeri: De exemplu, programatorul bibliotecii este de acord să nu șterge metodele existente ale clasei, deoarece aceasta poate perturba structura codului clientului. În același timp, problema inversă este mult mai acută. De exemplu, cum știe creatorul bibliotecii ce câmpuri de date sunt utilizate de programatorul client? Același lucru se aplică metodelor care fac parte numai din implementarea clasei, adică nu sunt destinate utilizării directe de către programatorul client. Și dacă creatorul bibliotecii va trebui să șterge vechea implementare și să o înlocuiască cu una nouă? Modificarea oricărui câmp de clasă poate perturba codul programatorului client. Se pare că creatorul bibliotecii "leagă mâinile" și nu are nimic de schimbat.
Pentru a rezolva problemele identificate în Java specificatori de acces (specificatorii de acces), prin care creatorul de bibliotecă indică faptul că programator client disponibil și ceea ce nu este. Nivelurile de acces (de la plin la minim) sunt stabilite de următoarele cuvinte cheie: publice, protejate. Accesați în pachet (nu are un cuvânt cheie) și privat. În paragraful anterior poate da impresia că fondatorul bibliotecii este cel mai bine să păstreze toate posibile „secrete“, și deschis doar acele metode, care, în opinia dumneavoastră, ar trebui să utilizeze programator de client. Și este absolut adevărat, deși se pare ciudat pentru persoanele ale căror programe în alte limbi (în special în ceea ce privește C) «obișnuit» la lipsa unor restricții. Până la sfârșitul acestui capitol, veți vedea clar utilitatea mecanismului de control al accesului în Java.
Cu toate acestea, conceptul de bibliotecă de componente și controlul accesului la aceste componente nu sunt toate. Rămâne de înțeles modul în care componentele sunt legate într-o bibliotecă unificată. În Java, această problemă este rezolvată de pachetul de cuvinte cheie (pachet), iar specificatorii de acces depind de faptul dacă clasele sunt în același pachet sau în pachete diferite. Deci, mai întâi vom afla cum sunt plasate componentele bibliotecilor în pachete. După aceasta, veți putea înțelege pe deplin semnificația specificatorilor de acces.
Pachetul ca modul de bibliotecă
Pachetul conține un grup de clase care sunt unite în același spațiu de nume.
De exemplu, pachetul standard Java include o bibliotecă de servicii, concepută ca un spațiu de nume java.util. Una dintre clasele java.util este numită ArrayList. Pentru a folosi o clasă într-un program, puteți folosi numele său complet java.util.ArrayList. Cu toate acestea, numele complete sunt prea greoaie, deci este mai convenabil să utilizați importul de cuvinte cheie în program. Dacă intenționați să utilizați o singură clasă, o puteți specifica direct în directiva de import:
Acum puteți accesa clasa ArrayList fără a specifica un nume complet, dar alte clase din pachetul java.util vor rămâne inaccesibile. Pentru a importa toate clasele, specificați * în loc de numele clasei, așa cum se face în aproape toate exemplele cărții:
Mecanismul de import oferă posibilitatea de a gestiona spațiile de nume. Numele membrilor clasei sunt izolate unele de altele. Metoda f () a clasei A nu intră în conflict cu metoda f () cu aceeași definiție (lista de argumente) a clasei B. Cum rămâne cu numele claselor? Să presupunem că clasa Stack este creată pe un computer unde altcineva a definit deja o clasă numită Stack. Conflictele de nume potențiale sunt principalul motiv pentru care gestionarea spațiilor de nume din Java este atât de importantă, cât și capacitatea de a crea identificatori unici pentru toate clasele.
Până atunci, cele mai multe dintre exemplele cărții au fost scrise în fișiere separate și au fost destinate utilizării locale, astfel încât numele pachetelor ar putea fi ignorate. (În acest caz, numele claselor sunt plasate în "pachetul implicit".) Desigur, aceasta este de asemenea o soluție, iar această abordare va fi aplicată în carte dacă este posibil. Dar, dacă creați o bibliotecă sau un program care utilizează alte programe Java pe aceeași mașină, trebuie să luați în considerare prevenirea conflictelor de nume.
Un fișier cu cod sursă în Java este numit adesea un modul compilat. Numele fiecărui modul compilat trebuie să se încheie cu un sufix .java. iar înăuntru poate fi o clasă deschisă (publică) care are același nume ca fișierul (cu o literă mare, dar fără extensia .java). Orice modul compilat nu poate conține mai mult de o clasă deschisă, altfel compilatorul va raporta o eroare. Restul clasei de module, dacă sunt acolo, sunt ascunse de lumea exterioară - ele nu sunt publice (publice) și sunt considerate "auxiliare" clasei principale deschise.
Ca rezultat al compilației pentru fiecare clasă definită în fișierul .java. Se creează o clasă cu același nume, dar cu o extensie .class. Astfel, atunci când sunt compilate mai multe fișiere .java, poate apărea o serie întreagă de fișiere cu extensia .class. Dacă v-ați programat într-un limbaj compilat, acesta este, probabil, obișnuit cu faptul că compilatorul generează fișiere de ieșire (de obicei cu extensia OBJ), care sunt apoi combinate de linker-ul pentru a produce un fișier executabil sau o bibliotecă. Java nu funcționează în acest fel. Un program de lucru este un set de fișiere .class omogene. care sunt combinate într-un pachet și comprimate într-un fișier JAR (utilitar Javajar). Interpretul Java este responsabil pentru găsirea, încărcarea și interpretarea acestor fișiere.
Biblioteca este, de asemenea, o colecție de fișiere cu clase. În fiecare fișier există o clasă publis cu orice număr de clase care nu au specificatorul public. Dacă doriți să declarați că toate aceste componente (stocate în fișiere separate Java și .class) sunt legate între ele, utilizați pachetul de cuvinte cheie.
înseamnă că acest modul compilat este inclus în bibliotecă cu accesul la nume. Cu alte cuvinte, indică faptul că clasa deschisă în unitatea de compilare aparține mypackage și dacă cineva vrea să-l folosească, el ar trebui să ardă complet sau nume de clasă, sau directiva de import, cu acces (proiectare, menționate anterior). Rețineți că, conform regulilor Java, numele pachetelor sunt scrise numai cu litere mici.
Să presupunem că fișierul este numit MyClass.java. Poate conține o singură clasă publică, cea din urmă fiind numită MyClass (cu majuscule):
Dacă acum cineva vrea să folosească MyClass sau orice alte clase publice din pachetul de acces. el va trebui să utilizeze importul cuvântului cheie. astfel încât numele din acces să devină disponibile. Este, de asemenea, posibil să scrieți numele complet al clasei:
Trimiteți-le prietenilor: