La versione originale di questa domanda specificava "liste" come destinazione dell'operazione dei metodi di supporto. Questo è un fatto critico molto qui, ma parlerò di due scenari.
Il primo scenario è uno in cui si ha un'operazione generica che si esegue su un oggetto di una classe che hai scritto. Questo dovrebbe assolutamente essere parte della classe. A volte è difficile adattarlo a una classe esistente: il design orientato agli oggetti può essere difficile a volte, certo. Se stai discutendo di mettere una tale funzione di utilità in un modulo separato perché non sei sicuro di dove si adatta, potrebbe essere un'indicazione (alcuni la chiamano " code smell ") che il design della classe o del modulo non è l'ideale. Vorrei indirizzarti a una risposta che ho scritto per una domanda diversa che copre un aspetto del codice di refactoring per rimuovere i dati temporali accoppiamento (chiamare il metodo A prima del metodo B). A volte quando un modulo fa troppo può essere difficile ragionarlo e capire dove vanno i metodi e come usarli insieme. Può aiutare a farlo a pezzi. Ciò può rendere più chiara la risposta alla tua domanda.
Il secondo scenario è sfortunato. Supponiamo che tu abbia bisogno di una nuova operazione di elenco generale, in cui "elenco" è una classe fornita dal framework principale e del tuo linguaggio, che detto framework non è modificabile dall'utente (in genere, ma non sempre) . Non c'è davvero nessuna soluzione migliore qui. Per farla breve, la comunità del software è giunta da tempo al consenso sul fatto che l'opzione meno valida è quella di creare classi con metodi statici che manipolino le strutture di dati fondamentali. Se guardi Apache Commons , ad esempio, ci sono StringUtils e CollectionUtils classi in cui ogni classe ha metodi di utilità per una classe Java single core. Ogni classe utils corrisponde a una classe Java single core, contenente metodi di utilità che qualcuno ha trovato utile quando si lavora con esso, ma l'interfaccia Java e le implementazioni mancavano della funzionalità necessaria.
Un'opzione che potresti considerare è decorare un oggetto se devi modificare il suo comportamento. Ad esempio, supponiamo di avere un elenco non ordinato di numeri interi. Tuttavia, si desidera iterare la lista in ordine crescente definito dall'ordinamento naturale degli interi (cioè il modo in cui si conta). Piuttosto che modificare l'elenco, puoi avvolgere o decorare l'oggetto. La maggior parte dei metodi passa semplicemente alla lista sottostante, tuttavia, i metodi usati per l'iterazione alterano il loro comportamento. Quindi, quando vuoi ripetere l'iterazione in un ordine diverso, avvolgi la lista in questo nuovo oggetto e chiama qualsiasi metodo utilizzato dalla tua lingua per ottenere un iteratore.
Ci sono opzioni qui e non c'è necessariamente una risposta "giusta" o "sbagliata". Non esiste " best practice ." Essendo relativamente nuovo alla professione, il tuo take-away dovrebbe essere che la progettazione del software è un processo intrinsecamente complesso che comporta dei compromessi. È necessario decidere quali compromessi positivi e negativi sono accettabili per il programma che si sta scrivendo. Noi (qui su questo sito) possiamo aiutarti a identificare le opzioni e magari anche a ridurne alcune, ma alla fine, è il tuo invito a procedere.