Dove collocare funzioni molto specializzate che utilizzano pesantemente una classe?

La prima cosa che farei è capire quali metodi richiederà il codice dell'utente finale. Creo quindi una classe astratta contenente tutti questi metodi come metodi astratti. Questo significa che il tuo codice utente ora dipende da una classe astratta che è buona perché la disaccoppia da come sono implementati i metodi e ti permette di eliminare facilmente questi metodi per testare.

Quindi crea una classe che implementa tutti questi metodi e importa anche la classe contenente il tuo codice di basso livello. Questi metodi effettueranno chiamate a quelli di basso livello. Ora, se il tuo codice di basso livello cambia, non influirà direttamente sul tuo codice utente, significa semplicemente che devi aggiornare la classe implementando l'interfaccia astratta.

Quindi quando costruisci il tuo programma il tuo codice utente prende la classe astratta nel suo costruttore e fa tutte le chiamate attraverso di essa. Questa è una forma di iniezione delle dipendenze ed è uno strumento utile per disaccoppiare il codice.

La risposta di SteveChallender è buona e l'ho svalutato. (Ricorda, il "upvoting" sta per "questa risposta è utile"). Tuttavia, nel tuo caso potrebbe rappresentare un po 'di over-engineering. Tu sei quello che sa veramente, e quindi chi giudica se è così, sto semplicemente facendo notare la possibilità che sia così.

Ecco il mio input sulle tre possibilità che hai elencato:

• Potrei aggiungere i metodi alla classe originale, ma la classe diventerà molto gonfia.

Questa potrebbe essere la scelta migliore. Ultimamente ho notato che molti programmatori sono totalmente spaventati dal semplice conteggio delle righe. Qualcuno che ha recensito il mio codice una volta ha definito una mia classe di 250 righe "terribilmente lunga". Il povero ragazzo non ha visto classi di 2500 linee che ho. Ecco la cosa: se la classe sta davvero facendo solo una cosa, e se non c'è una struttura interna in essa, (nessun insieme disgiunto di stato interno usato da diversi gruppi di metodi), se i metodi stanno semplicemente facendo cose che invocano altri metodi , quindi appartengono davvero alla stessa classe. È solo un fatto della vita. È un enorme errore aggiungere una struttura aggiuntiva non necessaria alla progettazione del proprio sistema solo per ridurre il numero di linee di una classe altrimenti perfettamente perfetta, solo perché il numero di linee in quella classe supera alcuni ciechi preconcetti su quale sia un buon numero di linee dovrebbe essere. Ricorda, "Le cose dovrebbero essere il più semplici possibile, ma non più semplici". (A. Einstein.) Ed è perché se provi a renderli "più semplici di quelli possibili" allora sei praticamente garantito che finirai per renderli più complicati.

• Potrei scrivere un modulo di funzioni giuste, ma avrebbero sempre avuto bisogno di un argomento di classe.

Sì, non sarebbe una cosa molto intelligente da fare. Un gran numero di funzioni che accettano tutte una determinata classe come argomento è in effetti un gran numero di funzioni che urlano "mettici in quella classe!" o, nel peggiore dei casi, "mettici in classe e rendi quell'oggetto un membro di quella classe, così sappiamo dove trovarlo!"

• Potrei ereditare e creare una nuova classe: MoreSpecificClass.

Rendere le funzionalità disponibili per diversi sottoinsiemi di codice è uno dei motivi meno legittimi per l'utilizzo dell'ereditarietà. È necessario utilizzare l'ereditarietà se MoreSpecificClass ha una relazione "è una" con LessSpecificClass. Avrà una tale relazione? Avrai mai una funzione che accetta "LessSpecificClass" come argomento ed è necessario passare un "MoreSpecificClass"? Dubito che tu abbia intenzione di fare una cosa del genere, quindi dubito che l'eredità sia adatta qui.