Funktionen aufrufen, nur falls sie auch existieren

Lesetipps

1. Gefährliche PHP-Funktionen ausschalten
2. Guess what’s happening – Folge 1
3. Mehrere Scripte via Cronjob parallel aufrufen

Als erstes gibt’s heute noch mal eine Erinnerung an unser Gewinnspiel. Für einen Backlink könnt ihr noch ein Planungspokerspiel gewinnen, Es sind noch ein paar von unseren 50 da. So genug der Eigenwerbung. Wieder zurück zum Thema.

Ich habe heute kurz mit Frank Bültge, meinem WordPress Guru, gesprochen, weil ich wissen wollte, wie er ein bestimmtes Plugin umsetzen würde. Natürlich hatte er auch gleich ein Beispiel zur Hand. Davon werdet ihr die nächste Zeit bestimmt auch noch hören, denn da habe ich noch was schönes vor. Was mir aber aufgefallen ist, ist dass ganz häufig in WordPress Plugin Quellen so was wie

if ( function_exists( 'doSth' ) { doSth( $arg1, $arg2 ); }

vorkommt. Das ist auf jeden Fall der saubere Weg, denn man möchte ja nicht, dass der Blog kaputt ist, nur weil ein Plugin ausgeschaltet wurde und ich eine Methode davon einbinde. Irgendwie ist das aber trotzdem duplizierter Code und das mögen wir ja gar nicht.

Spontan kam mir da heute eine Idee, wie man das testen für solche einfachen Fälle, wie oben beschrieben, machen könnte, ohne dass mir PHP da wild Fehler wirft. Das soll hier nur ein Proof of Concept sein. Keine Ahnung, ob ich oder jemand anderes es mal produktiv einsetzen wird. Seht es einfach als Denkanstoß.

Was müssen wir also machen? Eigentlich nicht viel, denn dank der magischen Methoden und PHP 5.3 wird einem eigentlich schon das meiste Out-of the-box geliefert. Wie würde ich mir einen nicht-doppelten Code vorstellen? So:

ifExists::doSth( $arg1, $arg2 );

Der Trick daran ist, dass man eine ifExists Klasse bastelt, die wie folgt aussieht:

class ifExists
{
  public static function __callStatic( $functionName, $args )
  {
    if ( function_exists( $functionName ) ) {
      call_user_func_array( $functionName, $args );
    }
  }
}

Das ganze funktioniert nach folgendem Schema. Da die statische Methode doSth in der Klasse ifExists nicht existiert, wird die magische Methode __callStatic aufgerufen, um den „Fehler“ abzufangen. Was wir jedoch machen ist den Aufruf an die global gültige Funktion weiterzuleiten, falls diese existiert. Fertig. Was anderes müssen wir gar nicht mehr machen, Außer vielleicht die Klasse dem System bekannt machen, aber dass könnte ja WordPress übernehmen, die sind ja eh ein Freund von so Dingen.

37 Kommentare »

• 
  

  ragtek

  am 24. Februar 2010 um 07:53 Uhr

  Hehe, endlich weiß ich, wieso der WordPresscode voller “if function_exists()” ist.
  Sonst hab ich das noch in keinem Projekt gesehen und benutze es für meine Sachen auch nicht.

• 
  

  Marek Luthardt

  am 24. Februar 2010 um 08:06 Uhr

  Sehr elegant! Würde ich sofort überall einsetzen, nur gibt es leider immer noch eine Unmenge an Hostern, die noch nicht bei PHP 5.3 angekommen sind.

• 
  

  Christian

  am 24. Februar 2010 um 08:08 Uhr

  Also ich weiss nicht..

  Ich habe auch schon öfters so einen Code geschrieben, um z.B. auf einem ZendPlatform Server monitor_custom_event() aufzurufen ohne dabei auf meinem lokalen Entwicklungssystem ohne ZP einen Fehler zu produzieren.

  Trotzdem kommt mit diese magische Klasse unschön vor.

  In Javascript ginge es soweit ich mich erinnere mit

  var result = funktionDieEsVielleichtNichtGibt|function(){}();

  aber ist das schön? An einer solchen Stelle kann ich (auch in PHP) besser mit einer Redundanz im Code leben, als mit einem Konstrukt, das sich im mir verschliesst, weil es sich versteckt.

• 
  

  Christian

  am 24. Februar 2010 um 08:11 Uhr

  ok mein Javascript ist doch eingerostet. aber so ähnlich war’s bestimmt.

• 
  

  metalguy

  am 24. Februar 2010 um 08:17 Uhr

  Na also ich weiss auch nich. Es ist auf jeden fall ne sehr nette Methode um bei so boliden Frameworks wie JQuery die Module gegenseitig abzusichern, gegen eine Portierung auf PHP sträube ich mich jedoch etwas. Ich meine ich entwerfe eine App auf Basis – PHP, und setze dann, falls gegeben, andere Module vorraus. Entweder wird sonst ein Teil oder es als ganzes nicht ausgeführt / buggy…
  Für sowas schreib ich doch installer, für sowas gibts phing… Für CMS-Apps vielleicht ganz nützlich aber für den Enterprise-Betrieb definitiv schon rein theoretisch total inakzeptabel.

• 
  

  Dennis Becker

  am 24. Februar 2010 um 08:19 Uhr

  Wieso kommt dir denn die Klasse unschön vor? Sie zentralisiert einen wichtigen Funktionsaufruf (an und für sich), aber wirkliche Ersparnis beim schreiben ist das sicherlich nicht Da sieht man halt, wie weit man OOP treiben kann, wenn man will

• 
  

  Nils Langner

  am 24. Februar 2010 um 08:28 Uhr

  Also unschön finde ich es auch nicht. Falls soetwas als Sprachkonstrukt existieren würde, würde sich auch niemand aufregen, dass es einem verschließt. Das bedeutet nicht, dass ich es einsetzen würde, aber das ist wohl alleine dem geschuldet, dass ich kaum noch prozedural programmiere.

  Mir kam grad übrigens noch die idee etwas wie cached::doSth( ) zu bauen. Mal schauen, ob ich da auch noch einen Proof “raushaue”.

• 
  

  somegas.de - So'n Krams halt

  am 24. Februar 2010 um 08:30 Uhr

  PHP – Existiert die Funktion überhaupt?…

  Eine relativ praktische Variante zum Prüfen, ob eine Funktion existiert habe ich heute PHP Hates Me entdeckt. Die eingebaute Funktion function_exists() kennt der ein oder andere evtl. class ifExists { public static function __callStatic( $func…

• 
  

  Julian

  am 24. Februar 2010 um 08:40 Uhr

  Ich weiß, dass euer zentrales Ziel ist, Fehler NICHT zu melden, andererseits… Fehlermeldungen sind Freunde, das wird oft vergessen.

  Davon abgesehen, dass ich bei so ziemlich allen magischen Methoden außer toString und construct ein schlechtes Gewissen habe, würde ich dann doch zumindest noch einen ausgefeilten Debug-Mechanismus mit einplanen (klar das hier ist noch nicht fertig), um Fehler leichter zu finden, wenn mal etwas doch nicht läuft.
  Man muss selbstverständlich die Vorteile sehen, aber es wird aus meiner Sicht schon zu einem großflächigen Spiel mit dem Feuer, wenn man so etwas stark einsetzt.

• 
  

  KingCrunch

  am 24. Februar 2010 um 09:26 Uhr

  Find ich auch net sooo gelungen. Das fängt schon damit an, das (mal wieder) Funktionen krampfhaft in Klassen verpackt werden, nur weil mans kann

  function call ($callback, $arg = null) {
  $args = func_get_args ();
  array_shift ($args);
  if (is_callable ($callback)) {
  return call_user_func_array ($callback, $args);
  }
  }
  echo call(‘doSth’, $v1, $v2);

  Ich seh das wie metalguy: Wenn ich das zu häufig wirklich brauche, dann vertrau ich ja meiner eigenen Anwendung nicht und gebe irgendwie zu, dass ich meine Anwendung nicht genug teste, um diesen Fall a priori auszuschließen.

  Wenn schon Abhängigkeiten zwischen WP->Plugins, Plugins->WP und/oder Plugins->Plugins existieren und sicher gestellt werden müssen, dann ist es doch eleganter _einmalig_ die Existenz und die Version zu prüfen, anstatt alle Nase lang alles, was man gerade so braucht.

• 
  

  David

  am 24. Februar 2010 um 10:09 Uhr

  Ich muss mich hier KingCrunch anschließen: wenn man schon wie bei WordPress oder Drupal alles in Function-Orgien verpackt, dann sollte man auch bei Functions bleiben. Dafür braucht es auch kein PHP 5.3.

  @Nils der Vollständigkeit halber solltest du in deinen Code auch ein “return” einbauen

• 
  

  Tom

  am 24. Februar 2010 um 10:18 Uhr

  Ich habe das mit den Plugins etwas anders (sauberer?) gelöst. Ich scanne das Pluginverzeichnis on-demand und hole mir für jede gefundene Klasse eine Reflection. Mit deren Hilfe kann ich die verfügbaren Klassen, Methoden, Parameter, Annotations, Beschreibungen und wo sie sich befinden auslesen. Das speichere ich in ein Repository, welches natürlich gecached wird.

  An das Repository angeschlossen ist ein Dispatcher. Dem übergibt man den Namen der gewünschten Funktion und die Parameterliste. Der Dispatcher prüft die Parameter auf Vollständigkeit und Korrektheit, lädt automatisch die notwendige(n) Klasse(n) nach und führt den Broadcast aus. Er fängt Exceptions ab und leitet sie in ein Error-Log. Das Ergebnis der Funktion liefert er zurück.

• 
  

  Michael

  am 24. Februar 2010 um 10:29 Uhr

  Wirklich sauber löst man das nur durch eine interne API, ich mein wer auf function_exists() mittels OOP zurückgreift der kann auch gleich sein Projekt voll OOP entwickeln und die entsprechenden Schnittstellen implementieren.

• 
  

  Tom

  am 24. Februar 2010 um 10:30 Uhr

  @Nils Dein Konstrukt hat noch einen anderen Nachteil: man hebelt IDE, statische Codeanalyse et cetera alles aus. Nicht davon zu reden, dass man Nutzereingaben natürlich weit fern davon halten muss.

  Du solltest das auf ganz bestimmte Klassen und Funktionen beschränken. Ansonsten ist es nicht handhabbar.

  Zum Beispiel auf Klassen, die ein vorgegebenes Interface implementieren. Dort kann man eine Klasse als Fassade vorschalten, welche sich dynamisch die passende Implementierung sucht. Dann kennt man zumindest die Ein- und Rückgabewerte ganz genau und bricht nicht mit den bekannten Analysetools.

• 
  

  Kim

  am 24. Februar 2010 um 10:46 Uhr

  Mit einer halbwegs ordentlich gestalteten modularen Projektstruktur sollte das m.E. nie benötigt werden. Und damit meine ich nicht, man müsse immer ewig seine Projekte planen.

• 
  

  Johannes

  am 24. Februar 2010 um 10:46 Uhr

  Noch eine böse alternative: Statt jedesmal beim Aufruf zu prüfen ob die Funktion da ist – was bei mehrfachen Aufrufen recht teuer ist initial einmal sowas:

  foreach (aaray(‘func1′, ‘func2′, /*…*/) as $func) {
  if (!function_exists($func) {
  eval(“function $func() {}”);
  }
  }

  Wäre antürlich schöner, wenn Fuktionen in PHP first class citizens wären uns sowas ginge:

  foreach (aaray(‘func1′, ‘func2′, /*…*/) as $func) {
  if (!function_exists($func) {
  eval(“function $func() {}”);
  }
  }Und ja. Das ist böse und sollte nicht gemacht werden.
  Aber anhand von bestimmten Funktionen verfügbare Features zu erkennen und das dann evtl. (nicht) aufzurufen wirkt für mich nach ner kaputten architektur wo irgendein Signal-Handling/Hook-Mechanismus angebracht wäre …

• 
  

  Johannes

  am 24. Februar 2010 um 10:48 Uhr

  ups, da hat sich der Copy&Paste Teufel eingeschlcihen, das zweite Beispiel war sowas wie

  if (!function_exists($func) {
  $func = function() {}
  }

  wobei $func = “foo” dann mit der funktion foo identisch sein müsste .. was mit der $-Notation nicht klappt usw. usf.

• 
  

  PHPGangsta

  am 24. Februar 2010 um 11:22 Uhr

  Ich sehe das ähnlich wie Tom. Nur um 15 Zeichen zu sparen verzichte ich nicht auf Codeanalyse, in der IDE das “Draufklicken” auf den Funktionsnamen usw.
  Mit der Lösung kann man auch nur, wenn ich micht nicht irre, Funktionen behandeln. Aufrufe wie method_exists() müßte man nach wie vor auf die “alte” Tour machen.

  Nette Idee, aber hat meiner Meinung nach zuviele Nachteile und keine erkennbaren oder messbaren Vorteile.

• 
  

  Nils Langner

  am 24. Februar 2010 um 11:43 Uhr

  @Tom: Den Weg findest du wirklich schön? Ich verstehe den Ansatz noch nicht mal wirklich, was darauf deuten könnte, dass er zu komplex ist, oder? Oder halt, dass ich aufm Schlauch stehe … was ich nicht ausschließen würde.

• 
  

  KingCrunch

  am 24. Februar 2010 um 12:10 Uhr

  @Johannes: Dein zweites Beispiel geht in 5.3

  @Tom: Funktionen profitieren auch sehr stark von 5.3. ZB kann es einen an vielen Stellen egal sein, ob es eine Funktion, oder ein Objekt mit Methode ist, wenn man Closures verwendet. Lambdas sind auch cool (siehe Johannes’ zweites Beispiel).

  @Tom2: Wo hebelt das die statische Code-Analyse aus? Die eigentliche Funktion würde man ja trotzdem testen, und zwar nicht über die den “call”-Umweg.

  @PHPGangsta: Wieso sollte etwas Vergleichbares nicht für Methoden funktionieren können?

  echo call(array($object, ‘myMethod’), $arg1, $arg2);

  Dass die IDE nicht mehr selbst vervollständigt, halte ich übrigens für nen vernachlässigbares Problem Ausserdem kann man ihr per “@var” auch Tipps geben, so dass es wieder funktioniert.

• 
  

  Norbert Bartels

  am 24. Februar 2010 um 12:20 Uhr

  Also ich denke, dass man function_exists u.ä. Dinge in der OOP nicht wirklich benötigt. Man definiert ein interface und die entsprechende Klasse implementiert dieses. Dadurch kann man vorgeben, ob eine Methode existiert oder nicht.

  Und dann kann ich auch mit instanceof gegen das Interface prüfen. So erhalte ich über diesen Weg eine Zusicherung, ob eine Methode existiert.

• 
  

  KingCrunch

  am 24. Februar 2010 um 12:29 Uhr

  Ein weiteres mal frage ich mich, wieso ihr nicht gleich ne richtige OOP-Sprache verwendet, wenn ihr PHP schon auf OOP reduziert Mit exessiven Einsatz von Type-Hints hätte man auch gleich die Typ-Schwäche ausgehebelt, jetzt noch “HipHop for PHP” und wir brauchen Java garnicht mehr

  Was ich sagen will: Natürlich ^kann^ man rein OOP programmieren und alles mit Interfaces, Type-Hints und instanceof absichern, aber damit nimmt man sich meines Erachtens einen großen Teil der Fähigkeiten, die einen PHP an die Hand gibt. Rein statische Klassen sind sowieso ein völlig unnötiges, künstliches Konstrukt, nur um hinterher zu behaupten, es wär OOP ;P

• 
  

  Norbert Bartels

  am 24. Februar 2010 um 13:38 Uhr

  Stimmt ja, mit type hinting brauche ich das häßliche instanceof sogar rauswerfen

  Statische Methoden kann man ja auch noch benutzen, um sich Schreibarbeit zu sparen. Und man muss kein dummy-Objekt instanziieren, dass man danach eh nicht mehr braucht.

  Java? Wer braucht denn schon Java?

• 
  

  Frank

  am 24. Februar 2010 um 14:07 Uhr

  Als erstes: Danke für die Blumen, zähle ich mich doch nicht zu den Codern, da mein Wissen rein autodidaktisch entstanden ist und ich noch viel zu lernen habe.

  Zum Artikel: ich nutze function_exists() grundsätzlich nie um auf Funktionen anderen Plugins in WP zu prüfen. Ich mache dies nur, wenn ich Funktionen einbinde, die im Laufe der zeit durch andere ersetzt wurde, so dass ich einem gewissen Rahmen abwärtskompatibel bleibe. Plugins prüfe ich über einen Schlüssel im WP, wo man alle aktiven Schlüssel findet.

• 
  

  Nils Langner

  am 24. Februar 2010 um 14:25 Uhr

  @Frank: Bleibst trotzdem mein WordPress Ansprechpartner

• 
  

  Frank

  am 24. Februar 2010 um 14:43 Uhr

  @Nils: das war nicht böse gemeint, nur als Hinweis und damit helfe ich immer gern, egal ob du oder andere Leute – es ist eher ein Zeitproblem. Vielleicht gibt es ja eine andere bessere Lösung und ich habe die Redundanz nicht mehr drin.

• 
  

  Andre Moelle

  am 24. Februar 2010 um 16:43 Uhr

  Eine (un)schöne Lösung für ein unschön kleines Problem, das durch eine unschöne Architektur entstanden ist.

  Will heißen: Deine Lösung liest sich gut, hat aber einige gewichtige Nachteile – wie bereits mehrfach erwähnt.

• 
  

  DSB

  am 24. Februar 2010 um 20:20 Uhr

  Totaler Overkill mit in Summe vermeidbarem Performanceverlust.

  @doSth( $arg1, $arg2 );

  … und fertig.

• 
  

  DSB

  am 24. Februar 2010 um 20:26 Uhr

  Ei, da lag ich leider falsch, da das Script so abgebrochen wird wenn die Funktion nicht existiert. *flööt* Ich hätte nichts gegen eine Löschung des Beitrags.

  Dennoch sehe ich keinen Sinn darin functions_exists in einer Klasse zu kapseln, da nicht zu erwarten ist, dass sich an der grundsätzlichen Aufgabe der Funktion etwas ändern wird oder diese zentral um weitere Aspekte erweitert werden muss. Und das erledigt die simple Funktion function_exists() eben schneller, als der Aufruf einer statischen Klassenmethode.

• 
  

  Julian

  am 24. Februar 2010 um 21:34 Uhr

  @Kim: Würdest du diese vorgeschlagene Struktur mal beschreiben?

• 
  

  Christopher K.

  am 24. Februar 2010 um 22:14 Uhr

  Was mir dabei aufgefallen ist:

  Ich rufe eine Funktion ja meist nicht auf, weil es ganz nett wäre, sie aufzurufen, sondern weil ich sie brauche. Das heißt, wenn es sie nicht gibt, muss ich etwas tun. Sei es einen Fehler ausspucken, eine Exception werfen oder eine andere Funktion verwenden. Und das berücksichtigt diese Lösung hier nicht. Wenn ich mache if(function_exists()) kann ich per else irgendwas anderes tun.
  Einfach im Code weiter zu gehen kann fatale Folgen haben, weil ich ja i.d.R. davon ausgehe, dass die Funktion etwas tut.

  Was das Cachen angeht: Verlockende Idee, so ein Universalcache. Aber wie lange ist der Cache gültig? Was, wenn die Funktion außer einer Rückgabeberechnung noch etwas anderes tut, wie eine Datei schreiben? Was, wenn die Funktion etwas zeitabhängiges tut? Das muss man immer individuell machen mit dem Cachen, ein individueller Cache nutzt nur für einfache Fälle was.

• 
  

  DSB

  am 24. Februar 2010 um 22:25 Uhr

  Im genannten Kontext geht es ja darum PlugIns anzusteuern. Wenn diese nicht erreichbar sind, sollte das die Core-Funktionalität des Hauptskripts nicht beeinflussen, so dass die Vorgehensweise in Ordnung sein sollte.

  Sicherlich könnte man jetzt einen Fall konstruieren, wo ein PlugIn von einem anderen abhängig ist, das übergeordnete nicht verfügbar ist und es dadurch im abhängigen PlugIn knallt. Aber dann sollte das abhängige PlugIn ebenfalls Prüfmethoden für das Vorhandensein des Haupt-PlugIns besitzen, welche dann greifen und es deaktivieren sollten.
  Insofern betrachte ich die Vorgehensweise der Prüfung mit function_exists als legitime und schnelle Möglichkeit.
  Just my 2 Cents.

• 
  

  Simon

  am 24. Februar 2010 um 23:00 Uhr

  Das ist für mich kein OOP, das ist Vergewaltigung von Klassen.
  Auch wenns nett aussieht, sauber ist das nicht

• 
  

  Andi

  am 25. Februar 2010 um 09:08 Uhr

  Hm…also nachdem ich mir die ganze Diskussion durchgelesen habe, erschließt sich für mich immer noch nicht der Nutzen dieser eigentlich interessanten Idee.

  Fazit bleibt für mich:
  1. Fehlermeldungen haben Ihre Daseinsberechtigung und sind beim Debuggen unverzichtbar (siehe Julians Kommentar).
  2. Die Funktion soll etwas tun (siehe Christopher K.)! Ich unterdrücke einen Fehler und meine Daten sind dazu noch unbrauchbar.
  3. Gerade bei einem Plugin kann bei der Installation auf die Systemvoraussetzungen überprüft werden (metalguys Kommentar). -> http://php.net/manual/function.version-compare.php

• 
  

  KingCrunch

  am 25. Februar 2010 um 16:09 Uhr

  Andi:
  1. Wenn eine Funktion nur optional aufgerufen werden soll, wäre ihr Fehlen kein Fehler.
  2. Siehe 1 zB Widgets: Wenns fehlt, fehlts, aber gefährlich isses nicht

• 
  

  Julian

  am 26. Februar 2010 um 00:35 Uhr

  Von Objektorientierung ist in dem Zusammenhang selbstverständlich nicht zu reden. OOP befasst sich mit Objekten (also Instanzen von Klassen) und weniger mit derlei statischen Konstrukten. Das ist oft eine Hintertür in meinen Augen.
  Genau wie einige andere, würde ich in diesem Zusammenhang Fehlerbehandlung kritisieren – die ist nämlich nicht mehr gegeben. In welchem Zusammenhang darf man das Konstrukt verwenden? Nur mit Aufrufen von Plugin-Funktionen? Was ist, wenn ich es mit anderen Funktionen in Verbindung bringe .. schon entstehen Fehler.
  Ich habe vor nicht all zu langer Zeit meinen Professor gefragt, wieso es (in Java) möglich ist, dass eine Instanz einer Klasse auf ein privates Attribut einer anderen Instanz derselben Klasse direkt zugreifen kann, wo man doch ohne direkten Zugriff und über Getter-Methoden eine viel bessere Kapselung erzwingen könnte. Die Antwort war in diesem Zusammenhang: “Programmcode soll sich nicht vor sich selbst schützen / kapseln, sondern vor äußeren Systemen” (sinngemäß). Damit möchte ich sagen, dass es nicht Sinn und Zweck ist, in einer Anwendung jede mögliche Fehlerquelle, die durch Fremdentwickler entsteht, auf Herz und Nieren zu prüfen. Plugins müssen nunmal korrekt entwickelt werden – es darf vor der Installation des Plugin durchaus eine Überprüfung stattfinden, aber eine vollständige Kapselung ist schier unmöglich, so dass immer Fehler auftreten können. Es ist also Aufgabe der Entwickler der Plugins, dieselben so zu entwickeln, dass sie den selben Standards wie die Anwendung selbst entsprechen.
  Man muss hier eben ein Mittelmaß finden und meines Erachtens geht es schon zu weit, jede Funktion eines Plugins auf Existenz zu prüfen, denn man sollte davon ausgehen können, dass, wenn ein Plugin installiert wurde, entsprechende Funktionen zur Verfügung stehen. Dann muss man eben nur korrekte Abhängigkeiten beachten.
  Übrigens weiß die Kern-Anwendung gar nicht von möglichen Funktionen, die ein Plugin zur Verfügung stellt. Nur Plugins können voneinander abhängen und optionale Funktionen aufrufen. Die Kern-Anwendung dagegen sollte ohne Plugins auskommen. Demnach ist es – unter Vorraussetzung, dass ein korrekt eingebundenes Plugin die Funktionen bereitstellt – eine Frage der Abhängigkeit von Plugins, ob ein Plugin eine bestimmte Funktion eines Anderen aufrufen kann. Kern-Funktionen sollten ja vorhanden bleiben.

• 
  

  maz

  am 27. Februar 2010 um 17:49 Uhr

  Hallo, ich muss KingCrunch Recht geben. In PHP kann man viel anstellen, aber nicht alles ist sinnvoll. Ich finde, was man auf eine Weise in PHP aber nicht auch in anderen Sprachen umsetzen kann, sollte man sich zweimal überlegen. Z.B. ist Late Static Binding zwar auf den ersten Blick recht nützlich, aber jeder weiß, dass man für Vererbung/Polymorphie normalerweise ein Objekt benötigt (C++ Entwickler errinnern sich vielleicht an die vtable).
  Durch das richtige Designmuster wird man nie auf Late Static Binduing angewiesen sein. Hinzu kommt, dass ich kein Fan von “Global State” bin und somit statische Dinge sowieso vermeide. (Kann hier nur empfehlen: http://www.youtube.com/watch?v=-FRm3VPhseI)
  Um zum Beitrag noch was loszuwerden: Wieso setzt man kein Eventsystem a la Observer ein? Ein Plugin-System auf Funktionsbasis ist meiner Meinung nach keine gute Wahl, denn wie können sich hier mehrere Plugins für eine Aufgabe registrieren?

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar