Multiple Classes!

Discussion in 'Spigot Plugin Development' started by Creepermanthe3rd, Jun 14, 2016.

Thread Status:
Not open for further replies.
  1. So I was making a GUI and I made on a command it will open up a gui but the gui I made in a diffrent class but it not opening it up. What do I do to make it be able to open the Inventory even tho its not in the same class
     
  2. Instantiate it, or make it static.
     
  3. Make it a method... also learn Java ;)
     
    • Optimistic Optimistic x 1
  4. That's better wording m8 than mine, brain freeze xD
     
    • Optimistic Optimistic x 1
  5. D: static classes scare me. Please don't make a static class.
    Use design patterns like the Service Locator. Can't stress enough how much that one specifically has saved me.
     
  6. That is.. really hacky. Kind of scary. You find that better than static?
     
    • Agree Agree x 1
  7. Yes. I was about to say "let me explain" but actually this book does a far better job than I could.
     
  8. Just stop with the StaticAbuse. Just take an instance from that class, out it in your onEnable, and get the instance and open the GUI.
    Or you can make a everything in the same class :p, but just use the instance ;)
     
  9. Or instead of a Singleton or a single giant class, use the Service Locator pattern ;)
     
  10. Static.. Please don't use static. This is the evielst thing that you can use.
     
  11. At least tell them to use the ServicesManager provided by Bukkit, rather than your badly written class.

    • If you're going with static, at least make it a singleton. The least you should do is removing the public constructor.
    • Use Map as your field type rather than HashMap (programming against abstractions rather than implementations, Liskov Substitution Principe)
    • Don't use primitive wrappers where not required (Boolean)
    • Don't catch Exception
    • Don't ignore Exceptions when important (i.e. ignoring an Exception thrown by Class#newInstance and returning null on failure)
    • Calling methods with reflection? Why not provide a lower bound generic type with at least has those methods?
      • And you can even make the methods default, so the implementation is not required
    • Map#containsKey is a waste, use Map#computeIfAbsent instead so you don't query the Map twice with an additional put/get.
    • Also, binding your services to a Class might easier than binding it to a String, as you have to maintain only one Mapping rather than two.
     
  12. The class I linked is a direct port from AS3. If there's better changes available, by all means make a pull request. I'm happy to learn!
    Also, I'm talking less about my direct class (which I linked because it's Java and relatively easy for people here to understand) and more about the actual concept of the pattern.

    I wasn't aware ServicesManager existed. It seems like a better (and native) implementation. Use that.
    • Singletons, like static classes, have their use. I would put it in the main Plugin class because of Bukkit functions that require it as an argument.
    • I already talked about List vs ArrayList (Map vs HashMap) in another thread, but I honestly prefer using HashMap and ArrayList (most of the time) because if I do then I don't end up accidentally casting to a wrong type somewhere down the line. Using the subclasses provides compiler errors which are easier to deal with than relative unknowns in the future.
    • I agree
    • Don't catch Exception.. Most of the time. try/catch is slow and a lot of the time you want things to error out if there's a problem. On the other hand, sometimes if there's an error (or exception) you actually just want to ignore it. In the case of a lot of third-party libraries, for example, Exception gets thrown everywhere. It's something I don't agree with, but it's a reality we, as programmers, need to deal with that other people's code is going to be a factor in our own codebase.
    • Same as above
    • Again, I agree - Reflection should be used when dealing with unknowns (other people's - or your own - future code, for example) to help keep things as generic and simple as possible.
    • Didn't know that was a thing. Makes me think I'll need to re-write some things later.
    • Binding to a string allows for multiple classes of the same type. It's not beautiful, but it works if you have, say, a large number of Registries in your Service Locator. A better solution may be to create a new RegistryLocator service, but the irony of the redundancy makes it seem like a bad idea ("I find my code ironic" is never something I want to be saying)
     
  13. Blatantly down casting is a faulty design to start with, and absolutely not an argument against Liskov Substitution Principle. You use abstract types as field types to create flexibility. Down casting violates this, and should not be done. You should only use concrete classes when there's a compelling reason to do so, which in this case, there is not. HashMaps and ArrayLists provide no additional methods over their interfaces, hence should be avoided as field types.

    [EDIT] Down casting in cases where you might be fed subtypes, but not the specific types* (i.e. Bukkit's events). Obviously, instanceof checking should always be done before a down cast.
     
    • Agree Agree x 1
Thread Status:
Not open for further replies.