Best way to organise code

Discussion in 'Plugin Development' started by MeJellyPelly, Dec 29, 2014.

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

    MeJellyPelly

    I am new to Java / Bukkit plugin coding ... and am currently writing code for multiple "things", on a not-yet-live server.

    Basically, the server will have a number of challenges that need various coding to make work - and to reset for future players.

    At the moment, I have .java files for different types of listener, e.g. player actions, block interactions, etc.

    That seemed like a good idea to start with, but now I am not sure!! Would it be better to keep code together based on the "challenge"? So, 10 challenges = 10 classes / .java files.

    For example, there is one called "speed run" and one called "find the block". "Speed run" needs to detect activating a pressure plate, entering a specific region, clicking on a specific block. "find the block" needs to detect clicking a specific block. There are many more challenges with different combinations of interaction checking, etc.

    Would it be better to group all coding into a .java /class file per challenge, or keep it grouped by interaction type (player, block, etc). It seems like a better idea, but is it a problem to be creating a lot more "listener" classes and probably multiple handler events (e.g. for BlockBreakEvent)?

    This plugin is not intended to be installed in parts, nor is it ever intended to be installed on any server not owned by me! (so it's environment is very controlled / known).
     
  2. Offline

    teej107

    @MeJellyPelly It depends on your judgement. Separating code into different packages and classes all boils down to readability and if your code is easy to follow.
     
  3. Offline

    Konato_K

    @MeJellyPelly My suggestion is to separate classes in packages (and subpackages) based on what they do, what do I mean? Instead of putting all listeners in a package called com.example.plugin.listeners you put them in whatever they are going to do like com.example.plugin.minigame1 and com.example.plugin.minigame2, so in this case you will have to make packages (and subpackages) for your challenges, this also adds you the advantage of having the default access modifier working better :D
     
  4. Offline

    MeJellyPelly

    Sorry, what does that mean?
     
  5. Offline

    Konato_K

  6. Offline

    1Rogue Retired Staff

    I would personally not follow that advice.

    If you want an idea, you could take a look at one of my own libraries: https://github.com/CodeLanx/CodelanxLib/tree/master/src/main/java/com/codelanx/codelanxlib

    Essentially, when you look at a project you have components that break into smaller components. You start with your main class: The overall project. This main class will then segment to different managers that define behavior (CommandHandler, ListenerManager, SerializationFactory, etc), and then those have subclasses that define separate objects or data (CommandHandler, for instance, has things such as SubCommand and CommandStatus).

    It helps to sometimes write down what you need to do, and the different things you'll need to accomplish that. Over time you somewhat can move away from that step but it's never hurtful to do.
     
  7. Offline

    MeJellyPelly

    @1Rogue your code looks very complicated! Lots of stuff in there that I don't know about yet!

    I think I am still struggling with the basic division of code ... should it be based on what is happening or being done, such as everything player related together (PlayerInteractEvent, PlayerMoveEvent, etc) or should it be based on division by function, e.g. group by "challenge"?

    When I started, it was clear where code was. Now that the number of challenges are increasing, it is becoming harder to determine where the code for each challenge is. Some of it is similar or actually the same and shared, some is unique per challenge.

    I have coded 3 or 4 challenges so far, I think there will be 10 or so in total. If I split it by challenge, I would need to do 10+ registerEvents - is that OK?

    I think your post described organising by function ... which is kind of what I have now.
     
  8. Offline

    mythbusterma

    @MeJellyPelly

    One of the more common philosophies in writing software for Java is that each class should a small set of well defined responsibilities (often only one). For example, a Listener is only responsible for listening to events and reporting them to something else, or a "TeamManager" or something of that nature may be responsible for keeping track of teams.

    What in the world do you mean by "challenge," I've never heard of anything like that. Each class should have one central responsibility (maybe two). If you need to listen to an event in multiple places to fulfill different tasks, by all means do so.
     
  9. Offline

    Dragonphase

    Read this. I like how yet again nobody has taken notice of this.
     
  10. Offline

    1Rogue Retired Staff

    Well if you have ten different categories of things that need to be listened to that have absolutely nothing to do with each other, then go ahead an separate them into different listeners! You can even make a ListenerManager that tracks all those listener instances and has the responsibility of registering them to Bukkit.

    Using multiple classes in some ways is a division of labor to accomplish a goal. As I was explaining earlier, repeated in a new form of example (I don't have photoshop on me at the moment):

    • Main Class: Responsible for your overall project. This class is the headstone to tackling your goal.
      • Managers: Help to divide the labor into categories. For instance, a CommandManager would be responsible for handling things pertaining to commands. A ListenerManager would be responsible for any listeners in your plugin.
        • Data / Implementation: The concrete methodology behind how your individual managers work

    In a perfect plugin, you could take these separate Managers and completely copy/paste them into a new plugin and have them work 100%. Of course this is somewhat silly to do when building a whole library, as the library as a whole benefits from building off of each other, but it helps to convey the idea of modularity.
     
  11. Offline

    MeJellyPelly

    @mythbusterma Sorry, I thought I kind of mentioned what a "challenge" was ... basically, it is a mini-game. They will be little games / challenges you have to complete before being able to rank up. There will be 10 or so that need programming support (others, like a maze, do not).

    @Dragonphase - when I say I'm new, I mean I haven't worked with Java / Bukkit very much but I do know the basics. I think it's fair to say that my question is not covered by basic "getting started" tutorials. But thanks for the link as I will read over it all again, just to make sure I've not missed anything!

    @1Rogue thanks for the advice - I want to get it right now, before I spend weeks writing the rest of it in a bad way. I will sit back for a bit and look at everything that needs to be done. I am starting to think I wasn't far off, maybe just need to work more on the "Manager" aspect :)
     
  12. Offline

    mythbusterma

    @MeJellyPelly

    If you're creating a plugin that has 10 different minigames, I would suggest each minigame being its own package and contains only classes related to that minigame. Then, have a couple higher level classes that manage those minigames and ranking etc.
     
Thread Status:
Not open for further replies.

Share This Page