Ho un database che memorizza i dati del cliente. Tutti i dati sono in una tabella. Per ogni cliente, c'è una riga al giorno. I clienti hanno diversi tipi di contratti, il loro formato dei dati rimane lo stesso, tuttavia, le dinamiche sottostanti sono diverse.
Sto creando un'applicazione per simulare queste dinamiche e sto lottando per trovare una buona struttura di oggetti per implementarla. Ho trovato due approcci:
Approccio 1
Vorrei iniziare con una superclasse per tutti i tipi di contratto. Gestire l'accesso al database e le proprietà fondamentali, come il numero del contratto, così come i metodi fondamentali (trovare prima data, valore totale, ecc.)
Quindi aggiungerei la sottoclasse per i tipi specifici per aggiungere metodi specifici (ad esempio, calcolare il valore dell'indice ottimale, il cui algoritmo dipenderebbe dal tipo di contratto).
Tuttavia, il tipo di contratto è determinato da un valore nel database. Pertanto, se l'oggetto del contratto carica i propri dati dal database, dovrebbe quindi modificare la propria classe in base al tipo. Non penso sia un buon design.
Approccio 2
In alternativa, potrei creare una classe contract_manager per contenere un elenco di tutti i contratti, recuperare i dati dal database e generare e riempire gli oggetti del contratto.
In tale scenario, tuttavia, temo che l'interfaccia da ricordare sia più complicata e l'accesso al database non possa essere nascosto all'interno dell'oggetto. Ciò sarebbe auspicabile, dal momento che queste classi faranno parte di una libreria di analisi e prototipazione per un gruppo di analisti di dati.
Quale sarebbe il modo corretto di formulare questo problema? Quale sarebbe l'approccio migliore per gestirlo?