Come evitare la duplicazione del codice per un sistema che ha una logica che può cambiare anno dopo anno?

In realtà, penso che le tecniche per evitare la duplicazione del codice siano le stesse di qualsiasi altro sistema. Ad esempio, pensa a una funzione

CalcTax2013(){...};

e supponiamo di dover duplicare quella funzione per l'anno successivo (magari con alcune modifiche)

CalcTax2014(){...};

allora dovresti immediatamente refactoring tutte le parti comuni a una funzione utilizzata da entrambi. Naturalmente, prima dovresti aver scritto alcuni test automatici per assicurarti che il refactoring non rotti nulla.

Ovviamente potrebbe esserci una situazione diversa: quando CalcTax2013 non deve più essere modificato più tardi, diciamo ad esempio dal 01/01/2014. In tal caso, non è necessario alcun intervento di manutenzione su tale funzione, il che rende inutile il refactoring.

Se questo non si applica alla tua domanda, ti preghiamo di dare un esempio più elaborato.

Sembra che tu sia sulla strada giusta. Una soluzione migliore potrebbe essere quella di regolare la struttura del database. Se si archiviano le domande e il codice in tabelle diverse, è sufficiente indicare le rispettive domande e il codice per un particolare anno.

Solo nuove domande e codice dovrebbero essere aggiunti al database.

Direi che è meglio risolverlo assicurandosi che il codice che è più probabile che cambi sia disaccoppiato come può essere. Cerca di implementare l'accesso front-end attraverso un pattern di facciata e fai in modo che le classi implementino un'interfaccia solida, in modo che qualsiasi modifica riguardi solo piccole parti del codice e sia facile da sostituire.

Il concetto di base è quello di astrarre ciò che cambia.

Se hai una serie di logiche che varia, considera il modello di strategia. Ciò implica un numero di classi che implementano tutte una singola interfaccia (o estendono un singolo tipo, a seconda della lingua che si sta utilizzando). L'implementazione appropriata viene istanziata e iniettata nell'oggetto chiamante. Questo è spesso implementato usando un framework per le dipendenze come Spring.

Ad esempio, potresti avere la tua classe di controllo, qualcosa come il questionario, che per la domanda 1 chiama un metodo nell'interfaccia di IQuestionOne. Questa interfaccia è implementata da classi diverse a seconda dell'anno: QuestionOne2013 contenente la logica 2013 e QuestionOne2014 contenente la logica 2014. Potresti quindi creare un Questionario per il 2013 e fare riferimento all'implementazione di QuestionOne2013 di IQuestionOne. Allo stesso modo, il questionario per il 2014 utilizzerà l'implementazione QuestionTwo2014.

Se la logica non cambia, puoi semplicemente riutilizzare la stessa implementazione. Quindi, forse la domanda 2 (astratta come l'interfaccia IQuestionTwo) ha la stessa logica per entrambi gli anni - usa semplicemente la stessa implementazione per entrambi i questionari.