È un odore di codice chiamare il metodo pubblico nel metodo privato della stessa istanza di oggetto?
No, non c'è cattivo odore. Potrebbe essere necessario, perché sospetti che sia sbagliato? Un metodo a livello atomico è un'entità indipendente che svolge un'attività. Finché svolge un'attività, chiunque possa accedervi può chiamarla per eseguire l'operazione.
Odore di codice? Sì, non è una brutta cosa, ma un buon indicatore che la classe potrebbe avere troppe responsabilità.
Prendilo come un segno che la classe potrebbe dover essere suddivisa in oggetti diversi, i metodi privati non dovrebbero davvero chiamare metodi pubblici dello stesso oggetto, certamente in un design OO pulito.
Ovviamente, una volta ispezionata la classe e le ragioni della chiamata al metodo sono chiare, potrebbe essere un uso perfettamente ragionevole, in generale ci si aspetterebbe che i metodi di utilità della classe siano privati, ma se uno è abbastanza utile per essere pubblico e utilizzato con altri metodi, in genere mi aspetto che anche questi metodi siano pubblici.
Come per tutti gli odori di codice, questa è una motivazione per un'ulteriore ispezione del codice, la razionalizzazione e forse il refactoring, ma non una causa di allarme.
Potrebbe portare a spiacevoli sorprese se qualcuno che non ha letto il codice sorgente di questa classe prova a suddividerlo e a scavalcare il metodo pubblico. Che questa sia una vera preoccupazione dipende ovviamente dalla tua situazione. Forse dovresti prendere in considerazione la possibilità di rendere il metodo pubblico o anche la finale di classe.
Non penso che possiamo genaralizzare.
Tutto dipende molto dal contesto.
Potrei avere, diciamo, un metodo di utilità pubblica in una classe che è usata da altre classi, e anche qualche metodo privato nella stessa classe.
No. Che altro dovrebbe essere fatto in quel caso? Rendi pubblico il metodo privato o il metodo pubblico? Copia-incolla il codice dal metodo pubblico a quello privato?
NO , nessun cattivo odore qui.
se implementiamo l'interfaccia di una coda con List, è un cattivo odore chiamare semplicemente le funzioni List appropriate per ottenere facilmente l'implementazione della coda?
se hai qualcosa e vuoi convertirlo in qualcos'altro (come wrapper) allora non è un cattivo odore, la sua riutilizzabilità del codice con pattern di progettazione agisce a livello di funzione (è una funzione un oggetto?)
So che questo è un vecchio post, ma è qualcosa che ho discusso sul lavoro. Lo considero un odore di codice, e non riesco a capire perché mai vorresti farlo. Se un metodo privato deve chiamare un metodo pubblico, il contenuto del metodo pubblico dovrebbe essere preso e inserito in un metodo privato, che entrambi i metodi possono quindi chiamare. Perché?
Il metodo pubblico può contenere test che non sono necessari una volta eseguito internamente il codice di esecuzione. Potrebbe ricevere un UserObj e voler testare le autorizzazioni utente ad esempio.
Dopo una chiamata pubblica, potresti avere il requisito di bloccare l'oggetto, se utilizzi il threading, quindi internamente, non vorrai richiamare su un metodo pubblico.
Più probabile introdurre errori circolari e loop infiniti e eccezioni di mem secondo me.
Semplice e semplice, cattivo design e "pigro". I metodi pubblici forniscono l'accesso al mondo esterno. Non c'è motivo di tornare indietro quando sei già dentro.
Immagina il contrario. Sei in un metodo privato e hai bisogno di funzionalità in un metodo pubblico Cosa succede se non puoi chiamare quel metodo pubblico da quello privato. Cosa faresti?
La risposta è chiaramente che quando vuoi la funzionalità in un metodo pubblico dovresti essere in grado di chiamare quel metodo dai metodi di questa classe o da altre classi.
Nel mio codice creo spesso getter di caricamento pigri, vale a dire che l'oggetto viene inizializzato la prima volta che viene richiesto e successivamente riutilizza lo stesso oggetto istanziato. Tuttavia, un oggetto istanziato utilizzando un carico pigro implica che non può essere necessariamente istanziato in un dato punto. Piuttosto che avvolgere la mia mente attorno alla sequenza di chiamate in modo tale che so che quell'oggetto è già istanziato o ripetendo lo stesso codice di un carico pigro all'interno di un altro metodo, chiamerò semplicemente il loader pigro ogni volta che ho bisogno di quell'oggetto.
Proprio come è possibile utilizzare i metodi pubblici in modo intelligente, è anche possibile utilizzarli in modo errato. Un esempio di questo potrebbe essere un metodo pubblico che elabora i suoi parametri prima di chiamare un altro metodo privato. Sarebbe un errore chiamare questo metodo pubblico casualmente semplicemente perché hai gli stessi parametri. L'errore è sottile ma è un errore di progettazione più di ogni altra cosa e richiede che tu impari a gestire i parametri del metodo interno piuttosto che i parametri del metodo pubblico.
Quindi, per rispondere alla tua domanda, non è certo un codice cattivo se lo usi correttamente.
La domanda che devi porci è perché la tua classe ha lo stesso bisogno dei clienti della tua classe? Di solito una classe ha esigenze molto diverse dai suoi clienti. Quindi sì, questa è un'indicazione che hai o
(a) esposto qualcosa pubblicamente che dovrebbe essere privato; o
(b) il comportamento della classe non è abbastanza ristretto (si pensi al principio della singola responsabilità).
Leggi altre domande sui tag object-oriented language-agnostic encapsulation