Static vs Other

Discussion in 'Programming' started by bman7842, Jun 9, 2015.

  1. When I first started developing plugins I was very inexperienced and could only write code when I saw specific things. Now I'm better and have more of a grasp on the concept of Java and the purpose of everything but I still have one question. When is it necessary or proper to use static variables and methods? I have been finding myself making a lot of my methods static recently. I don't know if I like this mainly because a lot of my internal methods are accessible to anyone who has access to my plugin. I also hear that static methods and variables can cause a lot of data failure and this is scary to think as well. As I get better at coding, I want to write things that work for everyone and are a lot more controlled and contained. I know that there are many ways of avoiding static variables including things such as storing all the classes in the main class and then adding a constructor to each class so that they have access to the main class but is this just as bad to do?

    So should I be using static variables for my internal methods or should I keep them private/public and only use statics for methods and variables I want other people to use like an API? If you have any suggestions on when it is proper to use statics or you have suggestions on how I should manage all my classes please tell me! Also, if you know anything about making an acceptable API for other developers to use please inform me! Thanks! (This is completely for my advice and future reference)
     
  2. Ahh, statics. Believe it or not, static vs non-static is actually really important. When hiring, my boss actually looks at that. So, when should you use static, and when should you not? This question boils down to software structure. You should consider how you want to organize your code early on. My recommendation for when to use static and not is as follows: If you can go without static, go without. Don't get me wrong, static is great. But there are some things that it just isn't good for. Static winds up creating sloppy project structure sometimes, and using it only when necessary just makes your software cleaner. So when is it necessary? Static is mainly necessary when you are ONLY going to have ONE of a field. For example, I tend to use static fields for things like the Main class, so that I can access it elsewhere, or a chat prefix I'm going to be using throughout my code. With reference to static methods, I rarely use them. Static methods can come in handy when trying to put a related method into a class that it is related to, when you absolutely cannot access it where needed as an instance method. The most common use for static methods in my code is usually for deserializes (or when I'm lazy).

    Hope I helped!
     
    • Like Like x 1
    • Creative Creative x 1
  3. Generally speaking you should stay away from static methods and variables since it's not good Object Oriented Programming (OOP) and it can cause memory leaks. Static methods are fine for small and simple utility methods. Static variables are used for global constants. For an API, you can create a single class with convenience methods that invoke methods from the API's implementation instance. Without the static class, it would be difficult to obtain the implementation instance, however the actual implementation is still an object instance.

    If you need a central place to store global values that are not constant, you should create a class to store them with getter methods and pass around the instance of the class through constructors or retrieve it as needed from the API's implementation instance.

    I suggest you learn more about the Object Oriented paradigm as well as Procedural. (I have no recommended reading, sorry)
     
    #3 JCThePants, Jun 9, 2015
    Last edited: Jun 10, 2015
    • Useful Useful x 3
  4. It's just a programming paradigm. The less you use it, in a general sense, the better. If you have a lot of related functionality, you should probably have an object to bind it all to, this makes your code more readable, conform to standards better and should help make it more extensible.

    As in the case of static methods, if you create one function as static initially, say that does something like create a file in a particular location, that's probably okay. If later, you find yourself creating more file related methods, it's probably a much better idea to encapsulate all that functionality into one object and the use that object as a hook to your functionality. The reason why this is useful outside of the encapsulation, is because you can have internal constants, functionality and the like that others don't really need to see, as well as a plethora of other reasons.

    tl;dr: Related functionality - use an object - unrelated, once off type methods - use a static method. Though you should always be looking for a way to make those static methods into some kind of object that you can better use and don't create a utility object, that makes literally no sense.

    For static variables, they're kind of useful for constants and IDS, since every class has access to them if they're public and the like. They belong to that class and not a particular object. So when you create a static variable and create an object in that class, that object does not have an instance of that static variable. The class holds the reference to the static variable which can then be altered how you like, a useful example on the small scale is assigning an int ID variable that every increases by one every time you call that class's constructor. Generally speaking, don't do this at anything larger than very small scale, since you can incur a lot of issues doing this. The static constants are useful since you can reference them like this: Classname.constant


    My opinion: People will try to push you away from it as much as possible and call your code demon code if you use too much of it, which is certainly true, you are using Java which is an OOP language, use objects. That being said, don't be afraid to use it. Just always go back and make sure the way in which you are using it after you progress your project a little more makes sense.
     
    • Like Like x 1
  5. Actually, this question reminds me a bit of the "Evil Singleton Discussion" that originated some years ago. Basically you should not have any global variables such as statics or singletons. The main argument of all opponents of singletons is, that they greatly damage the re-usability of your code proposed in Object Oriented Design. Whenever you use static instances in your code you basically make them depend on the class providing the singleton instance. You can therefore not simply copy your class and use it in another project as it will fail to resolve the singleton from there. If you pass around instances instead ( for example by specifying dependant modules in the constructor ) you are even able to only use an interface. Thus you can easily change the implementation and / or use multiple implementations for distinct objects as well, thus granting you a lot more freedom and flexibility whilst also complying with the ideas of object oriented programming patterns. I would therefore strongly advise you to not use static variables too often.

    Of course, their are situations in which static variables or objects are reasonably good: As my previous speakers already mentioned, constants are a very good example for a good usage of statics. If you've worked with Servlets you might also know the situation that you simply have no way to persist data. If you still need to do that you don't have any other choice than using statics under most circumstances.

    So don't get me all wrong here, statics / singletons do have positive aspects, too, but I would recommend using instances and interfaces instead, whenever this is possible.

    Best regards,
    BlackyPaw.
     
  6. The difference between using singletons and static methods and fields is a matter of preference and code style. As long as you stay consistent (and you agree on the same style with any existing project contributors), do whatever works for you.

    If you can make a method from one of your objects static, do it if you feel that makes your code more organized. If you don't like it, don't do it. It does nothing to the performance of the application and is purely for organization.
    What is generally acceptable in Java/Bukkit:

    - Wrap all objects and types that you want to expose to other plugins in 'API classes', or have all your types implement interfaces and expose the interfaces (but not the implementation) to other developers. The former is more accepted.

    - Either have a static class or accessors in your plugin class for grabbing instances of your types from your API. If I had a flying horse API, I would probably have a static method FlyingHorses.createHorse(...), but that is mostly up to you.

    The whole purpose of an API is in its name, it's a application programming interface, because you're using an API interface to interact with the underlying functionality of your plugin (this doesn't mean it has to be an actual Java interface, but rather some level of abstraction that allows developers to hook into your code without worrying about changes between different builds/versions).