This just isnt working

Discussion in 'Plugin Development' started by ChintziSecilMC, Dec 14, 2014.

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

    ChintziSecilMC

    @DeadlyScone

    just another off topic thing here how do i set a data for a Material like you know how for an item stack you do this:
    ItemStack miniBlocks = new ItemStack(Material.LOG, 1, (short) 1); and that would give me 1 of a different type of log, how do i do this with an itemstack?
     
  2. Offline

    DeadlyScone

    Last edited: Dec 16, 2014
  3. Offline

    ChintziSecilMC

    @DeadlyScone
    Well im trying to make a command that builds a christmas tree so im getting the block at the players location and im wanting to set it to a Spruce Log, but i can't use the method that it shown above with the (Short) and all that on a Material.etc
     
  4. Offline

    Bloxcraft

    The Block class has a .setData method, (it's deprecated because of the 1.8 blockstate change), or if you want it to work during 1.8, you have to use the Tree class (instance of MaterialData, get block's MaterialData by getting its BlockState (Block#getState() ) and using BlockState#getData() and BlockState#setData(data) )

    http://jd.bukkit.org/rb/doxygen/da/d03/classorg_1_1bukkit_1_1material_1_1Tree.html
     
  5. Offline

    ChintziSecilMC

  6. Offline

    Dragonphase

    @DeadlyScone

    Don't confuse static with constant. A constant field is one which is set once and cannot be changed. It represents a global, immutable state. Constants are identified as being both static and final. As for non-final, and thus non-constant, fields - they are not very object oriented.

    Static fields belong to their class, and not any one instance of the class; they represent a global state. This means that they can be accessed and modified without an object being instantiated. Why would you want something to have a global state when it is being used in one place and in a non-global context?

    They are a code smell. If you're using static for something such as how @ChintziSecilMC is, then something is wrong. Firstly, the List will always be created regardless of whether or not the Listener is registered. If for any reason he wants to unregister the Listener and register it a second time, the List will remain unchanged, which may cause problems.

    Secondly, there's less room for optimization. For example, a better way of doing this would be to store a non-static List<Player> in a new class (called PlayerSettings for example); create an instance of PlayerSettings and pass it to the Listener. That way, you could do:

    Code:
    private List<Player> playersWithTrails;
    
    public PlayerListener(MyPlugin plugin) {
        playersWithTrails = plugin.getPlayerSettings().getPlayersWithTrails();
    }
    This also provides room for expansion, by allowing you to add additional related fields to PlayerSettings at a later time. By doing this, you're approaching the situation in a more Object-Oriented way.

    The only reasons you should ever need to use static fields are:
    • If your class is a Singleton and it is absolutely appropriate to use static.
    • In Utility classes, if the field is final, thus representing a constant.
     
  7. Offline

    DeadlyScone

    @Dragonphase
    a constant variable can be changed unless it is final. I guess I am trying to ask. Why would you create a new instance of a class just to get or set that variable? Making that variable static works around this while offering less code. Take for example:

    Code:java
    1.  
    2. public class FirstClass{
    3. public static int example = 5;
    4.  
    5. public void someMethod(){
    6. //some code
    7. }
    8. }
    9.  


    Code:java
    1.  
    2. public class SecondClass{
    3.  
    4. public void someMethod(){
    5. int num = FirstClass.example;
    6. int newNum = 10;
    7. FirstClass.example = newNum;
    8. }
    9. }
    10.  
     
  8. Offline

    Dragonphase

    @DeadlyScone

    Again, your understanding of the word "constant" is incorrect. Why would you want to avoid instantiating FirstClass? If your class is designed to be instantiated as an Object you should treat its members as if they were part of an object. As I said before, static fields belong to the class, and not any one instance of the class. There is absolutely no justification for not doing the following:

    Code:
    public class FirstClass {
        private int example;
    
        public FirstClass() {
            this(5);
        }
    
        public FirstClass(int initialExample) {
            setExample(initialExample);
        }
    
        public int getExample() {
            return example;
        }
    
        public void setExample(int example) {
            this.example = example;
        }
    }
    
    public class SecondClass {
        private FirstClass firstClass;
    
        public SecondClass() {
            this(new FirstClass());
        }
    
        public SecondClass(FirstClass firstClass) {
            this.firstClass = firstClass;
        }
    
        public void someMethod() {
            firstClass.setExample(10);
        }
    }

    I don't feel like getting into a big debate over whether using static is wrong or not. The point is, when used exactly like you have just used it, it goes against the principles of the Object Oriented Paradigm, and Java is an Object Oriented Programming language.

    The best way to understand my point is to read up on Java and OOP.
     
    FerusGrim likes this.
  9. Offline

    FerusGrim

    If it's not final, it's not a constant variable.
    Code:java
    1. public final static int COMMANDS_PER_PAGE = 5
    The above is an example of a constant variable. Note that it's final, meaning it cannot be changed. It's static, as its value is not reliant on the instance itself, but rather, as @Dragonphase has stated, is a global, non-changing state of the class itself.

    Usually, constant variables are denoted by being capitalized, so that what you're accessing is more understandable from inside or outside of the class.
    Code:java
    1. SomeClass.COMMANDS_PER_PAGE



    The problem with your understanding of the situation, is that the code above is not OOP. There's no constructor there, so the global state of that class is the only state that will ever exist. There's no reason to reference anything inside of it as anything but static. Technically speaking, those methods should have a return value, probably some value sent to them, and also be static as well.

    In terms of OOP, when a class is instantiated, statics are only used for variables that aren't available to be changed. Anything that can be set, needs a getter, and shouldn't be static.

    EDIT: For the reasons stated above, static values are usually the only methods/values inside of a utility class.

    A utility class is a class that requires no instantiate, and contains methods which take information, process them, and spit something different out. They require nothing more than what you're giving them.
     
Thread Status:
Not open for further replies.

Share This Page