Should I use a static list for my inventory system?

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 expireDate everywhere. 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.

That list holding your MilkTea instances is your "product database" that is used for both your master data management (creating new MilkTea instances, modifying them, or deleting them) and your order management (ordering MilkTeas, producing them, and deliver them to the client).

As the product database have to exist independently for both, the master data management and the order management, a static list would be a decent replacement for what is called a 'persistence layer' elsewhere. But for a really productive system, this has to be something like a file on disk, or a real database system.

Of course you can add a class that represents that persistence layer, and inside that, you hide how you really store your MilkTea instances; that class will just have an interface that allows you to add/replace, remove and find MilkTea instances, like the List, too.

Yes, so you can access list without create a new instance. And if you change anything in another class, all classes and all instances will get your change.

For more information: https://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html

It depends on how you will use MilkTeaList.
If you creates only one MilkTeaList instance there are no reasons to make it static. But if you will create new instance each time when you want to add new MilkTea to list (this is bad desicion) so you need to declare it as static.

Also if you will use it from more than one thread you should make it concurrent-safety.

First consider what static means. When you declare static variables, they are created during the time of executing the program and are bound to the class they are declared in.

Meaning if you want to have just one instance of a variable you should use static.

If it is not static you would have to instantiate it every time you create a new Object.

Keep in mind if you share this ArrayList variable with countless classes you might not get the result you expect,since everyone changes it.