Willkommen zu meiner zweiten Client Analyse!
Dieses mal werden wir uns mit dem Client Ultima beschäftigen.
In der Hauptklasse des Clients können wir direkt sehen, dass auch der Entwickler dieses Clients nicht viel von Naming Conventions zu halten scheint. Außerdem scheint er entweder nicht viel über Java zu wissen, oder einen Hang dazu zu haben, alles viel zu kompliziert zu machen.
Zum Beispiel diese Stelle in der startup Methode:
Hätte man durch:
ersetzen können. Mal davon abgesehen frage ich mich, wieso er eine eigene Logger Klasse in seinem utils Package hat, wenn alle Ausgaben mit System.out.println() erfolgen.
An statt zwei Konstruktoren zu erstellen und in jedem die Variablen zuzuweisen hatte man im zweiten Konstruktor den ersten aufrufen und alle Argumente sowie einen default Wert für visible an ihn weitergeben können. Mal davon abgesehen hätte man stattdessen eine Annotation verwenden können, mit der man alle Klassen, die von Module erben markiert, von welcher man dann die Werte im Standard Konstruktor der Superklasse ausließt. Dies wäre die bessere Lösung, da man in Annotations default Werte festlegen kann und dies somit nicht in der Klasse tun muss.
In der ModuleManager Klasse sehen wir mal wieder einen Beweis für die Inkompetenz des Entwicklers.
Er hätte hier, anstatt manuell eine Instanz von jedem Module zu erstellen, entweder wie Latematt, nuf, die meisten anderen Leute aus dieser "Szene" und so ziemlich alle "Skids" die die Reflections Library benutzen können um in einer Schleife alle Klassen in dem Package "modules" durchgehen und dynamisch zu der Liste hinzuzufügen, oder er hätte die Chance seine Intelligenz unter Beweis zu stellen nutzen, und das selbe mit der ClassPath Klasse aus der Google Guava Library (die anders als die Relfections Library bereits in Minecraft mit inbegriffen ist) tun können. Beides hat er nicht getan, wie bereits in der Module Klasse zu sehen ist, scheint der Begriff Redundanz ihm ein Fremdwort zu sein.
Dieses mal werden wir uns mit dem Client Ultima beschäftigen.
In der Hauptklasse des Clients können wir direkt sehen, dass auch der Entwickler dieses Clients nicht viel von Naming Conventions zu halten scheint. Außerdem scheint er entweder nicht viel über Java zu wissen, oder einen Hang dazu zu haben, alles viel zu kompliziert zu machen.
Zum Beispiel diese Stelle in der startup Methode:
Code:
if (!Ultima.directory.exists()) {
if (Ultima.directory.mkdir()) {
System.out.println("Directory is created!");
}
else {
System.out.println("Failed to create directory!");
}
}
Code:
if ( !( Ultima.directory.exists() ) ) {
System.out.println( Ultima.directory.mkdir() ? "Directory is created!" : "Failed to create directory!" );
}An statt zwei Konstruktoren zu erstellen und in jedem die Variablen zuzuweisen hatte man im zweiten Konstruktor den ersten aufrufen und alle Argumente sowie einen default Wert für visible an ihn weitergeben können. Mal davon abgesehen hätte man stattdessen eine Annotation verwenden können, mit der man alle Klassen, die von Module erben markiert, von welcher man dann die Werte im Standard Konstruktor der Superklasse ausließt. Dies wäre die bessere Lösung, da man in Annotations default Werte festlegen kann und dies somit nicht in der Klasse tun muss.
In der ModuleManager Klasse sehen wir mal wieder einen Beweis für die Inkompetenz des Entwicklers.
Er hätte hier, anstatt manuell eine Instanz von jedem Module zu erstellen, entweder wie Latematt, nuf, die meisten anderen Leute aus dieser "Szene" und so ziemlich alle "Skids" die die Reflections Library benutzen können um in einer Schleife alle Klassen in dem Package "modules" durchgehen und dynamisch zu der Liste hinzuzufügen, oder er hätte die Chance seine Intelligenz unter Beweis zu stellen nutzen, und das selbe mit der ClassPath Klasse aus der Google Guava Library (die anders als die Relfections Library bereits in Minecraft mit inbegriffen ist) tun können. Beides hat er nicht getan, wie bereits in der Module Klasse zu sehen ist, scheint der Begriff Redundanz ihm ein Fremdwort zu sein.
