Le migliori pratiche per l'utilizzo di pubblico, protetto, privato?

12

È corretto affermare che è buona norma impostare tutto in privateprimo piano quando si codifica qualcosa?

E quindi aggiornarlo solo protectedse una sottoclasse ne ha bisogno o publicse ne ha bisogno un'altra classe?

— AJJ
fonte

2

Se stai creando alcune API, devi anticipare le funzionalità di cui un chiamante potrebbe aver bisogno. Quindi dovrai pensare di più ai tuoi modificatori di accesso. Dipende da chi sta usando il codice che stai scrivendo.

— user2023861

Possibile duplicato di TUTTE le variabili devono essere dichiarate private?

— moscerino del

10

Risposta breve: Sì

Risposta più lunga:

Sì, ma questo non dovrebbe essere interpretato come un suggerimento per iniziare scrivendo le tue lezioni con tutto ciò che è privato; tale approccio implica la progettazione di una classe concentrandosi sui dettagli di implementazione prima di scegliere un'interfaccia.

Uno degli aspetti più importanti da considerare nella progettazione di una classe è il modo in cui verrà utilizzata; che implica pensare ai tuoi metodi pubblici prima di iniziare a pensare ai dettagli privati / di implementazione.

Inoltre, questo approccio di solito perde le possibilità di chiedersi "Come scriverei un test unitario per questa classe?" - che è una domanda importante da porre anche se in realtà non stai scrivendo test unitari. (Relativo: "Quali sono i principi di progettazione che promuovono il codice testabile?" )

Quindi, una volta definita l'interfaccia pubblica, è una buona idea impostare il resto su privato perché la maggior parte di questi sarà in genere un dettaglio di implementazione grintoso che non interessa a nulla al di fuori della classe.

— Ben Cottrell
fonte

Quindi, se dovessi provare a riassumere ciò che ti stai dicendo (per vedere se capisco), è una buona idea invece pensare prima all'interfaccia rivolta al pubblico (cioè come viene effettivamente utilizzata questa classe dal fuori per cominciare?) e poi rendere tutto il resto privato?

— AJJ

1

@ArukaJ Un buon approccio è scrivere codice che userà le tue classi prima di costruire l'implementazione. Questo può essere un po 'un problema di pollo o uovo fino a quando non inizi a scrivere prima i test unitari.

— JimmyJames,

1

@ArukaJ In generale sì; che all'inizio può sembrare più difficile da fare, anche se come menziona JimmyJames, sembra molto più intuitivo quando si scrivono test unitari. Può comportare una mentalità leggermente diversa, ma l'obiettivo è quello di pensare più attentamente a ciò che rappresenta la tua classe e a come appaiono i tuoi input / output - nel complesso è solo un modo molto più "OO" di pensare al design; è più probabile che si traduca in classi ben incapsulate con elevata coesione.

— Ben Cottrell,

Sono diffidente nell'utilizzare i test unitari per progettare la tua classe, perché i test unitari non sono quelli che la useranno davvero. Tuttavia, sono decisamente meglio di niente nel pensare a come verrà usata la classe.

— user949300

8

"E quindi aggiornarlo per proteggerlo solo se una sottoclasse ne ha bisogno, o pubblico se ne ha bisogno un'altra classe?"

Questo è l'approccio sbagliato. In fase di progettazione, dovresti sapere quale accesso pubblico vuoi dare. Di solito dai accesso pubblico perché è tutto lo scopo della tua classe. E dai accesso protetto perché vuoi che le sottoclassi accedano alle cose. E usi il privato per cose che non sono affari di nessun altro.

Ora, se qualcuno ha bisogno di accedere a cose a cui non può accedere, allora dovresti pensare davvero a quel bisogno . Non dovrebbero aver bisogno di tale accesso o il tuo design è sbagliato. Forse il tuo design è sbagliato e qualcosa non è pubblico che dovrebbe essere pubblico, quindi lo cambi. Ma se il tuo design è giusto, allora c'è qualcosa di sbagliato nella necessità , quindi risolvi questo invece di danneggiare il tuo design.

— gnasher729
fonte

Diciamo che si dispone di una classe che non si ha intenzione di sottoclasse in questo momento (e potrebbe mai bisogno di) e un metodo che, se si dovesse creare una sottoclasse la classe, sarebbe utile / necessario per / dalla sottoclasse. Faresti quel metodo privateo protected?

— Lfk,

Dovrebbe essere la risposta accettata, rendere tutto privato all'inizio suona come se non volessi pensare / progettare.

— Niing

1

La chiave per comprendere questo aspetto della programmazione orientata agli oggetti è il concetto di incapsulamento dei dati . L'idea è di rendere una classe più facile da capire nascondendone i dettagli di implementazione. Questo si chiama nascondere i dati . Pertanto, vogliamo solo esporre (rendere pubbliche) le funzioni necessarie per utilizzare la classe. Queste funzioni sono l' interfaccia per la classe.

Pensa a un'interfaccia come la ruota di un'auto. Decidi in che direzione va la macchina girando la ruota, ma sotto i coperchi ci sono valvole rotanti, idraulica, pulegge che cambiano la rotazione delle ruote, ma non devi essere un ingegnere meccanico per guidare una macchina.

Quindi la risposta alla tua domanda è sì. Vuoi nascondere quanti più dettagli possibili su una classe da altre classi. Capire quando qualcosa dovrebbe essere pubblico, privato o protetto è facile da imparare ma difficile da padroneggiare.

— Chris Ghyzel
fonte