Come/quando scrivere metodi riutilizzabili in OOP

Question

Spesso mi trovo in una situazione in cui sto ripetendo due, tre righe di codice in un metodo più volte e poi penso se dovrei metterlo in un metodo separato per evitare la duplicazione del codice . Ma poi quando sposto quelle linee dal metodo trovo che il metodo appena creato non è riutilizzabile, è stato usato solo una volta o richiede un sovraccarico per essere utile per un altro metodo.

La mia domanda è che tipo di modelli dovremmo cercare che indicano che dovremmo creare un nuovo metodo. Apprezzo la tua risposta.

Answer 1

Come regola generale, pensa sempre a quelle situazioni come entità funzionali. Se un pezzo di codice esegue in modo funzionale un'attività (conversione di stringhe complesse, analisi, ecc.), È necessario scrivere un metodo riutilizzabile. Se la funzione è specifica per un determinato tipo, scrivere extension method.

Answer 2

È possibile creare una variabile locale all'interno della funzione di tipo Action<> o Func<> e assegnare lo snippet di codice ad esso. Quindi puoi usarlo ovunque all'interno della tua funzione senza inquinare la tua classe con troppe piccole funzioni di aiuto.

Answer 3

Se le righe di codice che si desidera spostare su un altro metodo eseguono un insieme specifico di azioni (come leggere un file, calcolare un valore, ecc.), È meglio effettuare il refactoring in un altro metodo di supporto. Anche in questo caso, eseguire questa operazione solo se il metodo di supporto viene chiamato in diversi punti del codice o se il metodo del chiamante è troppo lungo (la definizione di too long dipende dallo sviluppatore).

Domande simili

• How do programmers practice code reuse
• What techniques do you use to maximise code reuse?
• Code Reusability: Is it worth it?
• Coding Priorities: Performance, Maintainability, Reusability?

Answer 4

Vorrei iniziare leggendo sul principio DRY (Do not Repeat Distinti elf) si spera che ti dia una buona risposta per la tua domanda, che è una domanda che tutti gli sviluppatori dovrebbero chiedersi a proposito, ottima domanda !!

Vedi Don't repeat yourself

ho voluto lasciarlo a DRY perché è un concetto semplice ma potente che avrà bisogno di un po 'di lettura e un sacco di pratica per ottenere buon add. Ma lasciami provare a rispondere direttamente alla tua domanda (IMHO),

Se non puoi dare al tuo metodo un nome che rifletta esattamente ciò che il tuo metodo sta facendo, spezzalo in pezzi che hanno un significato.

Ti ritroverai ad asciugare il codice con facilità, i pezzi riutilizzabili verranno visualizzati e probabilmente non troverai mai un codice ripetuto.

Lo farei anche se significasse avere metodi con solo un paio di righe di codice.

A seguito di questa pratica sarà dare un senso al tuo codice, renderlo leggibile e prevedibile, e decisamente più riutilizzabile

Answer 5

Non mettere troppa funzionalità in un metodo/classe. Prova a seguire lo single responsibility principle. Ci vorrà del tempo per familiarizzare con questo approccio. Ma una volta raggiunto quel livello, noterai che è fatto tutto da solo. Prima di programmare, prova a chiedere a te stesso quali unità funzionali include il tuo concetto.

Ad esempio, si desidera sviluppare un'applicazione in grado di indicizzare il contenuto dei file PDF. E 'solo finzione, ma a prima vista, ho potuto individuare almeno tre componenti:

1. PdfParser - questo vi dà il contenuto di un file PDF
2. indicizzatore - prende input da parser e conta le parole significative
3. Deposito: è per la persistenza; questo potrebbe essere reso generico; quindi diciamo semplicemente repository.Get<IndexData>(filename) o qualcosa di simile

Si dovrebbe anche provare a codificare con le interfacce. Soprattutto quando è coinvolta una specie di interfaccia utente. Ad esempio, stai sviluppando un client di chat con WinForms. Se si segue il modello MVC/MVVM, è possibile (facilmente, più semplice della codifica rispetto a un oggetto Form) utilizzare la logica originale con una versione WPF del client.

Answer 6

Se si crea un metodo per la riutilizzabilità, ma non lo si utilizza in più di una posizione, la riusabilità del metodo non viene realmente verificata. Estrai i metodi quando ha senso e riprogetta questi metodi per la riusabilità quando hai effettivamente l'opportunità di riutilizzare il codice.