Controllo d'accesso

Precedentemente, abbiamo detto che ruby non ha funzioni, masolo metodi. Comunque esistono più tipi di metodi . Inquesto capitolo introduciamo il controllod'accesso.

Immaginate ciò che accade quando definiamo un metodonel "livello più alto" , cioè fuorida una definizione di classe. Possiamo pensare ad un talemetodo come ad una funzione in un linguaggiopiù tradizionale come il C.

ruby> def quadrato(n)    |   n * n    | end   nilruby> quadrato(5)   25

Il nostro nuovo metodo sembrerà non appartere anessuna classe, ma in effetti ruby lo mette nela classeObject , che è la superclasse di ognialtra. Come risultato, ogni oggetto ora dovrebbe essere ingrado di poter usare quel metodo . Questa cosarisulterà essere vera, ma c'è un dettaglio:si tratta di un metodo privato di ogni classe.Discuteremo un po' di cosa significa questa dichiarazionepiù avanti, ma una delle conseguenza è chepotrà essere invocato solo in “stilefunzione”:

ruby> class Foo    |   def quarta_potenza_di(x)    |     quadrato(x) * quadrato(x)    |   end    | end  nilruby> Foo.new.quarta_potenza_di 10  10000

Non ci è permesso di applicare esplicitamente ilmetodo su di un oggetto:

ruby> "pesce".quadrato(5)ERR: (eval):1: private method `square' called for "pesce":String

Ciò preserva in maniera intelligente la naturapuramente OO di ruby (le funzioni sono ancora metodi deglioggetti, ma il ricevitore èimplicitamenteself ) pur fornendo funzioni chepossono essere scritte come in un linguaggio tradizionale.

Una disciplina mentale comune nella programmazione OO, allaquale abiamo fatto rigferimento in un capitolo precedente,riguarda la separazone tra specifica edimplementazione, o tra quali compiti sisuppone che vengano svolti da un oggetto e comevengono effettivamente svolti. Il funzionamento interno di unoggetto dovrebbe generalmente essere mantenuto nascosto aisuoi utilizzatori; essi dovrebbero soltanto preoccuparsi dicosa entra e cosa esce, e fidarsi che l'oggetto sappiaquelloche deve fare al suo interno. Ad esempio spessoè utile avere nelle classi dei metodi che il mondoesterno non vede, ma che sono usati internamente (e possonoessere migliorati dal programmatore quando si vuole, senzacambiare il modo in cui gli uytenti vedono gli oggetti dellaclasse). Nel seguente semplice esempio, pensate aengine come al lavoro interno ed invisibiledella classe.

ruby> class Prova    |   def volte_due(a)    |     print a," volte due e' " ,engine(a),""    |   end    |   def engine(b)    |     b*2    |   end    |   private:engine  # questo nasconde engine all'utente    | end   Testruby> test = Test.new   #<Test:0x4017181c>ruby> test.engine(6)ERR: (eval):1: private method `engine' called for #<Test:0x4017181c>ruby> test.volte_due(6)6 volte due e' 12.   nil

Potremmo esserci aspettati che test.engine(6)ritornasse 12, ma invece vediamo che engineè inaccessibile quando agiamo come utenti esterni aProva. Solo ai metodi di Prova,come volte_due, viene permesso di usareengine. Abbiamo bisogno di passare attraversol'interfaccia pubblica, che consiste nel metodovolte_due . Il programmatore che èresponsabile di questa classe può cambiareengine liberamente (qui, forse cambiandob*2 con b+b, assumendo checiò porti a prestazioni migliori) senza infastidire ilmodo in cui l'utente interagisce con gli oggettiProva. Questo esempio ovviamente è tropposemplice per essere utile; i benfici del controllod'accesso diventano più chiari quando cominciamo acreare classi più complesse ed interessanti .



Ti potrebbe interessare anche

commenta la notizia