Entwurf einer Software-Architektur für die App-Entwicklung am Beispiel von TapeEcho
(EN google-translate)
(PL google-translate)
Nach folgende Grafik zeigt den Entwurf einer Klassenarchitektur für TapeEcho:
Bild 0-1: Klassenarchitektur für TapeEcho.
Es gilt ein umfangreiches Framework zu entwickeln, um allgemein
die Entwicklung eines bestimmten individualisierten Typs an Apps
zu unterstützen. So ist die Klasse Zwischenschicht dafür vorgesehen,
den unmittelbar in der erbenden Klasse verfügbaren Befehlssatz anzureichern,
so dass die Methoden aus PApplet und auch die der Zwischenklasse verfügbar sind.
Beispiele hierzu wären Methoden, die es vereinfachen, Standardbedienelemente zu erzeugen, oder die Eigenschaften des Zieldevices abzurufen (verfügbarer RAM-Speicher, Sensoren, ... ), oder Hilfsmethoden, um GUI-Elemente wie Buttons leichter zu erstellen.
Neben der Hauptklasse (im wirklichen Projekt info.kramann.tapeecho.TapeEcho), gibt es die Anwendungsklasse, die die Hauptfunktionalität enthält und bereits mit Hilfe einer rudimentären GUI in Hauptklasse getestet werden kann.
In einem Unterpackage hilfsklassen werden zudem nützliche Methoden gesammelt, die auch in anderen Projekten wiederverwendet werden können.
Nachfolgend sind zur Illustration noch Beispiel-Attribute und -Methoden eingefügt:
Bild 0-2: Klassenarchitektur für TapeEcho mit Beispielmethoden.
Dier hier dargestellte Struktur soll als Anregung für das eigene Projekt dienen, kann aber auch einfach so, wie sie ist für das eigene Projekt adaptiert werden.
Verfeinerung der Architektur
Anstatt einer Zwischenschicht, werden eine ganze Reihe voneinander erbender Zwischenklassen eingeführt.
Das hat den Vorteil, dass der Quelltext besser geordnet wird und man nicht benötigte Zwischenschichten leichter entfernen kann, insofern erst die Hauptklasse die Inhalte benötigt und nicht bereits Zwischenklassen.
Bild 0-3: Verfeinerung der Architektur
Das vorangestellte X steht für eXtension / Erweiterung.
Zudem wäre denkbar, die Zwischenklassen in einzelne als Library markierte, voneinander getrennte Eclipse-Projekte zu packen.
Die Anzahl der Zwischenklassen könnte viel größer sein. Hier ein Entwurf:
|
Da es sich um eine grosse Anzahl an Möglichkeiten handelt und die strenge Hierarchie eher unmotiviert ist, wäre alternativ möglich von jeder Klasse ein Objekt in der Hauptklasse bei Bedarf zu erzeugen.
Der Nachteil hiervon ist, dass nun nicht mehr ein einfacher Befehl etwas bewirkt, sondern immer objektname.befehl().
Tip: Notwendige Resourcen wie Arrays, andere Objekte müssen nicht vor der ersten Verwendung einer Methode instanziiert werden, wenn man so verfährt:
public boolean sendeSMS(String text, String nummer)
{
if(sms==null)
{
sms = new SMSgeraet();
}
if(sms!=null)
{
sms.schicken(text,nummer);
return true;
}
else
{
return false;
}
}
Code 0-1: Instanziierung bei Bedarf am Beispiel eines SMS-Gerätes.
Vorteil: leichter verstehbarer Code im Hauptprogramm. Vorteil2: Keine unnötigen Instanziierungen. Nachteil: Verlangsamung beim ersten Aufruf der Methode.