I'm developing a MilkTea Inventory and Ordering System in which I've already created a MilkTea class for my MilkTea objects. Now, I am planning to add all my MilkTea objects to an ArrayList. My system should be able to add, edit, display and delete Milktea as well as order MilkTeas. Now, my problem is determining the program design I should implement. Should I make the array list for my MilkTea, static?
- My array list can be changed overtime.
- My array list for milkteas will be also accessed on other class related to ordering.
- My array list is not immutable.
So far, this is my class for adding, editing, deleting and displaying MilkTeas:
package inventory;
import java.util.ArrayList;
public class MilkTeaList {
public ArrayList<MilkTea> list = new ArrayList();
public void addMilkTea(String flavorName,String[] sizes, double[] prices, int stock) {
list.add(new MilkTea(flavorName, sizes, prices, stock));
}
public ArrayList<MilkTea> getList() {
return list;
}
}
If you're using a database, I suggest you implement normal CRUD methods in a DAO class (call your current class MilkTeaListDao) and rely on the database's transaction integrity.
If not, call your class MilkTeaListHandler or MilkTeaListController, add a getInstance() method (and make sure you only have one single object of the class by having a private constructor), and use methods that manipulate the list. The list should not be static and the methods should have a global synchronize lock to ensure transaction integrity. And the getList() method should return a copy of the list, not the list itself.
I notice you get a few contradicting answers to this question so let me provide a few arguments and explanations for my suggestion:
- Using a static list that can be manipulated anywhere is convenient in the beginning of a project, but it can eventually grow into a headache you have to deal with for the rest of the project's lifetime. For example, lets say that one part of the code is storing the list to disk (using a for loop) while another part of the code (at the same time) is adding, updating and removing items in the list. Then you don't know what is stored on disk (what came first, the save or the update), and you will at some stage (maybe after several years) get nullPointerExceptions since the save feature assumes that there are records in the list that someone else has just removed.
- When the MilkTea object changes, you will need to make updates in the entire code. For example, remember to add
expireDateeverywhere. If all methods that manipulate the list are gathered in one place it is easier to change them (and a lot easier to see what effects the changes have since you will get compile errors in the rest of the code). - If add/remove/update is spread out, it is likely that the rest of the logic surrounding your MilkTea also will spread out. When logic changes you are likely to find duplicated code throughout your project, and it will be tedious and error-prone to update it in multiple places. An example of logic is error handling. Lets say that when the system updates your stock by reading rows from a file, an exception will be thrown is the price is set to zero. Good. But for the feature where the user can manually update the stock info from a web interface, you forgot to add that limitation. Not good. If the manipulating methods were gathered in one place, you would have to do the price==zero check exactly once, and then you would know it will forever.