- Remove permission logic on command side; make PermissionsManager handle checks for all CommandSender objects (not only Player), cf. #314
- Remove unnecessary redundancies in passed arguments ("command references" that can be inferred from the FoundResult)
- Extend FoundCommandResult to represent all possible error cases
* this class only contains wrapper of selected datasource type which every method included a code to run the task inside a new Thread. But this class doesn't help improving performance, because it's still running the task synchronously.
- Reduce tight coupling by passing list of available commands as param to CommandHandler
- Split command processing method into several smaller ones
- Remove unfinished logic for unlimited command arguments (reason: was not implemented and not used, probably needs another way to handle it once the need for it arises)
- Create test for CommandHandler
- Abstract Messages into two layers: the top layer 'Messages' is how Messages can be retrieved and sent as before. In the background, package-private, MessagesManager actually does the file read and worries about I/O while Messages takes care of higher-level things (such as joining two lines or checking the current language).
- Create Initializer class that only initializes AuthMe commands
- Move remaining method to CommandHandler
- Deprecate constructors on CommandDescription in favor of the builder
- Various cleanups and comments
- Add BufferedReader instantiation into try-with-resources statement
- Close scanner that was opened
- Create utility class to format a caught exception
Had to create a getGameServer() method in AuthMe in order to be able to catch this call in tests and replace it with a mock implementation of the actual server. The supertype method getServer() is declared as final, which makes it impossible to mock with Mockito.
While there are frameworks that manipulate the bytecode to mock final calls, it is much easier and less risky to simply delegate the server retrieval through another method.
Had to create a getter for the Management instance in the AuthMe class for mocking, but fields should generally not be accessed globally. Hopefully soon we will be able to make the field private.
Ideally JavaDoc should provide additional information to the developer
as to the method's purpose and usage. Typically you do not add the
return type of the method and the parameter's types since this can be
seen in the code.
A short description of what the parameter really is (e.g. a String can
hold many types of information) is a lot more beneficial. A JavaDoc
statement simply restating the parameter types and the method name is,
put bluntly, simply noise, since all of these things are already
contained in the code itself.
Similarly, @see references are great for pointing to other, related
methods but aren't very helpful to point to a superclass method (the
implemented or overriden method) since it is implied by @Override. A
developer can navigate easily to the superclass method with any
reasonable IDE.
