Open TheMolkaPL opened 9 years ago
Hmm, zastanawiałem się nad tą modułowością i myślę, że można by to rzeczywiście rozbić na oddzielne moduły.Co do WorldEdit API to wolałbym jednak spróbować samemu to ogarnąć a z Apache Commons to widzę, że ma tam ogarnięte zarządzanie plikami, więc przyda się na pewno. Z forgem to będę się później bawił. A co myślisz nad sposobem modyfikacji klas, które mają być ewentualnie modyfikowane przy wykorzystywaniu API danego typu serwera? Bo jak na razie mam klasę uniwersalną, która ma pewien szkielet i w razie potrzeby zostaje tworzona nowa klasa wraz ze zmodyfikowanymi metodami czy typami zmiennych. Ogólnie chciałbym zrobić ten projekt jak najbardziej wzorowy wedle pewnych standardów a nie tak losowo. Widziałem w WorldEdit, że tam implementują coś i potem @overidde dane metody. Więc nie wiem czy tak jak chcę robić będzie dobrą praktyką.
Ja bym zrobił tak jak w Bukkit API. Klasa UniGuild
(jak Bukkit
) gdzie jest metoda ustawienia implementacji interface'u IUniGuild
(jak Server
). IUniGuild
posiadałby wszystkie metody kierujące do managerów różnych kategorii (światy, gracze, scheduler, itd.). UniGuild
posiadałby jeszcze metodę getInstance()
zwracającą IUniGuild
. Ewentualnie jeszcze kopia metod z IUniGuild
, tak jak jest to w Bukkicie w klasie Bukkit
.
Poczytam sobie o interfejsach jak je jakoś praktycznie wykorzystać. Albo poczytam jakieś mądre książki xd
Przykładowy interface w API. Interface oznacza abstrakcyjną klasę w której wszystkie metody są abstrakcyjne.
package pl.grzegorz2047.uniguild;
// importy
public interface IUniGuild {
Player findPlayer(String query);
Player getPlayer(String username);
Player getPlayer(UUID id);
}
Implementacja w Bukkit.
package pl.grzegorz2047.uniguild.bukkit.impl;
// importy
public class BukkitUniGuild implements IUniGuild {
@Override
public Player findPlayer(String query) {
// kod
}
@Override
public Player getPlayer(String username) {
// kod
}
@Override
public Player getPlayer(UUID id) {
// kod
}
}
Rozumiem, czyli ten interfejs to taki template. Dzisiaj coś pokombinuję.
Chociaż, aby nie kopiować masy kodu pomiędzy platformami (silnikami), można by stworzyć implementację interface'ów (które są w API) w module uniguild-core
, przykładowo w package pl.grzegorz2047.uniguild.impl
, który nie byłby częścią API, a używanie tych metod z spoza tego pluginu nie powinno mieć miejsca (użycie na własną odpowiedzialność). Przykładowo IUniGuild
posiadałby implementację UniGuildImpl
. Klasa implementująca byłaby abstrakcyjna, dzięki czemu nadpisywałaby (@Override
) tylko niektóre metody. Byłoby to przykładowo zarządzanie graczami (pobieranych obecnie na serwerze). W tej klasie potrzebne są także metody dodawania/usuwania gracza do/z pamięci. Aby tego użyć trzeba IUniGuild
castować do tej właśnie klasy (używanie tylko na swoją odpowiedzialność poza pluginem).
Klasa modułu Bukkit (BukkitUniGuild
) byłaby rozszerzeniem UniGuildImpl
i implementowałaby resztę metod.
Mhm. To tak sobie myślę nad stworzeniem jakiegoś prostego pluginu, który mógłby wykorzystywać tę koncepcję xd I potem zabiorę się za ten bardziej złożony
Spróbuję zaimplementować to na tym przykładzie: https://github.com/grzegorz2047/UniPlayerChannels/blob/master/README.md
@TheMolkaPL Kiedy będziesz dostępny? Bo chciałbym porozmawiać.
@grzegorz2047 jakoś po południu
@TheMolkaPL okej na twoim tym tsie shootgame?
Okej! Czekam
Wbijesz?
Maven supports modules. Every module works as a new Java project. An example of modules in this project.
uniguild-core - the core of this plugin contains the API and main functionality. The dependencies can be Apache Commons and WorldEdit API from #1.
uniguild-bukkit - implementation of the uniguild-core for the Bukkit (and forks) server. Bukkit must be a dependency.
uniguild-forge - implementation of the uniguild-core for the Forge server. Forge must be a dependency.
uniguild-sponge - implementation of the uniguild-core for the Sponge server. Sponge and uniguild-forge must be a dependency.