DRY codice non correlato, ma quasi identico

Question

DRY codice non correlato, ma quasi identico

#1 da (111 voti)

33

Ho un codice che è quasi identico, ma usa tipi assolutamente diversi, senza ereditarietà tra loro, sulla variabile principale. Nello specifico, sto scrivendo un analizzatore con Roslyn per C # e VB.NET, con i seguenti tipi:

Microsoft.CodeAnalysis.CSharp.Syntax.AttributeSyntax Microsoft.CodeAnalysis.VisualBasic.Syntax.AttributeSyntax

Mi chiedo se, poiché il codice sta facendo la stessa cosa, dovrei tenerlo il più possibile ASCIUTTO, dividere il meno possibile in metodi separati (ma identici diversi dal tipo), oppure separarlo completamente perché due metodi non sono correlati e le modifiche future potrebbero forzare una versione a cambiare, ma non l'altra (anche se è improbabile)?

Modifica: circa un anno dopo, ho raggiunto lo stesso problema e il team di Roslyn mi ha aiutato a risolverlo: scrivi una classe base che prende generici e ha un parametro TAttributeSyntax che fa la maggior parte del lavoro. Quindi, scrivi le classi derivate con il minimo di dati che richiede un tipo specifico.

design c# dry

posta Hosch250 07.09.2015 - 02:05

fonte

1 risposta

Leggi altre domande sui tag design c# dry

Perché alcuni linguaggi di programmazione funzionale utilizzano uno spazio per l'applicazione di funzione? Perché la cancellazione di solito è molto più difficile da implementare rispetto all'inserimento in molte strutture di dati?

score 111 · Accepted Answer

Non fai SECCO perché qualcuno lo ha scritto in un libro da qualche parte che è buono da fare, lo si fa SECCO perché in realtà ha benefici tangibili.

In particolare da quella domanda:

If you repeat yourself, you can create maintainability issues. If doStuff1-3 all have similarly structured code and you fix a problem in one, you could easily forget to fix the problem in other places. Also, if you have to add a new case to handle, you can simply pass different parameters into one function rather than copy-pasting all over the place.

However, DRY is often taken to an extreme by clever programmers. Sometimes to not repeat yourself you have to create abstractions so obtuse that your teammates cannot follow them. Sometimes the structure of two things is only vaguely similar but different enough. If doStuff1-4 are different enough such that refactoring them to not repeat yourself causes you to have to write unnatural code or undergo clever coding backflips that will cause your team to glare at you, then it may be ok to repeat yourself. I've bent over backwards to not repeat myself a couple of times in unnatural ways and regretted the end product.

Quindi, in fondo, non pensare "oh uomo, questo codice è abbastanza simile, forse dovrei refactoring per non ripetermi". Pensa "il refactoring per rendere questo codice base riutilizzare elementi comuni rende il codice più mantenibile o meno gestibile ?" Quindi, scegli quello che lo rende più manutenibile.

Detto questo, dato SRP e solo cercando di avere classi piccole e flessibili in generale, potrebbe avere senso analizzare il tuo codice per quella ragione , rompe pezzi di comportamento che usano tipi generici (hai detto che sono identici a parte il tipo) in classi piccole. Poi scoprirai che alcune di queste classi sono totalmente identiche (non solo per lo più identiche), e quindi puoi creare un toolkit nel caso in cui desideri aggiungere Microsoft.CodeAnalysis.CPlusPlus.Syntax.AttributeSyntax .