-
Notifications
You must be signed in to change notification settings - Fork 0
Programming Principles
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.
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.
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
}
Durch das IPlugin Interface im Loader Programmteil unserer Anwendung wird das Open-Closed Principle umgesetzt.
Die Schnittstellendefinitionen sind jedoch zum aktuellen Punkt noch nicht final, es müssen noch Anpassungen durchgeführt werden um den endgültigen Designvorstellungen gerecht zu werden. Deswegen wird das Interface Segregation Principle noch nicht zur vollen Zufriedenheit umgesetzt. (Trennung von Notifications und Load Funktionalität im erwähnten Commit: PluginLoader Commit)
Das IPlugin Interface stellt die load Methode bereit, die von jedem Kernplugin implementiert werden muss. (Beispiel für Plugin: ServletPlugin) 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.
So können verschiedene Plugins dynamisch vom Kern oder einem externen Loader geladen und an den Kern angedockt werden.
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.
Der Loader ruft von jedem Plugin, das sich im passenden Java Package befindet nach der Objekterstellung die Load Methode auf um das Plugin zu initialisieren.
In der Configuration Klassenhierachie, die bereits in Klasse Configuration beschrieben wurde, wird das Liskov Substituion Principle umgesetzt. Der Commit in der das Liskov Substitution Principle umgesetzt wurde ist der gleiche wie der Commit in dem das Single Responsibility Principle umgesetzt wurde: Configuration Commit
Die Klassen ConfigMap und ConfigKey erben von der Klasse ConfigTree. Die einzelnen Klassen haben dabei folgende Funktion.
-
Basisklasse ConfigTree: Die abstrakte Klasse ConfigTree stellt die Basisklasse dar. Sie definiert eine gemeinsame Schnittstelle für verschiedene Arten von Konfigurationsknoten.
-
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.
-
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.
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 involvierte Mechaniken wie BlockUpdates.
Das Dependency Inversion Principle wird im Kernteil des Porgammes durch die Verwendung von Interfaces durchgesetzt.
Desweiteren wird das Inversion of Control (IoC) Muster verwendet.
Anstatt Abhängigkeiten zu Implementierungen einer Klasse zu haben, hat die Klasse Core nur Abhängigkeiten zu abstrakten Schnittstellen um das Dependency Inversion Principle umzusetzen.
Die Klasse Core hat beispielsweise eine Abhängigkeit von der abstrakten Schnittstelle IConfiguration. Statt direkt eine konkrete Implementierung von einer Klasse zu instanziieren, die die Funktionalität von IConfiguration aufweist, wird die konkrete Implementierung über den Konstruktor als Abhängigkeit übergeben. Dadurch hängt Core nicht von einer spezifischen Implementierung ab, sondern nur von der abstrakten Schnittstelle. Die Klasse Core hat auch eine Abhängigkeit von der abstrakten Schnittstelle IPluginFactory. Auch hier wird die konkrete Implementierung über den Konstruktor als Abhängigkeit übergeben, anstatt direkt eine spezifische Implementierung zu instanziieren. Die Klasse Core hat ebenfalls Abhängigkeiten von den abstrakten Schnittstellen IPublisher und IReceiver. Auch hier werden die konkreten Implementierungen über den Konstruktor als Abhängigkeiten übergeben. Diese 2 Klassen werden jedoch zukünftig in Plugins ausgelagert.
Die Abhängigkeit von abstrakten Schnittstellen wird auch in beide Richtungen verwendet, durch die Implementierung des ICore Interfaces kann der Core auch von anderen Plugin Loadern verwendet werden. Der Core soll zukünfig eine Liste von Core Features anzubieten, die durch die Plugins erweitert werden kann. Dadurch können Features die von Plugins geschaffen wurden anderen Plugins zur Verfügung gestellt werden.
classDiagram
class Core {
+ IConfiguration configuration
+ List<IPlugin> loadedPlugins
+ IPublisher publisher
+ IReceiver receiver
+ IPluginFactory pluginFactory
+ ApplicationState appState
--
+ Core(plugins, pluginFactory, configuration, initialState, publisher, receiver)
+ getConfiguration()
+ run()
+ getCore()
+ setState(state)
+ getState()
+ getPublisher()
}
interface IConfiguration
interface IPlugin
interface IPluginFactory
interface IPublisher
interface IReceiver
Core --|> IConfiguration
Core --|> IPlugin
Core --|> IPluginFactory
Core --|> IPublisher
Core --|> IReceiver
Die Klasse Core nimmt die abhängigen Objekte
pluginspluginFactoryconfigurationpublisherreceiver
im Konstruktor entgegen. Dadurch wird die Kontrolle über die Erstellung und Bereitstellung dieser Objekte an den aufrufenden Code (den sogenannten "Inversion of Control Container" oder "IoC Container") übergeben. Im Falle der Smarthome-Bridge übernimmt die PluginLoader Klasse in Verbindung mit der PluginFactory diese Funktion
Durch die Verwendung eines IoC Containers wird die Erstellung der abhängigen Objekte zentralisiert und die Abhängigkeiten zwischen den Komponenten des Systems werden entkoppelt. Dadurch wird die Flexibilität, Erweiterbarkeit und Austauschbarkeit des Systems verbessert.
Die Loader Klasse stellt die Objekte bereit, die in der Core Klasse verwendet werden.
Im aktuellen Zustand des Projektes werden Basisfunktionalitäten wie Nachrichtenaustausch und Configuration direkt per Objekt übergeben und von der Loader Klasse instanziiert. In den nächsten Schritten sollen nur noch die Plugins übergeben werden, die von der Loader Klasse initialisiert werden. Es werden jedoch nur Interfaces übergeben um eine lose Kopplung zu gewährleisten und nicht von konkreten Implementierung wie beispielsweise der PluginFactory abhängig zu sein.
Lose Kopplung wird unter anderem durch die Anwendung des Liskov Substitution Principle, Interface Segregation Principle und Dependency Inversion principle sowie den Aufbau nach der Clean Architecture umgesetzt.
Hohe Kohäsion wird unter anderem durch die Anwendung des Single Responsibility Principle umgesetzt. Das Projekt ist in viele Klassen aufgeteilt, die meist nur eine Verantwortung haben.
Das DRY-Prinzip wurde woimmer möglich umgesetzt, indem mit verschiedenen Mechaniken wie der Clean Architecture, Design Patterns oder der Anwendung der anderen, konkreteren Programming Principles eine lose Kopplung erreicht und damit ein Aufrufen bereits bestehenden Codes aus einem anderen Kontext ermöglicht wurde.
Das DRY-Prinzip wurde woimmer möglich umgesetzt, indem mit verschiedenen Mechaniken wie der Clean Architecture, Design Patterns oder der Anwendung der anderen, konkreteren Programming Principles eine lose Kopplung erreicht und damit ein Aufrufen bereits bestehenden Codes aus einem anderen Kontext ermöglicht wurde.