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

Durch das 'IPlugin' Interface im Kernteil unserer Anwendung wird das Open-Closed Principle umgesetzt. Da das 'IPlugin' Interface die load Methode bereitstellt, die von jedem Kernplugin implementiert wird. Durch die Implementierung der Load Methode in jedem Kernplugin, wird sichergestellt dass jedes Plugin seine eigene Initialisierung durchführen kann, ohne dass bestehender Code der 'Loader' oder 'Core' Klasse verändert wird.

package pluginmanager;


public interface IPlugin {

    void load(ICore core);

    void unload();

    void receiveNotification(String message);

    String getName();

}

Wird die Load Methode aufgerufen initialisiert sich jedes Kernplugin selbst mit einer angepassten Loadmethode.

Liskov Substitution Principle

In der ConfigurationKlassenhierachie, die bereits in Klasse Configuration beschrieben wurde wird das Liskovo Substituion Principle umgesetzt. Der Commit in der das Liskov Substitution Principle umgesetzt wurde ist der gleiche wie der Commit in dem das Single

Die Klassen ConfigMap und ConfigKey erben von der Klasse ConfigTree. Die einzelnen Klassen haben dabei folgende Funktion.

1. Basisklasse ConfigTree: Die abstrakte Klasse ConfigTree stellt die Basisklasse dar. Sie definiert eine gemeinsame Schnittstelle für verschiedene Arten von Konfigurationsknoten.

2. Abgeleitete Klasse ConfigMap: Die Klasse ConfigMap erweitert die Basisklasse ConfigTree. Sie fügt eine spezifische Implementierung hinzu, um eine Konfigurationsstruktur als Map von Schlüssel-Wert-Paaren darzustellen. Sie stellt die Methode getConfigSubmap bereit, um eine Teilmenge der Konfigurationsmap als neue ConfigMap abzurufen, und die Methode getConfigKey, um einen spezifischen Konfigurationsschlüssel als ConfigKey abzurufen.

3. Abgeleitete Klasse ConfigKey: Die Klasse ConfigKey erweitert ebenfalls die Basisklasse ConfigTree. Sie repräsentiert einen einzelnen Konfigurationsschlüssel mit einem Wert.

Zusammenfassend lässt sich sagen, dass das gezeigte Codebeispiel das Liskov-Substitutionsprinzip einhält, da die abgeleiteten Klassen die Verträge der Basisklasse einhalten und deren Funktionen erweitern, ohne das erwartete Verhalten zu ändern.