- Native Minecraft Version:
- Tested Minecraft Versions:
- Source Code:
I, and mostly any programmers, don't enjoy spending too much time on tedious works such as these:
1. Pretty printing commands and organizing them
2. Various conditions to use the commands
3. Implementing your own tab-complete functionality
4. Save/load or serialize/deserialize
5. Text output change in the config file
7. and so on and so on
This is just a framework to speed up your development by focusing on the actual core functionality of whatever you are trying to create. Minimize the need for detailed implementation such as items I listed above and jump straight into development!
I spend lots of time to simplify the development process, and I ended up with this structure.
The diagram might look intimidating than helpful, but let me explain.
There are mainly three big things to know:
1. The mains
This is just like the class where you `extends JavaPlugin` which means, it's the class where everything starts. No matter what I do, extending JavaPlugin is a must to load the class as a plugin. (Some people use reflection or something, but I like it this way)
Some people call these `modules` instead. Anyway, the manager is nothing but a class to organize your code. However, even though you are free to put whatever you want, my intention for the manager is to fulfill the `Single Responsibility`
What does that mean? If you made a UserManager, I expect functionalities related to User only, not something else. This greatly increases productivity since you can separate different functionalities into different managers. If you can put less code in one place, it becomes more readable, hence your code becomes more efficient and maintainable.
Well, Single Responsibility sounds like a good idea. But imagine you have to communicate with each manager in just one God Class. It will quickly become a mess, then what's the point? So instead, lets put them in another class called `mediator`. These are not modules but to serve as a `middle man` for communication between various classes.
For example, you want to create a Guild Plugin; I assume you will, at least, need a Manager for Guild and a Manager for Member. If you want to make a member join a guild, various checks will be made: is the player in another Guild already? is the Guild reached the maximum capacity? and so on. Probably it's a better idea to implement those logics in a Mediator class, so it can work as a middle man between the Guild manager and the User manager. When a user issues a `join` command, all you need to do is consult with the Mediator class.
And there are other pre-built classes to make your life easier.
Handy class to automatically store instances, serialize/deserialize to/from JSON, and save/load files. You have to use only the native types(String, int, double, you know) in the data class in order for the serialization to work properly, or add your own serializer if you want a more complex structure.
Pre-built manager to handle translation support. In any Manager or Mediator, access it by `main().lang()`
And more... (but not well documented. What a shame)
This was not intended for others to use, so it's not well documented. But you can still give a try if you hate boilerplate codes. I just couldn't stand copy and pasting the same codes again and again whenever developing new plugins. And if you have better ideas, help me to improve the framework.
You can use the template here: https://github.com/wysohn/PluginTemplate
Though, you may need to edit gradle.build since GitHub repository seems to be working only for the repository owner. I can upload it to some public repository if you specifically insist (P.M me in that case)