Closed johnbanq closed 4 years ago
note: the previous one was closed because I forgot to set it as a draft
@lukeeey Here is the codebase that encapsulated the cloudburst.yml and with my facade idea applied.
Is the design of the facade class (ServerConfig.class) acceptable?
How the sub-config classes are created is temporary. I think it is more important to get the API right at first, and we can work on details like this later
Further TODO:
since pulling all that string-based property access all into one place is more important than bikeshedding the detail of the encapsulated API, I think this PR is ready to merge. The TODO items above, if found acceptable by the owner, will be the goal of another PR
I think this PR is complete by now, please review so we can get this into mainline ASAP :)
Oof, i forgot to click send on my review
Goal: migrate properties and server configuration access logic out of Server class, to reduce its length and API surface, hence make the dev's life easier(?)
I would also like to propose a more explicit API to simplify property access.
Status: here is the proposed encapsulation scheme to server.properties all usage inside the Server class has been replaced, waiting for opinions on API style and design from the devs before further replacing all usage in the project and do the same to nukkit.yaml
Further idea: I think we should provide a facade class, perhaps named ServerConfiguration to move all the getIp() style getter out of the Server class?