Stavo esaminando la classe StringTokenizer.java e c'erano alcune domande che mi venivano in mente.Metodi privati su metodi pubblici
Ho notato che i metodi pubblici che devono essere utilizzati da altre classi hanno invocato un metodo privato che ha fatto tutto il lavoro. Ora, so che uno dei principi dell'OOD è quello di rendere il più possibile privato e nascondere tutti i dettagli di implementazione. Non sono sicuro di capire completamente la logica dietro questo però.
Capisco che è importante rendere privati i campi per impedire che vengano memorizzati valori non validi in essi (solo uno dei tanti motivi). Tuttavia, quando si tratta di metodi privati, non sono sicuro del motivo per cui sono così importanti.
Ad esempio, nel caso della classe StringTokenizer, non è possibile che abbiamo inserito tutto il codice di implementazione nei metodi pubblici? Come avrebbe fatto la differenza per le classi che usano questi metodi poiché l'API per questi metodi (vale a dire le regole per chiamare questi metodi pubblici) rimarrebbe la stessa? L'unica ragione per cui posso pensare perché i metodi privati sono utili è perché ti aiuta a scrivere codice duplicato. Ad esempio, se tutti i metodi pubblici hanno fatto la stessa cosa, è possibile dichiarare un metodo privato che esegue questa attività e che può essere utilizzata dai metodi pubblici.
Altra domanda, qual è il vantaggio di scrivere l'implementazione in un metodo privato rispetto a un metodo pubblico?
Ecco un piccolo esempio:
public class Sum{
private int sum(int a, int b){
return a+b;
}
public int getSum(int a, int b){
return sum(a,b);
}
}
... Vs
public class Sum{
public int getSum(int a, int b){
return a+b;
}
}
Com'è il primo campione più vantaggioso?
Non ho potuto ottenere il tuo punto. Perdonami se mi manca qualcosa. Mi dici: "Quindi avere un metodo privato è sempre buono, perché sai che non c'è alcun problema nel cambiarlo, anche se puoi tranquillamente aggiungere più parametri al metodo". Ma l'API pubblica di fronte al cliente è sempre la stessa. quindi scrivi tutta la logica all'interno di un metodo pubblico o chiama una funzione al suo interno o fai qualunque cosa il client che guarda all'API pubblica non osservi alcuna differenza. Il codice all'interno dell'implementazione può ancora essere modificato in qualsiasi momento, il che equivale a modificare il contratto/l'implementazione della funzione privata – Saurabh
@saury In questo caso particolare, sì, è la stessa API, ma non è ancora garantito che manterrà lo stesso in futuro Dalla mia esperienza personale posso consigliarti dall'idea di "Oh, facciamolo pubblico direttamente e, se in futuro ne abbiamo bisogno, lo cambieremo". Quello che finisce per accadere è che tali metodi non sono mai diventati privati, quindi è meglio avere un po 'di sovra-architettura all'inizio piuttosto che finire a fare un enorme refactoring in seguito. –
Se un metodo pubblico chiama il metodo privato che è stato modificato "senza problemi", il metodo pubblico non si interromperà comunque? Se è così, non c'è davvero alcuna differenza nel "cambiare in modo sicuro" qualsiasi cosa; tutto ciò che si modifica deve essere testato: renderlo pubblico/privato non ti darà ulteriore sicurezza in questa materia. – gented