Le funzioni private dovrebbero essere mantenute agli stessi standard delle funzioni pubbliche?

Naturalmente, i metodi privati hanno tanto da guadagnare quanto i metodi pubblici, dal controllo per assicurarsi che ogni singolo bit del loro input sia corretto. In generale, nessun programmatore si sarebbe mai posto la domanda se siano necessari più assegni rispetto a un minor numero di assegni, (duh!) Se non fosse per problemi di prestazioni.

Ora, quando si tratta di verificare materiale non valido, ci sono due tipi di controlli che è possibile eseguire:

• Controlli del tempo di produzione, (in breve, controlli di runtime ) che si verificano sia nello sviluppo che negli ambienti di produzione. (Là fuori sul campo.)

• Asserzioni solo in fase di sviluppo, (in breve, assertions ) che si verificano solo negli ambienti di sviluppo e vengono saltate negli ambienti di produzione.

Le asserzioni hanno la caratteristica sorprendentemente utile di non incorrere in alcuna penalizzazione delle prestazioni negli ambienti di produzione, quindi possono essere utilizzate in modo molto liberale. Vai avanti e asserisci tutto ciò che puoi, non influisce sulle prestazioni. Al contrario, affermare che tutto è buono per la robustezza, è utile per il debug, è utile per la documentazione, è utile per mantenere bassa la complessità dello stato del programma; in breve, è la cosa migliore dopo il pane a fette. Quindi:

The question you should always be asking

is not "should I assert this?"

but "is there anything I forgot to assert?"

Quindi, in un sistema ben progettato, sia i metodi privati che i metodi pubblici controllano tutto ciò che c'è da controllare, l'unica differenza è la seguente:

• Tutti (beh, quasi tutti) dei controlli eseguiti con metodi privati sono asserzioni.

• Molti dei controlli eseguiti con metodi pubblici sono controlli di runtime, ( non asserzioni,) se l'interfaccia pubblica dell'oggetto lo richiede. Generalmente, questi controlli sono per cose che possono verosimilmente accadere in condizioni di utilizzo normali e non sono necessariamente bug.

Ad esempio, se si sta codificando una classe File , in genere un errore nell'aprire il file non è un bug, quindi è necessario controllarlo e generare un'eccezione anche in fase di produzione. D'altra parte, se qualcuno passa il tuo metodo di apertura file pubblico a null nomefile, cioè un bug nel codice del chiamante, quindi il controllo di un nome file nullo può essere un'asserzione.

Generalmente, ogni singola cosa che viene controllata con un controllo di runtime in un metodo pubblico può anche essere ricontrollata in un metodo privato, ma questa volta con un'asserzione, poiché tutto l'input dovrebbe avere è già stato convalidato dai metodi pubblici, quindi qualsiasi cosa negativa che raggiunga un metodo privato significa che hai un bug nel tuo codice.

Quindi in generale:

• Nulla dovrebbe mai essere deselezionato, in metodi pubblici o privati.

• Le asserzioni sono gratuite, quindi usale liberamente.

ESCLUSIONE DI RESPONSABILITÀ: poiché questa è una domanda dell'intervista, tieni presente che quanto sopra può e non può essere quello che l'intervistatore vorrebbe sentire da te. In questi casi è meglio prefisso la tua risposta con un disclaimer del tipo: "Beh, ovviamente seguirò qualunque disciplina sia generalmente usata in casa, ma se dipendesse completamente da me, allora vorrei ..."

YES. I metodi privati dovrebbero essere mantenuti agli stessi standard di quelli pubblici.

Ricorda che c'è una curva a campana.

Ricorda che circa il 50% dei programmatori è al di sotto della media. Per definizione.

Supponi che NON sarai l'unica persona a lavorare sul tuo codice.

Supponiamo che almeno una delle persone che lavora sul tuo codice sarà qualcuno a cui non dovrebbe essere consentito l'accesso anche a Dartmouth BASIC su un minicomputer indipendente.

Ora, sei STILL sicuro che non ci saranno mai loop nei tuoi elenchi?

Non l'ho pensato.

Non sono d'accordo con le altre risposte e dico no . La verifica dell'input è molto più importante in pubblico rispetto ai metodi privati.

Specialmente se scrivi un componente per il riutilizzo, non puoi fare nessuna ipotesi su quali valori sono passati ai metodi pubblici, eccetto ciò che è garantito dal sistema di tipi.

Per i metodi privati è una questione diversa, dal momento che puoi facilmente vedere ovunque il metodo viene chiamato e con quali argomenti, almeno se la tua classe ha una dimensione ragionevole. Se non si assegna mai null a un riferimento a un oggetto, ad esempio, non è necessario verificare null in un metodo privato. In un metodo pubblico non è possibile formulare tali presupposti. Il tuo esempio in cui sai che non hai mai creato cicli in un elenco collegato è lo stesso.

Ovviamente c'è sempre il rischio che qualcuno modifichi un altro metodo nella stessa classe per infrangere le ipotesi, ma poi di nuovo se hai scimmie impazzite che cambiano il codice a caso, rischi anche di eliminare comunque i controlli di verifica. I test unitari rappresentano l'approccio giusto per verificare l'integrità di una classe e proteggersi da modifiche che introducono bug.

In teoria sarebbe bello se tutti i metodi verificassero tutti gli input. ma l'introduzione della verifica ha anche un costo. Ad esempio, un semplice refactoring del metodo di estrazione richiederà la copia della verifica dell'ingresso in pasta dal metodo host, introducendo il peso del codice senza alcun chiaro vantaggio.

Sì.

Una funzione privata interna è chiamata da qualche altra funzione (o è codice morto ).

Sebbene una funzione privata non faccia parte di un'interfaccia pubblica per una classe, uno spazio dei nomi o un modulo, può ancora produrre un lavoro utile per le funzioni che sono parte dell'interfaccia pubblica. Sebbene non sia esposto direttamente, contribuisce all'interfaccia pubblica in modo transitorio.

Le funzioni private devono essere testate, documentate e codificate secondo gli stessi standard delle funzioni pubbliche. L'unico standard su cui sarebbe lassista è la documentazione: dovrebbe esserci una breve nota su ciò che la funzione fa, pre e post condizioni, ma non c'è bisogno di entrare tanto nei dettagli quanto nella documentazione pubblica perché una funzione privata / interna fa non ha bisogno di essere compreso dagli sviluppatori esterni al tuo team.

Scrivi la quantità minima di codice per eseguire correttamente il lavoro. Nel tuo esempio direi che non ti preoccupare, se non c'è modo (senza modifiche al codice) che faccia loop allora non preoccuparti di farlo. Finirai per scrivere meno codice che puoi espandere in un secondo momento, piuttosto che troppi codici che potrebbero potenzialmente confondersi in seguito.