This may be more of a software design question – but I’ve been working on my first “real, non-academic” Java project and have recently learned about good code practices (such as breaking down methods into respective classes, so that my controller class doesn’t necessarily have 50+ methods all together) – and it’s led me to a question about data storage..
In a few words – my project reads a CSV file, where each line contains a person’s name and “start date” – and then gives the program user periodic reminders based on what day each person is at relative to their start date.. (For example, you would get notifications when person X has reached day Y..)
Currently, I have a Person class that holds a name and date, an ArrayList of type Person in my controller, as well as a method used to read the CSV file, create objects of type Person, and add them to the ArrayList. This AL lives in the Controller class – and I was wondering if there was a better way to do this considering that other methods (which may be in other classes) will need access to such data?
1
I’d normally expect you to have some sort of model object separate to the controller. That would manage the handling of your data and perhaps delegate to some sort of persistence layer (a DAO or data access object).
Your DAO may well support some sort of query type mechanism e.g.
Person getPersonByName(String name);
List<Person> getPersons();
etc. (your requirements will dictate the above). Consequently it’s hidden from your application that you’re currently using an array list, and at some stage you can substitute an alternative version of your DAO that delegates to a database, a remote web service, etc. etc.
As such, this:
well as a method used to read the CSV file, create objects of type
Person, and add them to the ArrayList.
should possibly reside somewhere within your DAO (since you’d presumably do something different if you were connecting to a database). You may reference the above within an initialise() method or similar, perform it lazily on the first request etc.
Your controller would then manage your model and control additional functionality, such as your reminder functionality, your mailer etc.
In considering the right approach you should think about how the input data might change over time and where the ultimate source of truth is for that data. For example if it’s a list of employees then what happens if a new hire comes on board. Does someone then send an updated CSV file to you, or would you expect (in a future version) to be accessing a centralised HR database that would get updated (by another team) when new hires come on board etc.
Future requirements like this are the reason why abstracting the data storage code away from the rest of the application makes sense. MVC is a common design pattern to achieve this (see https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller and http://www.austintek.com/mvc/ ), in this instance your Model is currently a CSV file but in future could be a database either within your application or another application.