User Tools
Problem constructing authldap
laboratoare:organizare-acces
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
laboratoare:organizare-acces [2013/08/06 20:59] Mihnea Muraru creat |
laboratoare:organizare-acces [2019/09/04 18:41] (current) Adriana Draghici [Exerciţii] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| = Organizarea surselor și controlul accesului = | = Organizarea surselor și controlul accesului = | ||
| + | |||
| + | Chiar şi în cadrul proiectelor de dimensiune medie, numărul claselor definite poate creşte considerabil. Astfel, devine aparentă necesitatea unei organizări a fişierelor sursă, pe baza funcţiei îndeplinite şi relaţiilor dintre acestea. În plus, această organizare permite şi utilizarea unor mecanisme de control al accesului. | ||
| + | |||
| + | Spre exemplu, în cadrul unei aplicaţii de transfer de fişiere, se pot distinge mai multe module, precum cel de interfaţă cu utilizatorul, cel de reţea, cel de configurare etc. În acest caz, este utilă gruparea claselor aferente fiecărui modul în propriul **pachet**. | ||
| + | |||
| + | Astfel, definiţia clasei //MainClass// din pachetul principal //myapp// ar începe prin cuvântul cheie ''package'': | ||
| + | |||
| + | <code java> | ||
| + | package myapp; | ||
| + | |||
| + | import java.util.*; | ||
| + | |||
| + | public class MainClass { | ||
| + | ... | ||
| + | } | ||
| + | </code> | ||
| + | |||
| + | Organizarea în **pachete** adoptă o formă //ierarhică//, naturală, de altfel, în condiţiile în care proiectele ajung să aibă rapid module şi submodule pe măsură ce se dezvoltă. De asemenenea, această organizare se reflectă şi în structura de directoare a proiectelor. De exemplu, presupunand că directorul ce conţine sursele este //src//, fişierul //Main.java// se va găsi în directorul //src/myapp//. | ||
| + | |||
| + | În continuare, pentru implementarea modulului de reţea în cadrul proiectului //myapp// de mai sus, se poate defini pachetul //network//, care va fi ierarhic inferior pachetului //myapp//. În astfel de situaţii numele de pachete se separă prin ".", ca în exemplul următor: | ||
| + | |||
| + | <code java> | ||
| + | package myapp.network; | ||
| + | |||
| + | public class NetworkConnection { | ||
| + | ... | ||
| + | } | ||
| + | </code> | ||
| + | |||
| + | Fişierul //NetworkConnection.java// se va găsi în directorul //src/myapp/network//. | ||
| + | |||
| + | O documentaţie detaliată legată de oraganizarea în pachete poate fi accesată de [[http://docs.oracle.com/javase/tutorial/java/package/index.html|aici]]. | ||
| + | |||
| + | == Specificatori de acces == | ||
| + | |||
| + | Clasele şi funcţiile menţionate până acum au fost declarate utilizând un specificator special: ''public''. În limbajul Java (şi în majoritatea limbajelor de programare de tipul OOP), orice clasă, atribut sau metodă posedă un **specificator de acces**, al cărui rol este de a restricţiona accesul la entitatea respectivă, din perspectiva altor clase. Există specificatorii: | ||
| + | |||
| + | * **''public''** - permite acces complet din exteriorul clasei curente | ||
| + | * **''private''** - limitează accesul doar în cadrul clasei curente | ||
| + | * **''protected''** - limitează accesul doar în cadrul clasei curente şi al tuturor descendenţilor ei (conceptul de //descendenţă// sau de //moştenire// va fi explicat mai târziu) | ||
| + | * **(default)** - în cazul în care nu este utilizat explicit nici unul din specificatorii de acces de mai sus, accesul este permis doar în cadrul //pachetului// (package private). Atenţie, nu confundaţi specificatorul default (= lipsa unui specificator explicit) cu ''protected''! | ||
| + | |||
| + | **Important**: utilizarea specificatorilor contribuie la realizarea //**încapsulării**//. Amintim, din primul laborator, că încapsularea se referă la acumularea atributelor şi metodelor caracteristice unei anumite categorii de obiecte într-o clasă. //Pe de altă parte, acest concept denotă şi ascunderea informaţiei de stare internă a unui obiect, reprezentată de atributele acestuia, alături de valorile aferente, şi asigurarea comunicării strict prin intermediul metodelor// (= //interfata// clasei). Acest lucru conduce la izolarea modului de implementare a unei clase (= atributele acesteia şi cum sunt manipulate) de utilizarea acesteia. Utilizatorii unei clase pot conta pe funcţionalitatea expusă de aceasta, **indiferent de implementarea ei internă** (chiar şi dacă se poate modifica în timp). Dacă utilizatorii ar avea acces la modul efectiv de implementare a unei clase, ar fi imposibilă modificarea implementării ei (necesitate care apare des în practică) fără un impact lateral asupra utilizatorului. | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
laboratoare/organizare-acces.1375811998.txt.gz · Last modified: 2013/08/06 20:59 by Mihnea Muraru
Page Tools
