Qual è il punto di definire i Modificatori di Accesso?

StackOverflow https://stackoverflow.com/questions/1888521

  •  19-09-2019
  •  | 
  •  

Domanda

Capisco le differenze tra di loro (almeno in C#).So che gli effetti sono gli elementi a cui sono assegnati.Quello che non capisco è il motivo per cui è importante per la loro attuazione - perché non hanno tutto il Pubblico?

Il materiale che ho letto sull'argomento, di solito va in su come le classi e i metodi non dovrebbero avere accesso inutile per gli altri, ma non ho ancora incontrato un esempio del perché e come tale sarebbe una brutta cosa.Sembra una questione di sicurezza, ma Io sono il programmatore;Creare metodi e definire quello che sarà (o non sarà) fare.Perché dovrei spendere tutto lo sforzo per scrivere una funzione che ha cercato di cambiare una variabile non dovrebbe, o provato a leggere le informazioni in un'altra classe, se il che sarebbe un male?

Mi scuso se è una domanda stupida.E ' solo qualcosa che mi sono imbattuto in sui primi articoli che ho mai letto su OOP, e non ho mai sentito come veramente cliccato.

È stato utile?

Soluzione

Prima, nulla nella lingua ti costringe a usare i modificatori di accesso - sei libero di fare tutto il pubblico in classe se lo si desidera.Tuttavia, ci sono alcune ragioni convincenti per il loro utilizzo.Ecco il mio punto di vista.

  1. Nascondere i dettagli di come la classe opera consente di proteggere che classe usi non previsti. Mentre si può essere il creatore della classe, in molti casi, non sarà il solo consumatore, o anche manutentore.Nascondendo stato interno protegge la classe per la gente che non può capire il suo funzionamento come te.Rendendo tutto pubblico, crea la tentazione di "aggiustare" il interno stato o di comportamento interno quando la classe non è agire il modo in cui si desideri - piuttosto che correggere l'interfaccia pubblica di implementazione interna.Questa è la strada della rovina.

  2. Nascondere interne aiuta a de-ingombrare lo spazio dei nomi, e consente l'uso di strumenti come Intellisense per visualizzare solo le informazioni pertinenti e significativi metodi/proprietà/campi.Non sconto di strumenti come Intellisense - sono un mezzo potente per gli sviluppatori di identificare rapidamente ciò che si può fare con la vostra classe.

  3. Nascondere interni, consente di strutturare un'interfaccia appropriata per il problema la classe è solving.L'esposizione di tutti gli elementi interni (che spesso sensibilmente superiori alle esposti interfaccia) rende difficile poi capire quello che la classe sta cercando di risolvere.

  4. Nascondere interni, consente di mettere a fuoco i tuoi test sulla porzione appropriata - l'interfaccia pubblica.Quando tutti i metodi/proprietà di una classe sono pubblici, il numero di permutazioni è necessario testare potenzialmente aumenta in modo significativo - poiché ogni particolare percorso di chiamata diventa possibile.

  5. Nascondere interni consente di controllare (imporre) la chiamata percorsi attraverso la vostra classe. Questo rende più facile per garantire che i consumatori a capire che cosa la vostra classe può essere chiesto di fare e quando.In genere, ci sono solo un paio di sentieri che attraversano il codice che siano utili e significative.Permettendo un consumatore di prendere qualsiasi percorso, rende più probabile che non sarà possibile ottenere risultati significativi e di interpretare che come il codice essere bacato.Limitare il modo in cui i consumatori possono utilizzare la classe in realtà li libera per utilizzare correttamente.

  6. Nascondere l'implementazione interna libera di modificare, con la consapevolezza che non si potrà non avere un impatto negativo i consumatori della classe - così a lungo come interfaccia pubblica rimane invariato.Se si decide di utilizzare un dizionario piuttosto che un elenco internamente - nessuno si cura.Ma se hai fatto tutti gli interni della classe disponibile, qualcuno potrebbe scrivere il codice che dipende il fatto che il tuo internamente l'utilizzo di un elenco.Immaginate di dover cambiare tutti i consumatori quando si desidera modificare tali scelte circa la vostra applicazione.La regola d'oro è:i consumatori di una classe non si cura di come la classe fa quello che fa.

Altri suggerimenti

I'm the programmer è un presupposto corretto solo se sei l'unico programmatore.

In molti casi, altri programmatori lavorano con il codice del primo programmatore. L'usano in modi che non intendeva per giocherellare con i valori dei campi che non dovrebbero, e creano un hack che funziona, ma si rompe quando il produttore del codice originale cambia.

OOP è sulla creazione di librerie con contratti ben definiti. Se tutte le variabili sono pubblici e accessibili ad altri, poi il "contratto" include teoricamente ogni campo nell'oggetto (ei suoi sotto-oggetti), così diventa molto più difficile costruire una nuova, diversa implementazione che onora ancora il contratto originale.

Inoltre, le "parti in movimento" di più del vostro oggetto sono esposti, più è facile per un utente della classe di manipolarla in modo non corretto.

Probabilmente non hai bisogno di questo, ma ecco un esempio che considero divertente:

Diciamo che vendere una macchina senza cappuccio sopra il vano motore. Vieni notte, il conducente accende le luci. Si alza alla sua destinazione, esce dalla macchina e poi si ricorda ha lasciato la luce accesa. E 'troppo pigro per aprire la porta della vettura, in modo tira il filo alle luci fuori da dove è attaccato alla batteria. Questo funziona bene - la luce è fuori. Tuttavia, poiché non ha usato il meccanismo previsto, si ritrova con un problema la prossima volta che sta guidando al buio.

Vivere negli Stati Uniti (andare avanti, mi downvote!), Si rifiuta di assumersi la responsabilità per il suo uso non corretto del viscere della vettura, e si fa causa, il produttore per la creazione di un prodotto che è pericoloso guidare al buio perché le luci non può essere attivata in modo affidabile dopo essere stato spento.

Questo è il motivo per cui tutte le auto hanno cappe sopra i loro vani motore:)

Un esempio più serio: si crea una classe Fraction, con un numeratore e il denominatore di campo e un sacco di metodi per manipolare le frazioni. Il tuo costruttore non lasciare che il suo interlocutore creare una frazione con un denominatore 0, ma dal momento che i campi sono pubblici, è facile per un utente di impostare il denominatore di una frazione esistente (valido) a 0 e ilarità ne consegue.

E 'principalmente una cosa nascondersi e condivisione. Si può produrre e usare tutto il proprio codice, ma altre persone forniscono le librerie, ecc per essere utilizzati più ampiamente.

Fare le cose non pubblica consente di definire in modo esplicito l'interfaccia esterna della classe. La roba non pubblico non fa parte del l'interfaccia esterna, il che significa che è possibile cambiare tutto quello che vuoi internamente senza influenzare chiunque utilizzi l'interfaccia esterna,

Si desidera solo per esporre l'API e tenere tutto il resto nascosto. Perché? Ok Assumiamo si vuole fare in una libreria Matrix impressionante in modo da rendere 

class Matrix {
   public Object[][] data //data your matrix storages
   ...
   public Object[] getRow()
}

Per impostazione predefinita ogni altro programmatore che utilizzano la libreria vorranno massimizzare la velocità del suo programma sfruttando la struttura sottostante. 

//Someone else's function
Object one() {data[0][0]}

Ora, si scopre che utilizzando l'elenco di emulare la matrice aumentare le prestazioni in modo da cambiare i dati da 

Object[][] data => Object[] data

cause Object one() a rompere. In altre parole, modificando la tua implementazione hai rotto la compatibilità all'indietro: - (

si incapsulamento dividere implementazione interna dall'interfaccia esterna (ottenuta con un modificatore private). In questo modo è possibile modificare l'attuazione il più possibile senza rompere la compatibilità a ritroso: D Utile !!!

Naturalmente se si è l'unico programmatore che sta andando mai modificare o utilizzare quella classe si potrebbe così come tenerlo pubblico.

Nota: Non ci sono altri vantaggi importanti per incapsulare la tua roba, questo è solo uno dei tanti. Vedere incapsulamento per maggiori dettagli

Credo che la migliore ragione di questo è quello di fornire livelli di astrazione sul vostro codice.

Per quanto l'applicazione cresce, è necessario avere i vostri oggetti che interagiscono con altri oggetti. Avendo campi modificabili pubblicamente rende più difficile per avvolgere la testa in giro l'intera applicazione.

La limitazione quello che dovete fare pubblica sul tuo classi rende più facile per il vostro disegno astratto modo da poter capire ogni strato di codice.

Per alcune classi, può sembrare ridicolo avere membri privati, con un gruppo di metodi che semplicemente impostare e ottenere quei valori. La ragione per questo è che diciamo di avere una classe dove i membri sono pubblici e accessibili direttamente: 

class A 
{
    public int i;

   ....
}

E ora si va sull'utilizzo che in un mucchio di codice che hai scritto. Ora dopo aver scritto un mucchio di codice che accede direttamente e ora ci si rende conto che avrei dovuto alcuni vincoli su di esso, come dovrei essere sempre> = 0 e meno di 100 (per ipotesi). Ora, si potrebbe passare attraverso tutto il codice dove ho usato e verificare la presenza di questo vincolo, ma si può solo aggiungere un metodo Seti pubblica che avrebbe farlo per voi: 

class A
{
    private int i;
    public int I 
    {
        get {return i;}
        set 
        {
            if (value >= 0 && value < 100)
                i = value;
            else
                throw some exception...
         }
    }
}

Questa nasconde tutto questo controllo degli errori. Mentre l'esempio è banale, situazioni come queste vengono in su abbastanza spesso.

Non è legato alla sicurezza a tutti.

modifers di accesso e la portata sono tutti di struttura, gli strati, l'organizzazione e la comunicazione.

Se si è l'unico programmatore, è probabilmente bene fino ad avere così tanto codice, anche non riesci a ricordare. A quel punto, è proprio come un ambiente di team -. I modificatori di accesso e la struttura del codice di guida a rimanere all'interno dell'architettura

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top