Chaining in Symfony

Lesetipps

1. Projektwerkstatt: Symfony Konfigurator
2. Symfony Components
3. Setter sind keine getter … auch symfony macht mal Fehler

Durch meinen neuen Job komme ich ja in letzter Zeit immer öfters mit Symfony in Kontakt und ich muss sagen, dass es mir ganz gut gefällt. Wirklich tief bin ich noch nicht wirklich eingestiegen in die Materie, aber meinen ersten WTF habe ich schon gefunden. Es ist nichts schlimmes. Es geht einfach um eine wirklich übermäßige Nutzung von Chaining (flüssiges Interface). Interfaces so flüssig wie möglich zu halten ist natürlich eine angenehme Sache, aber was die Jungs von Symfony in ihren Funktionalen Tests machen finde ich wirklich übertrieben. Aber ich zeige einfach mal das Beispiel, dass ich so besonders fand:

$browser->info('1 - The homepage')->
  get('/')->
  with('request')->begin()->
    isParameter('module', 'job')->
    isParameter('action', 'index')->
  end()->
  with('response')->begin()->
    info('  1.1 - Expired jobs are not listed')->
    checkElement('.jobs td.position:contains("expired")', false)->
  end()
;

Schaut man sich das ganze mal genau an, sieht man, dass es sich hier genau um einen Ausdruck handelt. Ich meine er ist schön Eingerückt und so wie er da steht auch übersichtlich. Aber das kann auch ganz schön in die Hose gehen. So ein Ausdruck in den Händen eines PHP Neulings? Oh mein Gott. Komisch finde ich auch, dass sogar Kontrollstrukturen (begin, end) in Methoden gepackt wurden.

Vielleicht hat ja jemand von euch Erfahrung mit dem Testing-Framework gemacht und möchte mal ein paar Worte dazu sagen. Für mein Gefühl ist es auf jeden Fall ziemlich unübersichtlich.

9 Kommentare »

• 
  

  Jan

  am 21. April 2009 um 09:43 Uhr

  Wenn ich mich recht erinnere kannst du auch jeden Schritt davon wieder neu als $browser->foo(); schreiben – aber das ist einiges an Tipparbeit da du ja immer und immer wieder auf dem selben Objekt arbeitest.

  Meine Erfahrung war, dass dieses Chaining hilft das “Programmieren” dabei zu vergessen und mehr als Browser zu denken. Aufruf->Klick->Feld_prüfen->Beenden.

• 
  

  Nils Langner

  am 21. April 2009 um 12:41 Uhr

  Ok, das kann gut sein, aber fies ist es trotzdem

• 
  

  Lukas

  am 21. April 2009 um 16:26 Uhr

  Unglaublich.. geht ja gar nicht. Jede dieser Funktionen gibt also das Objekt selbst wieder zurück – wie sinnlos. Spart überhaupt keine Codezeilen.

• 
  

  Jan

  am 21. April 2009 um 17:30 Uhr

  Das versteh ich nun nicht, wieso das keinen Code spart. Man spart sich doch immer wieder das $browser, oder?

• 
  

  admin

  am 21. April 2009 um 18:08 Uhr

  Er sagt ja nur, dass es keine CodeZEILE spart Code spart es auf jeden Fall.

• 
  

  Jan

  am 21. April 2009 um 18:09 Uhr

  Ach, genauer lesen…

• 
  

  Ueberlein

  am 21. April 2009 um 20:30 Uhr

  Fluid Interfaces scheinen auf dem Vormarsch zu sein. Fein, ich persönlich finde, dass der Code dadurch an Lesbarkeit gewinnt – vorausgesetzt man rückt vernünftig ein. Was bislang noch gegen einen exzessiven Einsatz spricht, ist das ein unbeteiligter Dritter allein durch die Betrachtung des Setter-Aufrufs nicht unbedingt erwarten kann, dass die Methode ein this zurückgibt. Dem könnte man vielleicht entgegenwirken, indem man einen neuen Operator einführt, der einen möglichen Rückgabewert der Methode ignoriert und stattdessen stets das Methodenobjekt zurückgibt. In Anlehnung an den -> Operator beispielsweise so:

  $myObject=>doThis()=>doThat();

  Das hätte zusätzlich den Vorteil, dass man Fluid Interfaces auch in Klassen nutzen könnte, die eigentlich gar nicht dafür vorgesehen sind. Aber vielleicht ist das auch alles Humbug weil man die Sprache dadurch wieder unnötig überfrachten würde…also schmeißen wir die Idee besser mal wieder über Bord

  Salbungsvolle Grüße nach Hamburg!

  PS: stehe ich hier eigentlich alleine mit meiner Meinung, dass ein Preview Button und eine ordentliche Codeformatierung, potentiellen Kommentarschreibern entgegenkommen würde?

• 
  

  Artem

  am 20. April 2010 um 11:47 Uhr

  @Ueberlein

  Ich würde sagen das deine Methode nicht funktionieren würde, denn es ist ja nicht immer das gleiche Object was man erwartet. Was ist mit den Getter Methoden die wahrscheinlich andere Objekte zurückliefern.

  Glücklicherweise ist es mit einer vernünftigen IDE möglich auch durch diese extravagante Verkettungen durchzublicken … Stichwort TypeHints und DocBlocks

• 
  

  b00giZm

  am 20. April 2010 um 12:19 Uhr

  Doctrine setzt in seinem Query-Builder auch auf Chaining und ich finde es persönlich recht komfortabel.

  Abgesehen davon, dass es Tipparbeit spart, finde ich diese Art und Weise zu programmieren sogar recht intuitiv und gut lesbar (ein gutes Beispiel dafür ist imho das Chaining innerhalb von jQuery).

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

Einen Kommentar hinterlassen