I have a database that stores client data. All data is in one table. For each client, there is one row per day. Clients have different kinds of contracts, their data format remains the same, however, the underlying dynamics are different.
I am creating an application to simulate those dynamics and I am struggling finding a good object structure to implement this. I came up with two approaches:
I would start with a superclass for all types of contract. It would handle the access to the database and fundamental properties, such as the contract number, as well as fundamental methods (find first date, total value, etc)
Then I would subclass this for the specific types to add specific methods (e.g. calculate optimal index value, the algorithm of which would be depending on contract type).
However, the type of contract is determined by a value in the database. Therefore, if the contract object loads its own data from the database, it would then need to change its own class depending on the type. I don't think is good design.
Alternatively, I could create a
contract_manager class to hold a list of all contracts, retrieve the data from the database, and generate and fill contract objects.
In that scenario however I fear that the interface to remember would be more complicated, and database access could not be hidden inside the object. This would be desirable, since these classes will be part of an analytics and prototyping library for a team of data analysts.
What would be the correct way of phrasing this problem? What would be the best approach to handle this?