Controllare l’accesso ai membri di una classe

Con l’utilizzo dei qualificatori di accesso possiamo determinare quando un particolare campo o metodo di una classe può essere invocato da un’altra. Impararne il corretto utilizzo è un requisito essenziale per chiunque desideri progettare un’interfaccia software solida, robusta e ben scritta.

Il linguaggio Java definisce due livelli di accesso:

  • a livello di classe, o esternopublic, oppure package-private (nessun modificatore esplicitamente dichiarato);
  • a livello di membro di una classe, o interno: public, private, protected, o package-private (nessun modificatore esplicito).

Quando una classe viene dichiarata public, diventa visibile a tutte le altre. Se invece non viene definito nessun modificatore, allora rimane visibile soltanto all’interno dello stesso package dove la classe è stata dichiarata.

All’interno di una classe possiamo utilizzare il qualificatore public per rendere accessibile ovunque quel campo o quel metodo, oppure nessun modificatore (package-private) per limitarne l’accesso all’interno dello stesso package. In aggiunta possiamo utilizzare i qualificatori private e protected. Il primo indica che il membro può essere visto soltanto nella sua classe. Il secondo invece indica che il membro può essere visto anche dalle classi dello stesso package e, in aggiunta, dalle sue classi discendenti, anche in package differenti.

La tabella che segue schematizza quanto appena detto:

Livelli di accesso
Modifier Class Package Subclass World
public Y Y Y Y
protected Y Y Y N
no modifier Y Y N N
private Y N N N

 

Come si può vedere, una classe ha sempre accesso a tutti i suoi membri. La colonna Package ci dice invece quando il membro è accessibile dalle altre classi dello stesso package. La colonna Subclass indica invece quando una classe figlia ha accesso al membro, a prescindere dal package di appartenenza. La colonna World, infine, ci dice quando tutte le altre classi hanno accesso al membro.

I livelli di accesso influiscono in maniera significativa nella progettazione di un’interfaccia software. Quando si usano le classi provenienti da una libreria esterna, come ad esempio quelle della libreria standard di Java, i qualificatori determinano infatti quali classi e quali membri è possibile utilizzare nel proprio codice sorgente. Inoltre, quando si scrive una nuova classe e si definisce il livello di accesso di ogni singola variabile e di ciascun metodo, si definisce implicitamente una nuova interfaccia, nascondendo al mondo esterno l’implementazione dell’interfaccia stessa. Questo concetto è alla base dell’incapsulamento e del polimorfismo nel paradigma della programmazione a oggetti.

Prendiamo adesso, a titolo di esempio, un insieme di classi definite in due package distinti e vediamo come i qualificatori di accessi modificano la visibilità di ogni membro nelle altre classi.

classes-access

Visibilità
Modifier Alpha Beta Alphasub Gamma
public Y Y Y Y
protected Y Y Y N
no modifier Y Y N N
private Y N N N

 

Ecco alcuni consigli per scegliere il livello di accesso più appropriato: se altri programmatori usano la nostra classe, dobbiamo assicurarci che non si verifichino errori causati da un utilizzo scorretto.

  • Limitiamo l’accesso per quel particolare membro della classe al livello più restrittivo, purché ciò abbia senso. E’ sempre meglio usare il qualificatore private a meno che non ci sia una ragione valida per fare diversamente.
  • Evitiamo di dichiarare campi public, ad eccezione delle costanti. Variabili pubbliche tendono infatti a legarti a quella particolare implementazione e limita la flessibilità nella modifica e revisione del codice.

BDE su Windows 7

Se come me stai cercando un modo di far funzionare il Borland Database Engine su Windows 7, sia 32 che 64 bit, allora sei nel posto giusto!

Il BDE è un software ormai vecchio e vetusto. Tuttavia esistono in giro alcune applicazioni che ancora ne fanno uso. I problemi sono dovuti principalmente alla non corretta gestione dei permessi con l’UAC e al programma di installazione originale che non è pienamente compatibile con il Windows Installer.

Ho trovato in rete un pacchetto di installazione contentente l’ultima versione del BDE (5.2.0.2) e che supera queste limitazioni. Il nuovo setup permette l’installazione dei file necessari al corretto funzionamento, dopo aver richiesto i privilegi amministrativi tramite il prompt di UAC. E’ presente una funzione che permette la rimozione di eventuali chiavi di registro rimaste a seguito di una precedente installazione corrotta.

File allegato: Setup_BDE52

Proteggere i files con lo sticky bit

Nei sistemi Linux e unix-like se un utente ha i permessi per scrivere in una directory allora può rinominare o eliminare i files contenuti in essa, anche se non ne è il proprietrio. Per prevenire ciò il proprietario della directory, o l’amministratore del sistema, può impostare il cosiddetto sticky bit. In questo modo i soli utenti che possono rinominare o rimuovere i files di quella directory sono il proprietario del file, il proprietario della directory e l’utente root.
Facciamo subito un esempio. Creiamo un nuova directory e impostiamo lo sticky bit:

MacBookPro:~ mark$ mkdir share
MacBookPro:~ mark$ chmod 1777 share
MacBookPro:~ mark$ ls -ld share
drwxrwxrwt 2 mark staff 68 9 Mag 16:26 share

Con questi permessi qualunque utente può creare dei file ma può eliminare solo quelli che gli appartengono. Così l’utente pippo non può eliminare i file dell’utente topolino, anche se ha i permessi per scrivere sulla directory:

MacBookPro:~ pippo$ ls -l
total 3
-rw-r--r-- 1 pippo staff 120 Nov 19 11:32 data.pippo
-rw-r--r-- 1 topolino staff 3421 Nov 19 15:34 data.topolino
-rw-r--r-- 1 pluto staff 728 Nov 20 12:29 data.pluto
MacBookPro:~ pippo$ rm data.topolino
data.topolino: 644 mode ? y
rm: data.topolino not removed.
Permission denied