È considerata una cattiva pratica di ingegneria del software utilizzare sempre metodi "pubblici"? [duplicare]

I metodi, le proprietà e i costruttori (ovvero i membri di una classe) che definisci utilizzando un accessor public determinano l'area di superficie con cui gli utenti della tua classe potranno interagire. Qualsiasi metodo che non vuoi far parte di questa superficie non dovrebbe essere reso public .

Motivi per cui alcuni membri potrebbero non essere pubblici:

1. Sono dettagli di implementazione; implementano il comportamento richiesto dai membri pubblici, ma non sono pensati per essere chiamati direttamente dall'esterno (cioè private ).
2. Sono pensati per essere accessibili in una classe derivata, ma non chiamati direttamente. (cioè protected ).

Pensaci in termini di casa tua. Non lasciare che l'uomo delle tasse entri in casa tua, trovi il libretto degli assegni e ti dia un assegno. Piuttosto, l'uomo delle tasse ti manda un conto, tu rivedi il conto, scrivi un assegno e spediscilo a lui. L'invio della fattura e il controllo sono entrambi atti pubblici. Gli atti di revisione del disegno di legge e la stesura del controllo sono dettagli di implementazione eseguiti nella privacy della propria casa di cui l'uomo delle imposte non ha bisogno di sapere nulla.

Ulteriori letture
Incapsulamento

Risposta breve:

Dichiarare un metodo o campo "pubblico" si traduce in una promessa:

Dear colleages,

I invite you to use this method or field wherever you find it appropriate.

I have documented everything you need to know about its usage, and as long as you don't violate this documentation, I take responsibility for every bug in this context.

I promise that I'll never change the behaviour of this method / interpretation of the data in this field, or I'll analyze all of your code using my method and change it appropriately.

Sei sicuro di volerlo (specialmente la parte "documentazione")?

Se ho una classe:

class SomeThing
{
    public DoSomething()
    {
        DoThing1();
        DoThing2();
    }

    public DoThing1() ...
    public DoThing2() ...
}

Ora potrei voler chiamare tutti solo DoSomething . Ma ho reso pubblico anche DoThing1 e DoThing2 , quindi le persone potrebbero ancora usarli. Di conseguenza, quando in seguito riscrivo DoSomething per utilizzare solo DoThing3 , sono bloccato: non riesco a sbarazzarmi di DoThing1 e DoThing2 , anche se non li uso più.

Se li avessi contrassegnati come private , non si presenterebbe alcun problema di questo tipo. Posso tranquillamente eliminarli senza rompere il codice esterno.

Quindi una buona regola empirica è contrassegnare tutto private a meno che non sia assolutamente necessario accedere al di fuori della classe. Se è necessario accedervi, contrassegnarlo internal se possibile, in quanto rimane "privato" per quel progetto e può essere modificato senza interrompere altri progetti. Solo se è necessario come parte dell'API pubblica del progetto, devi contrassegnarlo public . Questo vale tanto per le classi, le enumerazioni ecc. Quanto per i membri di quelle classi ecc.

Le classi espongono un'interfaccia (la parola inglese, non la parola chiave c #), attraverso la quale le usi.

Rendi le interfacce facili da usare correttamente e difficili da usare in modo non corretto.

Se la tua classe ha una funzione che non dovrebbe essere chiamata da altre classi, eppure permetti ad altre classi di farlo, ti rendi facile usare la classe in modo errato. Questo introduce bug, costi di manutenzione e costi di formazione. Non è così male se sei l'unico sviluppatore: conosci già il codice e sai quali funzioni puoi o non puoi chiamare. A meno che non si debba rivisitare il codice 6 mesi dopo, a quel punto non si ricorda.

Se stai scrivendo un software "su larga scala" (cioè lavorando con più team, rilasciando nuove versioni nel tempo, hai abbastanza codice che è difficile tenere tutto in testa in una volta), allora sì è una cattiva ingegneria pratica (vedi le altre grandi risposte).

Se stai solo scrivendo codice one-off (ad esempio uno script a file singolo per spingere i dati in giro con solo 3 metodi), allora è eccessivo.

Gli specificatori di accesso fungono anche da una sorta di documentazione / commento / descrizione. Quando leggi qualche codice sorgente, se vedi qualcosa di privato sai immediatamente che la cosa è usata solo internamente. Questo aiuta a migliorare la leggibilità del codice.