CoinsAPI (File & MySQL) | 1.7.X - 1.13.X

Zitat von DevCyntrix

Nette API, jedoch würde ich vorschlagen eine Vault Implementation und asynchrone Methoden einbringen.

Vielen Dank für dein Feedback.

Ich werde tun was ich kann.

Hey,

Also wie soll ich anfangen, es ist cool das ihr Plugins kostenfrei zur Verfügung stellt. Wäre dort nicht ein Haken, ihr seid eigentlich verpflichtet euch an die Java Conventions zu halten, was ihr eben überhaupt nicht tut, schon alleine die Package Benennung ist vollkommen falsch "net.LegitPlugins.CoinsAPI" die Packages werden immer klein geschrieben. Das nächste Problem ist die Hauptklasse, die ihr wenn ihr Spigot Plugins programmiert auf keinen Fall "Main" nennen dürft, denn die Klasse "Main" gibt es bereits in Spigot und es ist verboten 2 Klassen mit dem selben Namen zu haben. Das nächste wäre die allgemeine Klassenbenennung, "CMD_Pay" ist halt falsch Klassen werden in kompletten Wörtern ausgeschrieben ohne "_", das bedeuted "PayCommand", wäre die richtige Benennung. Java ist eine Objektorientierte Programmiersprache, das versaut ihr indem ihr alles "public static" macht. Zu guter letzt gehe ich davon aus, dass dieses Plugin niemals einen "professionellen" Gebrauch finden wird, da der Code auch einfach nicht performant ist, es werden Live MySQL Updates gemacht, es wird nichts asynchron ausgeführt und von Caching habt ihr anscheinend auch noch nie was gehört.

Fazit: Bevor ihr Plugins zum kostenfreien Download anbietet, überlegt euch was ihr da programmiert, denn diese CoinsAPI ist aus Entwicklungstechnischer Sicht einfach Abfall.

Zitat von SeiCool

Hey,

Also wie soll ich anfangen, es ist cool das ihr Plugins kostenfrei zur Verfügung stellt. Wäre dort nicht ein Haken, ihr seid eigentlich verpflichtet euch an die Java Conventions zu halten, was ihr eben überhaupt nicht tut, schon alleine die Package Benennung ist vollkommen falsch "net.LegitPlugins.CoinsAPI" die Packages werden immer klein geschrieben. Das nächste Problem ist die Hauptklasse, die ihr wenn ihr Spigot Plugins programmiert auf keinen Fall "Main" nennen dürft, denn die Klasse "Main" gibt es bereits in Spigot und es ist verboten 2 Klassen mit dem selben Namen zu haben. Das nächste wäre die allgemeine Klassenbenennung, "CMD_Pay" ist halt falsch Klassen werden in kompletten Wörtern ausgeschrieben ohne "_", das bedeuted "PayCommand", wäre die richtige Benennung. Java ist eine Objektorientierte Programmiersprache, das versaut ihr indem ihr alles "public static" macht. Zu guter letzt gehe ich davon aus, dass dieses Plugin niemals einen "professionellen" Gebrauch finden wird, da der Code auch einfach nicht performant ist, es werden Live MySQL Updates gemacht, es wird nichts asynchron ausgeführt und von Caching habt ihr anscheinend auch noch nie was gehört.

Fazit: Bevor ihr Plugins zum kostenfreien Download anbietet, überlegt euch was ihr da programmiert, denn diese CoinsAPI ist aus Entwicklungstechnischer Sicht einfach Abfall.

Absoluter Bullshit.

Man darf die Class auch Main nennen. Wieso sonst wird es überall so vorgestellt und auch programmiert? Außerdem wird es immer Classes mit dem gleichen Namen geben.

In einigen Punkten gebe ich dir zwar Recht, aber nicht bei dem Bullshit mit den Classnamen. Außerdem ist man nicht verpflichtet sich an die Java Conventions zu halten.

Zitat von NullGehirnzellen

Absoluter Bullshit.

Man darf die Class auch Main nennen. Wieso sonst wird es überall so vorgestellt und auch programmiert? Außerdem wird es immer Classes mit dem gleichen Namen geben.

In einigen Punkten gebe ich dir zwar Recht, aber nicht bei dem Bullshit mit den Classnamen. Außerdem ist man nicht verpflichtet sich an die Java Conventions zu halten.

Ich mache mir für diesen BS jetzt extra ein Account hier.

Nur, weil jemand im Internet etwas so vorstellt, heißt das nicht, das du es so machen sollst.

Du hast ein großes Problem und möchtest es beenden. Du leist im Internet darüber das du aus dem Fenster springen kannst. Es würde vll. deine Schmerzen nehmen aber ist es die richtige Lösung? Nein. (Mods pls don't ban me ich habe nicht dazu aufgefordert!)

Es ist Bullshit das man nicht zwei Klassen mit demselben Namen haben darf, ja aber sonst würde ich sagen sind alle anderen aussagen relativ verständlich.

Minecraft hat eine Main und Craftbukkit hat eine. (Ist nur eins der Beispiele).

Ich schreibe einen Minecraft Client welcher in vielen Versionen unterstützt wird und mache deswegen einen abstrakten Layer um die Minecraft internen Funktionen herum. In der Common, dem Projekt mit dem Versionsunabhängigen Code, gibt es ein Interface namens "Minecraft". In der Implementationsklasse Namens: VirtualMinecraft(Unsere Implementationen haben eig. immer den Präfix Virtual) und diese Implementiert dieses Interface, haust aber auch eine Variable zu net.minecraft.client.Minecraft.

Ich konnte auch in den Java Conventions nichts darüber finden. Er hat aber damit recht, dass man seine Pluginhauptklasse nicht Main nennen sollte. Hier ist warum:

Main oder auch oft Bootstrap ist meistens dafür da die Startklasse des Systems bekannt zu geben. Diese Verarbeitet oft wichtige Informationen aus den Argumenten und gibt den Start Befehl an eine Sub-Klasse(in Minecraft z.b net.minecraft.client.Minecraft) weiter welche dann alle Befehle ausführt.

Warum ist jetzt Main in Plugins falsch?

Vor allem bei APIs ist es schlimm. Wenn jemand auch eine Klasse namens "Main" hat und dein Plugin importiert kann es oft zu Import Fehlern kommen. Die Klasse sollte viel eher "CoinsAPIPlugin" oder so in der Art heißen. Warum?

Lass es aufteilen in 2 Teile:

CoinsAPI <- Dein Plugin Name. Wir nehmen wieder das Beispiel net.minecraft.client.Minecraft. Deine Main ist in diesem Fall der Bukkit Classloader und nicht deine "Main". Die "CoinsAPIPlugin" ist deine Sub-Klasse welche alle Befehle Ausführt

Plugin <- In einem der nächsten Parts beschreibe ich Interfaces deswegen gehen wir hier jetzt davon aus das du ein Interface CoinsAPI hast welches natürlich nicht mit deinem Pluginnamen zu Import fehlen führen sollte. Deswegen ist es Empfehlenswert das Plugin am Ende oder Davor anzugeben um zu definieren das es sich hierbei um das Plugin und nicht die API handelt.

Java Conventions. Warum einhalten, wenn es ohne geht?

Also bei einer API ist das ganz schlimm. Einige IDEs und Compiler nehmen deine API nicht an. Die Leute können damit kein Plugin schreiben. Der Unterstrich ist für manche Compiler und IDEs verboten oder gibt etwas an was nicht so definiert sein sollte.

Genauso ist es mit großgeschrieben Package Namen. Diese können auch falsch interpretiert werden.

Außerdem sind die Java Conventions dafür gedacht das Coden für jeden Developer einfach zu machen da jede API mit der er arbeitet dieselbe Struktur haben soll und somit einfach zu verstehen ist.

Interfaces

Du hast zwei Klassen. CoinsAPI_File und CoinsAPI_MySQL. Du könntest ein Interface machen welches CoinsAPI heißt. Mit z.b einem Static Getter kannst du dieses Interface in deiner Hauptklasse weitergeben. z.b CoinsAPIPlugin.getCoinsProvider() oder CoinsAPIPlugin.getCoinsAPI()

In der Config Datei kannst du dann einfach abfragen ob man File oder MySQL möchte. Beim Aktivieren deines Plugins fragst du das dann ab und definierst diese Static Variable dann mit Implementationen.

Das Interface sollte alle Methoden enthalten, welche in beiden Varianten zur verfügung stehen. Also setCoins, getCoins, AddCoins, createPlayer usw... Die Implementationen implementieren diese Methoden dann und geben dieser Funktionalität. Somit kümmerst du dich um die Variante nicht der Nutzer deiner API. So kannst du auch schnell neue Implementationen wie MongoDB, SQLite oder andere hinzufügen.

Code Style generell

Du kannst statt:

if(sender instanceof Player) {
   if(player.hasPermission("stuff") {
       //To Stuff
  }
}

auch das machen:

if(!(sender instanceof Player) || !sender.hasPermission("stuff")) {
    return false;
}
//To Stuff 

"Zu guter letzt gehe ich davon aus, dass dieses Plugin niemals einen "professionellen" Gebrauch finden wird, da der Code auch einfach nicht performant ist, es werden Live MySQL Updates gemacht, es wird nichts asynchron ausgeführt und von Caching habt ihr anscheinend auch noch nie was gehört."

Dieses Statement von SeiCool finde ich nicht ganz korrekt. Ich habe schon lange aufgehört solche Sachen direkt in der API zu Cachen. Man muss nicht alles immer direkt gecached haben. Wenn das Plugin, welches die API benutzt, eine Aufgabe oft ausführt sollte dieses einfach das Caching ausführen und diesen Cache auch regelmäßig auffrischen. Cachen ist nicht immer die Lösung.

Asynchrones Programmieren auch nicht. Die API sollte Synchron laufen können aber auch Asynchron(Threadsafe) laufen können. Das Plugin, welches darauf zugreift, ist verantwortlich die Operation über einen ExecutorService oder ähnliches auszuführen. Damals habe ich direkt mit Consumern der Daten gearbeitet und direkt alles Asynchron ausführen lassen. Aber glaub mir das ist ein Horror. Ewig viele Consumer bei vielen Daten... Wenn das Plugin einen Service an den ExecutorService abgibt und dort einfach alles ausführt ist das so viel schöner und tatsächlich auch performanter was Memory Usage angeht(Ein Consumer statt viele mehr). Kein großer Impact aber immer noch etwas. Ich benutzte lange kein MySQL mehr aber normalerweise sollten Live Updates kein Problem sein, oder? Wann sollen sie sonst ausgeführt werden? Wenn man ein Bungeecord Netzwerk hat sollten die Daten am aktuellsten sein. Und zwar überall. Sie werden so oder so irgendwann ausgeführt also was solls. ¯\_(ツ)_/¯

Das Plugin ist definitiv ausbaufähig. Kritik ist wichtig also nimm das nicht als Hass gegen dein Plugin. Aber derzeit ist das Plugin einfach zu unfertig um auf den Markt zu sein. Und ich hab, dir denke ich erklärt warum

MFG

Zitat von MenschenToaster

Das Plugin ist definitiv ausbaufähig. Kritik ist wichtig also nimm das nicht als Hass gegen dein Plugin. Aber derzeit ist das Plugin einfach zu unfertig um auf den Markt zu sein. Und ich hab, dir denke ich erklärt warum

Bei dem Punkt mit der Ausbaufähigkeit gebe ich dir auch Recht, allerdings muss man auch bedenken, dass das Plugin kostenlos zum Download frei steht und man von einem kostenlosen Plugin keine Meisterarbeit erwarten sollte.

Zitat von MenschenToaster

Nur, weil jemand im Internet etwas so vorstellt, heißt das nicht, das du es so machen sollst.

Da ich selbst noch kein erfahrener Developer bin kenne ich es nur so.

Dann tut es mir Leid, falls ich falsch lag.

Zitat von MenschenToaster

Vor allem bei APIs ist es schlimm. Wenn jemand auch eine Klasse namens "Main" hat und dein Plugin importiert kann es oft zu Import Fehlern kommen. Die Klasse sollte viel eher "CoinsAPIPlugin" oder so in der Art heißen.

Soweit ich weiß sind alle API-bezogenen Methoden etc. in anderen Klassen abgespeichert.

CoinsAPI_File und CoinsAPI_MySQL sollten es sein.

Zitat von NullGehirnzellen

Soweit ich weiß sind alle API-bezogenen Methoden etc. in anderen Klassen abgespeichert.

CoinsAPI_File und CoinsAPI_MySQL sollten es sein.

Wenn man die API importiert wird die Main Trotzdem vorhanden sein.

Zitat von NullGehirnzellen

Bei dem Punkt mit der Ausbaufähigkeit gebe ich dir auch Recht, allerdings muss man auch bedenken, dass das Plugin kostenlos zum Download frei steht und man von einem kostenlosen Plugin keine Meisterarbeit erwarten sollte.

Fawe, Luckperms usw. sind auch kostenlos. Die Qualität hat nicht viel damit zu Tun, ob ein Plugin Kostenlos ist oder nicht. Oft sind kostenpflichtige Plugins sogar schlechter. Aber du sendest hier ein Plugin in die Welt, welches andere Plugins nutzen sollen. Wenn man nur für sein eigenes Netzwerk Coded macht man sein eigenes. Wenn also viele Leute dieses Plugin nutzen und es so "schlecht" strukturiert ist, nimmst du diesen Plugins schon fast die Zukunft.

Am Anfang sollte man die Plugins eher für sich Entwickeln und/oder vll. Öffentlich nach Meinung fragen und nicht direkt darauf Losschießen ^^(Ich wüsste hier jedenfalls nicht, das hier steht: "Das Plugin ist nicht Fertig aber hier ist der SRC könnt ihr mir mal eure Meinung sagen" oder sowas in der Art yk)

MFG

Zitat von MenschenToaster

Am Anfang sollte man die Plugins eher für sich Entwickeln und/oder vll. Öffentlich nach Meinung fragen und nicht direkt darauf Losschießen ^^(Ich wüsste hier jedenfalls nicht, das hier steht: "Das Plugin ist nicht Fertig aber hier ist der SRC könnt ihr mir mal eure Meinung sagen" oder sowas in der Art yk)

Wir sind immer für Vorschläge und Tipps offen.

Das Plugin habe auch außerdem vor langer Zeit programmiert.

Updates und Fixes werden noch kommen.