Archive for the 'Software Design' Category

Page 2 of 2

jPatchLib 0.0.1b

So, hier ist die nächste Version von jPatchLib: 0.0.1b.

Die Probleme mit den Leerzeilen sollten jetzt erledigt sein und ich habe die Dokumentation hinzugefügt: JavaDoc.

Mehr Infos. Weitere Projekte.

Patch Library für Java – jPatchLib

Nachdem ich lange vergeblich versucht habe eine Implementation von GNU Patch für Java zu finden bin ich zu dem Schluss gekommen, dass es wohl einfacher ist eine selbst zu schreiben.

Das Ergebniss findet sich unter http://developer.gauner.org/jpatchlib/.

Ein paar Sachen stehen noch auf meiner ToDo Liste, aber für einen ersten Eindruck sollte es reichen.

Was noch aussteht:

- Dokumentation

- Probleme mit Leerzeilen beheben

Ansonsten natürlich viel Spaß damit.

Patch Library für Java?

Es gibt zwar ein paar Implementierungen von diff für Java, aber eine patch Implementierung konnte ich nicht finden.

Sollte ich doch noch fündig werden, werde ich darüber berichten.

Eclipse: Dummer Update-Manager

Warum ist der Update-Manager von Eclipse eigentlich so blöd?

Kaum habe ich Eclipse nach der Installation der neusten Updates neu gestartet, fängt er wieder von Vorne an und will neue Updates installieren. Kann der das nicht auf einmal?

Ausserdem frage ich mich auch warum der nach jedem Start ewig braucht bis er die Updates gefunden hat? Da liese sich einiges verbessern …

Essence of Software Design (Java)

Ich habe mir vor einiger Zeit einige wichtige Design-Prinzipien für das Software Design, insb. in Java, zusammengefasst und einige oft gebrauchte Design-Patterns und Entwurfsrichlinien erläutert.

Zu finden ist das ganze unter The Essence of Software Design.

Die wichtigsten Prinzipien:

  • Open-Closed-Principle (OCP) – A class should be open for extension but closed for modification.
  • Liskov Substitution Principle (LSP) – An instance of a class should function as an instance of its superclass.
  • Dependency Inversion Principle (DIP) – High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.
    DO NOT DEPEND ON A CONCRETE CLASS.
    All relationsships in a program should terminate on an abstract class or an interface.

Singleton in D

Das ist wohl der erste “self containing singleton” (so habe ich ihn getauft) in D:

 8:    /// Singleton instance.
 9:    private static SceneManager singleton;
10:
11:    /// No public need for this.
12:    private static this() {
13:        singleton = new SceneManager();
14:    }
15:
16:    /// Get signleton instance.
17:    public static SceneManager opCall() {
18:        if(singleton == null)
19:            singleton = new SceneManager();
20:        return singleton;
21:    }

z.B.:

SceneManager().registerScene(new DebugScene());
SceneManager().registerScene(new StarfieldScene());