Flash-Engineering, Teil 2 – Anwendungen erweiterbar entwickeln

Kein Beitragsbild

Ziel der Flash-Entwicklung ist nicht nur eine funktionierende Anwendung. Der entwickelte Code sollte zudem auch einige andere Anforderungen erfüllen. In diesem Teil der Serie geht es um die Erweiterbarkeit von Code.

Der komplette Artikel stammt aus dem Buch Flash-Engineering Stundentenausgabe von Sven Busse und ist ein Gastbeitrag des ADDISON-WESLEY-Verlags.

Erweiterbarkeit

Flash gibt es zu der Zeit, in der dieses Buch entstanden ist, in Version 10. Die Flash-API und auch die Sprache ActionScript selbst wurden stetig erweitert. Viele Anwendungen, die über einen längeren Zeitraum hinweg verwendet werden, werden um Funktionen erweitert. Erweiterungen sind dabei noch mal anders als Veränderungen, die wir im vorangegangenen Abschnitt behandelt haben. Bei Erweiterungen bestehen zwei gegensätzliche Herausforderungen. Einerseits muss die Anwendung die neue Erweiterung nutzen und ansprechen können, andererseits möchte man für eine Erweiterung möglichst wenig in der eigentlichen Anwendung verändern.

Nun könnte man sich eine Anwendung vorstellen, die als eine geschlossene Einheit aufgebaut ist, die in sich alle Funktionen erfüllt, die anfangs definiert wurden, und das war’s. Eine solche monolithische Anwendung wäre dann im Prinzip gar nicht erweiterbar, ohne dass man sie nicht selbst stark abändert. Das Ziel ist ja aber, dass man eine Anwendung erweitern kann, ohne am bestehenden Code allzu viel ändern zu müssen. Das klingt nun nach einer nicht so einfachen Anforderung, denn man kann ja heute nicht wissen, was wohl in der Zukunft für Erweiterungen kommen mögen. Und eine Anwendung für alle Eventualitäten zu rüsten, würde einen immensen Aufwand bedeuten und den Code auch enorm aufblähen, was sich wiederum schlecht auf die Wartbarkeit auswirkt.

In der Tat ist die Erweiterbarkeit auch ein Merkmal, das nicht zwingend bei allen Anwendungen gleich wichtig ist. Anwendungen, die einen kurzen Lebenszyklus haben, müssen höchstwahrscheinlich nicht so stark erweiterbar sein wie Anwendungen, von denen man sich eine lange Lebensdauer erhofft. Wie kann man aber nun bei solchen länger laufenden Anwendungen für eine gute Erweiterbarkeit sorgen?

Praxisbeispiel – erweiterbare Punkte kapseln

Erweiterbarkeit muss geplant werden. Man kann eine Anwendung nicht vorsorglich in alle Richtungen erweiterbar machen. In den meisten Fällen muss man das auch nicht. Nehmen wir als kleines Beispiel wieder den Videoplayer für unsere Firma FilmRegal. Wie können wir Erweiterbarkeit für einen Videoplayer planen? Was wollen wir  bei einem Videoplayer erweiterbar halten? Zunächst fällt einem da das Videodatenformat ein. Seit einer bestimmten Version von Flash 9 können wir nicht mehr nur FLV-Dateien laden, sondern auch andere Dateiformate, solange sie einen kompatiblen Codec verwenden.

Es ist denkbar, dass in der Zukunft weitere Formate dazukommen. Wenn das passiert, wäre es schön, wenn wir dazu nicht jedes Mal unseren Videoplayer komplett umbauen müssen. Das Beziehen der Videodaten sollte innerhalb des Players also vom Rest der Anwendung gekapselt werden, damit wir später weitere Formate hinzufügen können. Wir definieren also das Videodatenformat als einen Punkt, der erweiterbar sein soll.


Enorme Erweiterbarkeit zum reinen Selbstzweck bringt meist wenig Nutzen.

Kennst du unser E-Book-Bundle? Spare jetzt 6,99 €!

E-Book Bundle von Andreas Hecht

Wie viele Stellen man in einer Anwendung für konkrete Erweiterbarkeit identifiziert, ist eine Abwägungsfrage zwischen Aufwand, Wahrscheinlichkeit des zukünftigen Wunsches der Erweiterung an dieser Stelle und negativen Einflüssen auf Wartbarkeit, Leistungsfähigkeit und anderen Eigenschaften der Anwendung. Es ist also letztlich in einem hohen Maß eine wirtschaftliche und strategische Überlegung.

Frühere Projekte geben Hinweise auf potentiellen Erweiterungsbedarf

Strategisch auch, weil Erfahrungen mit ähnlichen Projekten aus der Vergangenheit Hinweise darauf geben können, wo sich in der Zukunft Anforderungen für Erweiterungen ergeben können. Bei einer Gruppe von Anwendungen, die in der Vergangenheit oft Änderungen und Erweiterungen mit einem bestimmten Backend-System erfahren hat, kann man davon ausgehen, dass dies ein Punkt für Erweiterungen auch in einem neuen Projekt sein kann, wenn es mit den anderen verwandt ist. In dem Fall sollte man auch in der neuen Anwendung dafür sorgen, dass entsprechend der Entwurf der Anwendung eine Erweiterbarkeit an der Schnittstelle zu besagtem Backend ermöglicht.

Um konkret geplante Erweiterbarkeit in einem hohen Maße zu erreichen, stehen uns Entwicklern einige nützliche Entwurfsmuster zur Verfügung, die speziell die Entkopplung von nutzenden zu genutzten Klassen modellieren, wie zum Beispiel Decorator, Facade, Chain of Responsibility und andere.

Es gibt aber auch noch grundsätzliche Dinge, die die Erweiterbarkeit einer Anwendung begünstigen oder auch behindern. Modularität und Kapselung begünstigen die Erweiterbarkeit. Wenn in unserem Videoplayer die Anwendung keine direkte Kenntnis vom Videodatenformat hat, dann ist es überhaupt erst möglich, unterschiedliche Formate als Erweiterungen zu unterstützen. Wenn die Grundlogik des Videoplayers sauber vom User-Interface getrennt ist, dann kann später Letzteres um zusätzliche Bedienfunktionen erweitert werden.

Je stärker wiederum einzelne Teile einer Anwendung konkrete Kenntnis von anderen Teilen haben, je verzweigter etwa die gegenseitigen Methodenaufrufe sind – Klasse A verwendet zwei Methoden von Klasse B, die wieder mehrere Methoden von Klasse C, die wiederum einige von Klasse B und A –, desto geringer ist zwangsläufig die Erweiterbarkeit einer solchen Anwendung.

Anwendungen also, die grundsätzlich stark modular und gekapselt aufgebaut sind, sind auch in den Teilen auf Erweiterungen gut vorbereitet, in denen nicht mit Erweiterungen gerechnet wurde. Man muss hier aber wie gesagt aufpassen, dass man einen gesunden Mittelweg zwischen Modularität und Sicherstellung von Leistungsfähigkeit und beherrschbarer Komplexität der Anwendung weiterhin gewährleistet, denn zu kleinteilige Modularität kann negative Auswirkungen auf andere Eigenschaften einer Anwendung haben, wie zum Beispiel Verständlichkeit und Robustheit.

Im nächsten Teil lesen Sie:
  • Wiederverwendbarkeit
  • Robustheit
(mm), ™