schöne namenskonvention für asynchrone methoden

[bokel]

Schöne Namenskonvention

Neulich habe ich bei MS in der .NET Dokumentation gestöbert und bin auf einen Artikel über
asynchrone Programmierung gestossen den ich interessant fand. Als Flasher sind wir in der Richtung
ja einiges gewohnt. Wie auch immer, interessant fand ich vor allem die Namensgebung für die Methoden.
Das zeige ich euch am besten am Beispiel, z.B. XML laden

class Test {
 
function loadXMLAsynch( url:String){
      var x:XML = new XML();
      //
      var self:Test = this;
      x.onLoad = function(success:Boolean){
        if( ! success){
          self.loadXMLError( this);
        } else {
          self.loadXMLComplete( this);
        }
      x.load(url);
}
 
function loadXMLComplete( x:XML){
       //...
}
 
function loadXMLError( x:XML){
       //...
}
 
} 

Also eine Methode, die asnychron ablaeuft, bekommt Asynch an ihren Namen hinten angehängt.
Die Ergebnishandler bekommen entsprechend Complete und Error angehängt. Eine Kleinigkeit
nur, aber schön zu lesen finde ich. Man kann sogar noch loadXMLProgress nach dem gleichen System
integrieren. Da hat man sie gleich alle unter einem Hut

Wer hat sowas in der Art in Petto? Dann her damit.
mfg. r

[elysian]

xervus,

schön zu lesen - stimmt... allerdings gibt's das doch bei macr... adobe auch schon!? bei flashremoting z.b. heissen die servicecalls dann

function serviceCall(x){
 service.serviceCall(x);
}
 
function serviceCall_Result(result){
 trace(result);
}
 
function serviceCall_Status(status){
 trace(status.description);
} 

aber natürlich wäre so eine konvention nicht schlecht, in eigenen projekten einzusetzen

greetz, elysian.

[elias]

Nameskonventionen für UnitTest-"Doubles":
http://www.martinfowler.com/bliki/TestDouble.html

[_sevenDust]

Das Wörtchen Load impliziert für mich in Flash eigentlich immer einen asynchronen Vorgang. Bei den Callbacks könnte man sich natürlich so eine Konvention angewöhnen.

[subHero]

Zitat von _sevenDust

Das Wörtchen Load impliziert für mich in Flash eigentlich immer einen asynchronen Vorgang.

dito meinerseits.
eigentlich ist doch sogar jeder zugriff auf externe entities in flash ein asynchroner prozess (im gegensatz zu z.bsp. sql-queries in php).
ausserdem ist mir die delegation von methoden innnerhalb einer klasse wie bei der alternativen "*_Result" remoting verfahrensweise ein greuel (man denke an 8+ servicemethoden).
vielmehr hat sich für mich die zentrale verarbeitung von ereignissen/ergebnissen eines remote-zugriffs in einer methode, welche entsprechend aussagekraeftige events (z.bsp. XmlResult, XmlFault, XmlParsed) dispatched als nützlich erwiesen. das ganze dann in eine als statisch zu implementierende klasse gewrappt (kein scattern von remote-zugriffen, sei es xml oder remoting) und eine unterscheidung von einzelnen methoden durch naming scheint mir nicht mehr nötig.

Allerdings: alles geschmackssache
auch das "asynch", "complete", etc. naming ist selbsterklärend.

cheers
-sh

[hazy fantazy]

Jau, da stimmt, in Flash sind die Ladevorgänge immer asynchron. Aber wenn man häufig mit anderen Sprachen arbeitet, macht es Sinn überall einheitlich vorzugehen.

mfg. h

[elias]

Mit dem "Asynch" kann ich mich auch nicht anfreunden, das ist in Flash einfach zu offensichtlich, in .NET ist es halt optional da macht es Sinn.

Was ich aber viel interessanter finde ist die Konvention das "loadXML" vor die
Events zu setzen.

Beispiel:

class XmlLoader
{
    function loadXml();
    function addListener(listener:XmlListener);
}
 
class XmlListener
{
    function loadXmlSuccess();
    function loadXmlFailure();
} 

Ich würde sogar den Klassennamen als Präfix bevorzugen:

class XmlLoader
{
    function load();
    function addListener(listener:XmlListener);
}
 
class XmlListener
{
    function xmlLoaderSuccess();
    function xmlLoaderFailure();
} 

Vorteile:
* Man weiß sofort woher das Event kommt.
* Keine kollisionen mit generischen Event Bezeichnern (zb onLoad)

Nachteile:
* Bezeichner sind sehr Speziell, die API ist hier fixiert auf XML.

Also doch eher Attributes/Annotations?

[subHero]

Zitat von elias

Ich würde sogar den Klassennamen als Präfix bevorzugen:

ich würde es statt präfix lieber (semantischer) kontext nennen. man fängt an zu lesen, die klasse heisst XmlLoader, ergo wird was wohl bei load geladen ?!

* Keine kollisionen mit generischen Event Bezeichnern (zb onLoad)

halte ich für nicht schlimm. zumal man dies ja wiederum gelernt hat (aus dem kontext einer klasse die bedeutung des onLoad's abzuleiten, z.bsp. LoadVars vs. MovieClip vs. XML). ausserdem liebe ich die kennzeichnung von event-methoden mit "on*". on etwas passiert folgendes.

* Bezeichner sind sehr Speziell, die API ist hier fixiert auf XML.

finde ich eher gut. habe schon stunden in dokumentation von frameworks/apis zugebracht, welche ins alles und nichts abstrahiert haben

0.02 €
-sh

[bokel]

@elias: wenn ich den Listener so speziell dafür schreiben würde, dann würde ich ihn auch gleich XMLLoaderListener nennen. Bei den Methoden ist es so eine Sache - was wenn es mehrere load methoden gäbe?

@subHero: Jo das stimmt. Es gibt noch einen Nachteil, wenn alle Methoden gleich heissen. Man kann sie schwierig finden, zumindest mit einer einfachen Textsuche. Was war eigentlich nochmal genau die Begründung für die Gleichmacherei?

mfg. r

[elias]

Also ich bin verwirrt, irgendwie klingt ihr beiden so als würdet ihr alle Variationen
gut und schlecht finden. Aber ich bin auch irgendwie unschlüssig.

Jedenfalls finde ich die "Gleichmacherei" erstmal nicht schlecht. Ein XML.load()
oder LoadVars.load() hat ja bis auf das Parsen den gleichen ablauf. Ein *load()
endet also im *onLoad(). Das Konzept zieht sich ja recht Konsequent durch
Flash und finde es von daher schön transparent. Aber durch die Typisierung
finde ich es weniger leicht austauschbar. Angenommen ich nutze Bokels erstes
Beispiel, aber muss jetzt LoadVars nutzen. In dem Fall würde ich die Klasse
komplett neu schreiben, nur das die Typiserungen und Namen auf LoadVars
ausgerichtet sind. Bis auf das Parsen bleibt aber der Ablauf gleich und es wäre
streng genommen duplizierter Code. Wenn ich statt XML und LoadVars einen
GenericLoader hätte müsste ich nur die Parser routine ändern.
Ein brilliantes Gegenstück ist die Stream API von PHP, egal ob ich einen
Socket, das Dateisystem, FTP o.ä. anspreche ich kann überall fread(), fwrite()
etc. einsetzen. Um die Quelle zu ändern muss ich lediglich meine Klasse mit
einer anderen Resource füttern.
Ich denke das diese "generischen" Namenskonventionen die eine oder andere
Tür öffnen. Es ist aber auch eine Frage ob oder eher wie man Typisierung
einsetzt. Letztlich würde ein "Loader" Interface in XML und LoadVars das
Problem teilweise lösen.

Meinungen?

[atothek]

Schlagwort ist dabei GenericLoader.
Ich handle das loading verhalten mitlerweile für alle externen quellen
über eine Loader klasse. Diese agiert dabei als Proxy für das loading und nutzt dabei die klasischen events

onLoadStart, onLoadComplete, onLoadProgress und onLoadError,

dabei werden alle LoadTargets unterstützt die dem Interface ILoadable entsprechen,
ILoadable verlangt nach

getBytesTotal() und getBytesLoaded()

sowie einer load methode. ausnahmen machen dabei MovieClips, Sounds und videos diese handle ich speziell, diese haben ja geine generische load methode
(warum auch immer)

Der Vorteil des ganzen ist ein immer gleichbleibendes Interface anzusprechen was intern je nach LoadTarget entscheidet wie wo was .

Das ganze hat einen Hauch von der EierlegendenWollMilchSau ist aber noch an der Granze und meiner meinung nach durchaus vertretbar.

mfg
alex

[hazy fantazy]

Polymorphie ist natürlich ein guter Grund für Gleichmacherei. Aber auf der anderen Seite habe ich auch schon erlebt, dass in einem groesseren Stück Code die Funktionen solcherart ähnliche oder sogar gleiche Namen hatten, dass man echt nicht mehr wusste, was Sache ist. Im Sinne von OOP wäre es ja richtig, dass man nicht genau weiss, was in Detail passiert, aber zum Verständnis des Codes ist es dann wichtig, dass die Methoden auf der Metaebene (unterhalb der alle Objekte gleich behandelt werden) sinnvolle Namen haben, so dass man sich daraus zusammenreimen kann, was wirklich passiert. Sonst muss man doch wieder in die Klassen oder deren Doku reinschauen. Als extremes Beispiel stell dir mal vor, deine Objekte haben alle nur eine Funktion namens execute, z.B. XMLLoader.execute entspräche also dann XMLLoader.load - extremes Beispiel, ist schon klar. Es soll auch nur zeigen, dass gute Namen nicht nur Schall und Rauch sind

irgendwie klingt ihr beiden so als würdet ihr alle Variationen
gut und schlecht finden.

Das ist wohl auch so. Ich würde gerne mal eine Punkt erreichen, an dem ich von einem älteren Stück meines Codes sagen kann, wow, gut lesbar und macht was es soll

mfg. h

[elias]

@atothek
Ja ganau darauf wollte ich hinaus. Hast du Lust deine API genauer zu skizzieren,
wie sieht z.B. deine "GenericLoader" Schnittstelle aus?

@hazy fantazy
Ja das ist schon richtig, die Namen sollten aussagekräftig sein und nicht in die
Irre führen. Aber wenn ich Daten lade dann ist es mir erstmal schnurz was
es für Daten sind, die Unterscheidung mache ich ja erst wenn die Daten
da sind und ich sie verarbeiten möchte.

[bokel]

Nur der Vollständigkeit halber: Hier ist der Link, auf den ich mich in meinem ersten Post bezogen habe: http://msdn2.microsoft.com/en-us/library/e7a34yad.aspx