Regola pratica: evitare che funzioni pubbliche chiamino altre pubbliche

Se una funzione pubblica chiama un’altra pubblica, stai probabilmente degradando la tua API¹.

Scenario tipico: scrivi foo, parte di foo esiste già in bar. L’istinto DRY spinge a richiamare bar da foo. Resisti. Estrai un helper privato con la logica condivisa. Fai chiamare l’helper sia a foo sia a bar. Così l’interfaccia resta progettata per chi la usa, non per comodo interno¹.

Perché succede. Un’API pubblica deve essere ottimizzata per il call site. Se la usi per implementare se stessa, nasce una tensione tra usabilità esterna e riuso interno. Nel tempo compaiono parametri opzionali “solo interni” che l’utente non dovrebbe impostare. Questi parametri arrivano dopo, durante l’evoluzione del codice. L’interfaccia si sporca e peggiora¹.

Se l’implementazione condivisa è privata, la tensione si allenta. Puoi modificare la firma dell’helper quando serve. Il cambiamento resta locale e costa poco. L’API pubblica non assorbe dettagli d’implementazione¹.

C’è un’eccezione chiara: le scorciatoie. Una funzione pubblica che incapsula una sequenza comune di chiamate ad altre funzioni pubbliche deve chiamarle direttamente. Nessun livello privato in mezzo. Serve a verificare che sia una scorciatoia reale, non uno strato intermedio fuori posto¹.

L’autore vorrebbe portare un esempio concreto, ma dichiara di non averlo a portata e chiede di fidarsi della regola pratica. Il nucleo resta operativo: condividi l’implementazione in privato, proteggi la forma dell’API in pubblico¹.

Sul fronte test, una risposta molto votata su Stack Overflow critica le chiamate tra funzioni pubbliche perché rendono più difficile fare mocking del singolo metodo. L’articolo contesta l’assunto: è l’approccio di test a essere fuorviante. Dovresti mockare l’I/O, non i metodi. E dovresti testare la funzionalità, non l’unità in isolamento. Fanno eccezione le librerie pubbliche con API stabile, un ambito ristretto ma importante¹.

Un’obiezione accetta la regola solo se sancita da uno standard. La replica è netta: non si seguono linee guida per autorità, ma per le ragioni che le sostengono. Le best practice possono concentrare buone motivazioni, ma non sostituiscono il giudizio del progettista¹.

Checklist essenziale:

• Se due funzioni pubbliche condividono logica, estrai un helper privato e fai convergere lì le chiamate¹.
• Evita parametri “solo interni” nelle funzioni pubbliche. Se servono, appartengono all’helper privato¹.
• Se definisci una scorciatoia, compola come concatenazione esplicita di chiamate pubbliche. Niente helper privato in mezzo¹.
• Nei test, mocka l’I/O e misura la funzionalità. Non inseguire il mocking dei metodi¹.
• Applica le regole per il motivo che le giustifica, non perché “ufficiali”¹.

Una domanda guida aiuta a non sbagliare: prima di far chiamare una pubblica da un’altra, chiediti se stai per introdurre un parametro che l’utente non dovrebbe vedere. Se la risposta è sì, ti serve un helper privato¹.