CODEWITHSUNDEEP
javastatic-classes
Ziessel
Ziessel

Reputation: 57

Should I make my class Application static?

I'm building a Java application. I have this class called Application, which contains arraylists of users objects and groups objects. Inside of the classes User and Group, some methods (such as sending a message to another user) needs to get another User object searching by email, username, or another field within the arraylist of users in the class Application. Since Application is the container class, I don't want to have instances of it inside the contained classes Users or Groups.

As I just going to have one instance of the Application class, I was thinking to make this class and its attributes static in order to be able to access the searching methods from classes User and Group, but I'm also not sure about if it's a good idea or a proper use of static classes. Do you think it's right or there's a better option? Thanks in advance

Edit* Another option is to make static the attributes ArrayList of users and groups, since they have to be the same for all possible instances of Application. Do you think that's better?

Upvotes: 1

Views: 165

Answers (3)

Elist
Elist

Reputation: 5533

If you are sure you are going to implement a singleton application, I would recommand an enum singlton.

public enum Application {
    INSTANCE;
    private ArrayList<User> userList;
    // Whatever other members your application should contain
}

However, you should know that in general, static code is breaking the dependency injection design pattern, which can cause sirius problems in large scale applications (watch this Google's video to learn more about dependency injection vs. global state).

It's not that having static code always bad, but in general it should be reserved for stateless utility methods or global constants.

Anyway, if you do decied to implement a singlton, try to stick with only one such across the application. Other classes will become "singltons" if you bind them to the real singlton by adding them as it's fields (you can make a type private inner type of the singlton class to make sure its not getting instantiated from outside, if it makes sense). This way you can avoid static initialization order problems (where singletons depends one on each other and the order the JVM initialize them "magically" matter).

Upvotes: 1

Michał Szydłowski
Michał Szydłowski

Reputation: 3419

Well, that looks like a singleton pattern problem. You declare a static field inside the class, which holds the current instance of that class:

private static Application INSTANCE = null;

And then in a method, you either return the existing instance, or create a new one, that way exists always up to one:

public static Application getInstance(){
    if(INSTANCE == null){
        return new Application();
    }
    else return INSTANCE;
}

Then, using this access point, you call the static method (which you can, without having to instantiate the class first):

Application app = Application.getInstance();

Edit: As suggested in the comments, the constructor of such class should be private, to prevent uncontrolled outward instantiation (just like in multi-threading for example).

Upvotes: 1

avk
avk

Reputation: 871

Using final classes that have static variables and functions is one way of doing things. But calling such a class "Application" might not be the best choice.

Final classes allow you to access these variables and/or functions from all your other classes without creating multiple instances just to get this static data.

But what you should consider is how "static" the data actually is. If part of the variables are not-so-static like a list of users that may grow over time, it could be better to just use for example a UserFactory that itself is static and manages a class user and an "arraylist[User] users" which you can then work with by calling UserFactory.get(), set(), update().

Upvotes: 1

Related Questions