Know-how für Kreative

Inhaltsverzeichnis
1 Erste Schritte
2 Versionen
3 Einführung in die Programmierung
4 Die Entwicklungsumgebung
5 Regeln
6 Anweisungen und Aktionen
7 Werte und Datentypen
8 Ausdrücke und Operatoren
9 Funktionen
10 Kontrollstrukturen
11 Dokumenten-Objektmodell und Gültigkeitsbereich (Scope)
12 Ereignisse
13 Objekterstellung
14 Vererbung
15 Movieclips
16 ActionScript 2.0
17 Komponenten
18 Codedesign und Konzeption
19 Flashdetection
20 Aussergewoehnliche Benutzerfuehrung
21 D mit Flash
22 Macromedia Central
23 HTML
24 JavaScript, ActiveX und Java
25 Flash undokumentiert
26 Vergangenheit, Gegenwart und Zukunft
27 Kurzreferenz
28 Buchtipps
29 Links
30 Die CD-ROM zum Buch
Index
Download: - ZIP, ca. 9,8 MB
Buch bestellen
Ihre Meinung?
<< zurück | Galileo Design / <openbook> / ActionScript | vor >>
ActionScript 1 und 2 von Sascha Wolter (http://www.saschawolter.de/) Objektorientierung und Codedesign mit Flash MX 2004
ActionScript 1 und 2 672 S., mit CD, Referenzkarte, 44,90 Euro Galileo Design ISBN 3-89842-221-6 |
| Kapitel 18 Codedesign und Konzeption
|  | 18.1 Analyse und Konzeption
|  |  | 18.1.1 Veränderliche Anforderungen und Konzepte
|  |  | 18.1.2 Mehr Vorstellungskraft durch Prototypen
|  | 18.2 Entwicklungsumgebung
|  |  | 18.2.1 Werkzeuge
|  |  | 18.2.2 Trennung von Ressourcen und Programmierung
|  |  | 18.2.3 Aufteilung in einzelne Module
|  |  | 18.2.4 Versionsmanagement
|  |  | 18.2.5 Strukturierung der Dateien
|  | 18.3 ActionScript
|  |  | 18.3.1 Bezeichner
|  |  | 18.3.2 Typisierung
|  |  | 18.3.3 Codehinweise
|  |  | 18.3.4 Kommentare und Dokumentation
|  | 18.4 Optimierung
|  |  | 18.4.1 Bytecode optimieren und extrahieren
|  |  | 18.4.2 Eigenständige Anwendungen und Bildschirmschoner
## 18.3 ActionScript ##### Codedesign\ActionScript Ein guter Programmierer zeichnet sich nicht nur dadurch aus, dass er die Grammatik (Syntax) und die Vokabeln (Semantik) der Sprache kennt, sondern dass sein Programmcode nicht nur vom Computer korrekt ausgeführt, sondern auch von menschlichen Lesern nachvollzogen werden kann. Bereits einige wenige Regeln helfen, die Lesbarkeit für Menschen zu verbessern. ### 18.3.1 Bezeichner Für die korrekte Wahl der Namen von Eigenschaften und Methoden gibt es unzählige Empfehlungen. Auch hier kommt es in erster Linie wieder darauf an, dass Sie sich aus diesem Fundus an Vorschlägen die für Sie besten heraussuchen. Als Erstes sollten Sie die Sprache für die Bezeichner und die Kommentare festlegen – in der Hoffnung, dass sich alle Beteiligten daran halten. Für die Bezeichner kommt meist Englisch zum Einsatz, da die Programmiersprache ActionScript sich ja auch an diese Sprache anlehnt und sich der Quellcode so einfach durchgängiger lesen lässt. Für die Kommentare kann es von Vorteil sein, diese in Deutsch zu halten, falls viele deutschsprachige Entwickler mit mangelnden Englischkenntnissen im Team sind oder anschließend eine deutschsprachige Dokumentation gefordert ist. Internationale Unternehmen fordern aber auch hier meistens Englisch. Es ist hilfreich, Eigenschaften einen beschreibenden Namen zu geben und Methoden mit einem Verb im Imperativ (Befehlsform) zu versehen, um die Bezeichner von Eigenschaften und Methoden leichter unterscheiden zu können:
    function loadView () { }; // lade Ansicht
    var loadedView:String; // geladene Ansicht
    var viewLoaded:Boolean; // Ansicht geladen?
Bei Eigenschaften ist es außerdem empfehlenswert, bereits im Bezeichner zu kennzeichnen, welchen Typ an Information sie verwalten. Ob es sich dabei um ein Suffix (angehängte Zeichenkette) oder ein Präfix (vorangestellte Zeichenkette) handelt, ist Geschmackssache. Im Zweifelsfall können Sie ja die Suffixe von Macromedia übernehmen (siehe Tabelle):
    // Ein paar mögliche Bezeichner für einen MovieClip
    var name_mc:MovieClip; // Macromedias Variante
    var mc_name:MovieClip;
    var nameMc:MovieClip;
    var mcName:MovieClip;

Tabelle 18.3 Macromedias Suffixe für Variablen

Objekttyp | Suffix
Array | _array
Button | _btn
Camera | _cam
Color | _color
ContextMenu | _cm
ContextMenuItem | _cmi
Date | _date
Error | _err
LoadVars | _lv
LocalConnection | _lc
Microphone | _mic
MovieClip | _mc
MovieClipLoader | _mcl
PrintJob | _pj
NetConnection | _nc
NetStream | _ns
SharedObject | _so
Sound | _sound
String | _str
TextField | _txt
TextFormat | _fmt
Video | _video
XML | _xml
XMLNode | _xmlnode
XMLSocket | _xmlsocket
### 18.3.2 Typisierung Grundsätzlich zählt eine konsequente Typisierung zu den wichtigsten Regeln, um Fehler zu vermeiden. Doch ab und an scheint Typisierung nicht zu funktionieren, wie das folgende Beispiel zeigt. ##### Probleme mit der Typisierung bei der Verwendung von Rückruffunktionen. Angenommen Sie haben eine DataLoader-Klasse, die das Laden von XML-Daten verwaltet, und nutzen in dieser Klasse eine Instanz der XML-Klasse zum Laden. Dann handelt es sich bei dieser XML-Instanz letztendlich um eine vom DataLoader aggregierte (also im Besitz befindliche) Instanz. Die XML-Instanz muss nun ihrem Besitzer, also dem DataLoader, eine Nachricht senden, sobald Daten empfangen werden. Doch anders als bei MovieClips gibt es hier keine automatisch erzeugte _parent-Eigenschaft mit Referenz auf den Besitzer.
    class DataLoader {
       function loadData() {
          var my_xml;
          my_xml = new XML();
          my_xml.onLoad = function() {
             // Teile das Ergebnis der übergeordneten Instanz mit
             // instanzVonDataLoader.onLoadData();
             // _parent geht nicht
             // ...
          };
       }
       function onLoadData() {
       }
    }
Eine Lösung dieses Problems wäre, wie im Folgenden auf die Typisierung zu verzichten und der XML-Instanz eine Referenz auf den DataLoader mitzuteilen. Das this innerhalb der Funktion mit dem Verweis auf den owner (engl. für Besitzer) muss verwendet werden, um auf den Gültigkeitsbereich der XML-Instanz zu verweisen. Ohne this findet Flash an dieser Stelle keinen owner! Der Verzicht auf die Typisierung öffnet fehlerhaftem Code Tür und Tor, weshalb davon abzuraten ist.
    class DataLoader {
       function loadData() {
          var my_xml;
          my_xml = new XML();
          my_xml.owner = this;
          my_xml.onLoad = function() {
             // Teile das Ergebnis der übergeordneten Instanz mit
             this.owner.onLoadData();
          };
       }
       function onLoadData() {
       }
    }
##### owner Ähnlich wenig empfehlenswert wie die vorhergehende Lösung ist der Versuch, die Typisierung nur für die eine Eigenschaft owner auszuhebeln:
    class DataLoader {
       function loadData() {
          var my_xml:XML;
          my_xml = new XML();
          // Verhindert Typisierung durch Zugriff mit ["bezeichner"]
          my_xml["owner"] = this;
          my_xml.onLoad = function() {
             // Teile das Ergebnis der übergeordneten Instanz mit
             this.owner.onLoadData();
          };
       }
       function onLoadData() {
       }
    }
Eine selbst erstellte Klasse mit der Eigenschaft owner ist die sauberste, aber leider auch aufwändigste Lösung. Diese Klasse beherrscht dank Vererbung alles, was auch die Klasse XML kann:
    class DataXML extends XML {
       var owner:Object;
    }

    class DataLoader {
       function loadData() {
          var my_xml:DataXML;
          my_xml = new DataXML();
          my_xml.owner = this;
          my_xml.onLoad = function() {
             // Teile das Ergebnis der übergeordneten Instanz mit
             this.owner.onLoadData();
          };
       }
       function onLoadData() {
       }
    }
Die letzte und aufgrund des geringen Aufwandes beliebteste Lösung ist eine lokale Variable namens owner. Lokale Variablen haben die Eigenheit, dass sie im gesamten Kontext einer Funktion inklusive der darin deklarierten Objekte und Methoden zur Verfügung stehen – egal wie tief geschachtelt die Objekte erstellt werden. Aus diesem Grund darf auch dieser Variablen kein this vorangestellt werden, da es sich dann um einen anderen Gültigkeitsbereich handeln würde. Zwar ist der Programmcode dann etwas schwieriger zu lesen, da die lokale Variable nur schwer von einer Eigenschaft zu unterscheiden ist, aber wenigstens bleibt die Typsicherheit erhalten:
    class DataLoader {
       function loadData() {
          var owner:DataLoader;
          var my_xml:XML;
          my_xml = new XML();
          my_xml.onLoad = function() {
             // Teile das Ergebnis der übergeordneten Instanz mit
             owner.onLoadData();
          };
       }
       function onLoadData() {
       }
    }
### 18.3.3 Codehinweise Um eine Unterstützung des Flash-Editors bei der Entwicklung zu erhalten, gibt es die Codehinweise. Flash blendet dabei die verfügbaren Eigenschaften und Methoden eines Objektes ein, sofern der Typ bekannt ist. Dabei ist es für die Codehinweise egal, ob Sie eine richtige Typisierung vornehmen
    var eigenschaft:Typ;
oder ob Sie den Typ in einem Kommentar ausschließlich zur Anzeige von Codehinweisen vorgeben (inklusive dem Semikolon):
    // Typ eigenschaft;
oder ob Sie mit einer eindeutigen Zeichenfolge im Bezeichner arbeiten (siehe Tabelle »Suffixe«):
    eigenschaft_suffix;
Sollten Sie mit den Codehinweisen nicht zufrieden sein, so können Sie zumindest die von Flash erkannten Zeichenfolgen anpassen. Diese finden Sie im Konfigurationsordner, meist C:\Dokumente und Einstellungen\[Benutzer]\Lokale Einstellungen\Anwendungsdaten\Macromedia\Flash MX 2004\[Sprache]\Configuration\, unter der Bezeichnung AsCodeHints.xml im Verzeichnis ActionsPanel (siehe »Entwicklungsumgebung anpassen« ab Seite 99). Flash unterscheidet hier zwischen Mustern (engl. Pattern) für Codehinweise, die automatisch vervollständigt werden, und Typangaben, anhand derer die zulässigen Eigenschaften und Methoden angeboten werden. Glücklicherweise dürfen Sie hier eigene Angaben vornehmen. Das folgende Beispiel erlaubt das Präfix mc_ für Movieclips und vervollständigt bei der Angabe von Application. die Anweisung mit einer der beiden angegebenen Varianten:
    <codehints>
      <codehint pattern="Application.start();\n}\n" />
      <codehint pattern="Application.stop();\n}\n" />
      <typeinfo pattern="mc_*" object="MovieClip" />
    </codehints>
### 18.3.4 Kommentare und Dokumentation Hier klicken, um das Bild zu Vergrößern Abbildung 18.4 Automatisch generierte Dokumentation des Quellcodes (mit Jellyvision ActionDoc erzeugt) Nicht nur zur Orientierung ist es erforderlich, den Programmcode zu kommentieren und zu dokumentieren. Für viele Auftraggeber gehört zum Ende eines Projektes eine Dokumentation mit zur erfolgreichen Übernahme. Da wäre es natürlich hilfreich, wenn die Dokumentation automatisch generiert werden könnte. Flash bietet jedoch keine Werkzeuge dafür. Das von Macromedia für die eigene Code-Dokumentation verwendete Werkzeug mit dem Namen ASDoc ist nicht für Normalsterbliche erhältlich. So bleibt nur die Suche nach einer Alternative … ##### JavaDoc Der Standard für Kommentare und daraus generierte Dokumentation ist JavaDoc. JavaDoc funktioniert jedoch nicht gemeinsame mit ActionScript, da die Syntax von Java und ActionScript zu unterschiedlich ist. Doch immerhin halten sich alle bekannten Zusatzwerkzeuge für Flash an den von JavaDoc etablierten Standard für die Angabe der Kommentare – der ActionScript-Editor SE|PY erlaubt bereits die automatische Generierung von JavaDoc-ähnlichen Kommentaren (siehe »Werkzeuge«). JavaDoc-Kommentarblöcke zur Beschreibung von Klassen, Eigenschafen und Methoden werden mit /** eingeleitet und mit */ beendet. Die dazwischen liegenden Zeilen beginnen mit einem *. Je nach verwendetem Werkzeug sind in den Zeilen weitere Angaben erlaubt, um beispielsweise Parameter oder den Autor anzugeben – diese werden meist mit einem @ eingeleitet. Aus diesen Angaben und dem eigentlichen Code erzeugen Werkzeuge wie die in der Tabelle angegebenen eine Dokumentation. Beispielsweise führt der folgende ActionScript-Code mit JavaDoc-Kommentaren zu der in der Abbildung 18.4 dargestellten Dokumentation, sobald ein Werkzeug wie ActionDoc zum Einsatz kommt:
    /**
     * Freundin
     *
     * @author Sascha Wolter
     * @see <a href="http://www.saschawolter.de">Sascha Wolter</a>
     * @version 1
     */
    class Freundin {
       public var kreativ:Boolean;
       /**
        * Freundin
        *
        * @param Void
        */
       function Freundin(Void) {
          kreativ = true;
       }
       /**
        * tanze
        *
        * @param Void
        * @return Void
        */
       function tanze(Void):Void {
          trace("yippi!");
       }
    }

Tabelle 18.4 Werkzeuge zum Generieren von Programmcode-Dokumentation (Auswahl)

Bezeichnung | Hersteller | URL | Bemerkung
ActionDoc | Jellyvision | http://www.jellyvision.com/actiondoc/ | Beta.
AS2docGenerator | Tanja Pislar | https://sdeveloper.berlios.de/... | OpenSource.
ASDoc | Macromedia | http://www.macromedia.com/ | Leider nicht öffentlich erhältlich.
gModeller | Grant Skinner | http://www.gskinner.com/gmodeler/ | Dieses Modellierungswerkzeug erstellt automatisch Kommentare und Dokumentation.
JavaDoc | Sun Microsystems | http://java.sun.com/j2se/javadoc/ | Das Standardwerkzeug zur Code-Dokumentation.
<< zurück | <top> | vor >>
Zum Katalog
ActionScript 1 und 2 bestellen
Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen? Ihre Meinung
Buchtipps
| Einstieg in ActionScript
| Einstieg in Flash 8
| Flash 8 und PHP
| Flash 8-Tutorials
| Dreamweaver 8
| Webseiten programmieren und gestalten
Shopping
Versandkostenfrei bestellen in Deutschland und Österreich Info

Copyright © Galileo Press GmbH 2005
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

[Galileo Design]
Galileo Press GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de