Programming Principles

Programming Principles

SOLID

Single Responsibility Principle

Nach dem Single Responsibility Principle soll eine Klasse nicht zu viele Verantwortlichkeiten aufweisen.

In unserem Programmentwurf wurde das Single Responsibility Principle in Commit Configuration Commit in der Klasse Configuration umgesetzt.

Jede Klasse der Configuration Architektur hat eine oder höchstens 2 Funktionen.

Klasse Configuration

Das Klassenkonstrukt um Configuration ist in mehrere Subklassen aufgebaut, die alle einzelne Aufgaben übernehmen.

Die Klasse Configuration hat die Aufgabe die Konfiguration bereitzustellen, sie implementiert die Schnittstelle zu anderen Programmteilen an über die Plugin Schnittstelle des Kerns. Dies macht sie indem sie das Interface "IConfiguration" implementiert.

Die Aufgabenteilung durch das Single Responsibility Prinzip wird dadurch erreicht, dass Funktionalitäten wie das Speichern der Configuration auf dem Dateisystem und das Laden der jeweiligen Konfiguration in einzelne Klassen ausgelagert wurden. Ebenso wurde die Datenhaltung der Konfiguration in einem Baum in einer extra Klassenstruktur ausgelagert.

class Configuration{}

classDiagram

Configuration --> "1" ConfigMap
Configuration --> "1" ConfigurationSerializer
Configuration --> "1" ConfigurationDeserializer
Configuration ..> IConfiguration : implements
Configuration ..> IPlugin : implements
ConfigMap --> "0..n" ConfigKey
ConfigMap --|> ConfigTree
ConfigKey --|> ConfigTree

class ConfigTree{
    +member
}

class Configuration{  
    +configPath:File
}

class IConfiguration{
    <<interface>>
    +getConfiguration()
    +setConfigKey(key:String, value:String)
    +getConfigKey()
}

class ConfigMap{
    +member
}

class ConfigTree{
    +member
}

Loading

Open-Closed Principle

Nach dem Open-Closed Prinziple

function test()

Liskov Substitution Principle

Interface Segregation Principle

Die im Abschnitt "[Dekorierer Pattern](#Dekorierer Pattern)" beschriebenen Klassen SadQueueingBlockUpdater und SadChunkedBlockUpdater implementieren beide das BlockUpdater Interface. Beide besitzen jedoch noch eine weitere Schnittstelle, da auf Minecraft-Ticks beziehungsweise Chunk Load Events reagiert werden muss. Wären die entsprechenden Methoden im BlockUpdater Interface deklariert, würde das Dekorierer Pattern so nicht mehr funktionieren, da jede Implementierungen auf Ticks und Chunk Loads reagieren müsste. Stattdessen sind diese Methoden daher in eigenen Interfaces namens RedstoneTickListener und ChunkLoadListener deklariert. So kann der aufrufende Code (SadMinecraftEventUnpacker) mit dem jeweils benötigten Interface arbeiten und hat keine unnötig starke Kopplung an andere involiverte Mechaniken wie BlockUpdates.