Development Assistance Static Object of main class

Discussion in 'Plugin Help/Development/Requests' started by 8jy89hui, Jan 29, 2015.

Thread Status:
Not open for further replies.
  1. Offline

    8jy89hui

    I personally Like to make a static object of my main class called myPlugin. If you have any reasons why not to use a Static object of your main class please list your reasons below:
     
  2. Offline

    nverdier

    @8jy89hui Statics. What exactly are they? When used for variables, they mean that in each instance of the class, the variable is the exact same. It only gets loaded once, when the class is first loaded. Statics will cause memory leaks if not properly managed, and still aren't good to use. I honestly can't think of one situation where I would use a static. Now what is OOP? Object Oriented Programming is, quite obviously, based off of the concept of objects. Objects interact with each other.

    What can you use instead of statics for accessing other classes? Constructors and instances. For example, instead of using
    Code:
    Test.method("test");
    you would use
    Code:
    Test test = new Test();
    Test.method("test");
    or
    Code:
    new Test().method("test");
    Now on the topic of memory leaks. A memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations poorly. If memory leaks occur with statics, that should tell you something. Statics are potential "incorrectly managed memory allocations". That should really tell you something about statics.

    Ask any decent programmer. Statics are almost always due to laziness, poor planning, bad practices, or a bit of each. There is no reason why you shouldn't be able to us constructors rather than statics, and there are far less consequences.

    TL;DR Statics suck. Use constructors instead. Also, read the post!
     
  3. Offline

    8jy89hui

    @nverdier I mean
    Code:
    public static Test test = new Test()
    
    So that in class X and Class Y you can use Z.test.method("test");
     
  4. Offline

    nverdier

    @8jy89hui Just use constructors in X and Y and pass over the instance of 'Test'.
     
  5. Offline

    8jy89hui

    @nverdier You mean a constructor in Z? So that I can Z.getTest().... That would mean Z has to be either an object or the .getTest has to be static
     
  6. Offline

    nverdier

    @8jy89hui No, I am saying don't use a static! Here, look:
    Code:
    Class Z {
          Test test = new Test();
          X x = new X();
          Y y = new Y();
    
          public Test getTest() {
                return test;
          }
    }
    
    Class Test {
          public testyTest(String str) {
                System.out.println(str);
          }
    }
    
    Class X {
    Z zStance
          X(Z zInstance) {
                this.zStance = zInstance;
          }
    }
    
    Class Y {
    Z zStance
          Y(Z zInstance) {
                this.zStance = zInstance;
          }
    }
    
    Then you can use zStance.getTest(); and use test.
     
  7. Offline

    8jy89hui

    okkk..... But would this still work with public classes though?
     
  8. Offline

    teej107

    @8jy89hui
    Java is an Object Oriented Programming language so it is best to develop with OOP in mind. Passing information in the parameters (of methods or constructors) is the best way to take advantage of OOP. Static isn't a magical access anywhere keyword. Public is the keyword to access members from anywhere. Using static isn't Object Oriented. It is Class Oriented.

    That being said, let me provide an example. Player is a class that holds the player's Location, health, inventory, etc. Yes, you could have the fields storing those values be static and you could access them very easily from anywhere. However since static is Class Oriented, every single Player instance will have the same Location, health and inventory since static is shared among all instances of the classes.

    There are times when using static is appropriate but abusing it just so you can "access it anywhere" is the wrong approach. If there is an appropriate time when using a static field, that field should either be final and/or private. Exposing a field publicly makes it so easy to change the value from anywhere and it could potentially change the outcome your program and finding the source of the problem could be a nightmare. When making a field final, you can't change the value. If a static field is private, you can't change the value outside of the class. Static methods can't access instance fields and if you find yourself changing everything to static because your IDE "says so", stop! In some (or all) cases, it may make sense to change an instance method to static if they don't access any instance members.

    EDIT: If you ever make your Plugin field static, make it is private and make sure to nullify the value in the onDisable method.
     
    nverdier likes this.
  9. Offline

    8jy89hui

    Of course you would not have the players variables be static..... I am not talking about having an MULTIPLE objects variables be static. I am talking about having a a SINGLE version of an object where I define THIS ONE VERSION as static. That means I can Access it anywhere... Yes this is class oriented but I can access it in the objects too... I simply dont see the problem with having the single instance of the plugin be static.
     
  10. Offline

    teej107

    There is the singleton pattern approach if you want to be guaranteed one instance of a class.
    Code:
    public class SingletonExample
    {
        private static SingletonExample singleton;
    
        private SingletonExample()
        {
            //Code here
        }
    
        public static SingletonExample getSingleton()
        {
            if(singleton == null)
            {
                singleton = new SingletonExample();
            }
            return singleton;
        }
    }
    The above code is one of they ways to achieve it.
    http://en.wikipedia.org/wiki/Singleton_pattern

     
Thread Status:
Not open for further replies.

Share This Page