Kommentare zu: Methoden-Templates mit __call() erstellen https://blog.ebene7.com/2010/09/27/methoden-templates-mit-call-erstellen/ Wed, 19 Dec 2018 08:31:45 +0000 hourly 1 http://wordpress.org/?v=3.2.1 Von: Ralph Meier https://blog.ebene7.com/2010/09/27/methoden-templates-mit-call-erstellen/comment-page-1/#comment-947 Ralph Meier Fri, 01 Oct 2010 15:51:17 +0000 http://blog.ebene7.com/?p=1468#comment-947 Wir hatten intern gerade vor kurzem bei uns im Geschäft die Diskussion, was die Vorteile/Nachteile von Magic Methoden sind. Danke für die interessanten Kommentare. Ich bin auch eher der Meinung, dass Magic Methoden mehr Probleme schaffen, als das sie helfen. Wir hatten intern gerade vor kurzem bei uns im Geschäft die Diskussion, was die Vorteile/Nachteile von Magic Methoden sind. Danke für die interessanten Kommentare. Ich bin auch eher der Meinung, dass Magic Methoden mehr Probleme schaffen, als das sie helfen.

]]> Von: steffkes https://blog.ebene7.com/2010/09/27/methoden-templates-mit-call-erstellen/comment-page-1/#comment-921 steffkes Tue, 28 Sep 2010 17:23:25 +0000 http://blog.ebene7.com/?p=1468#comment-921 man mag ja über doctrine sagen was man will .. aber ich würde doch stark davon ausgehen, dass die nicht einfach nur der laune halber die ganzen magic getter & setter beim umstieg von doctrine1 auf doctrine2 entfernt haben .. man mag ja über doctrine sagen was man will .. aber ich würde doch stark davon ausgehen, dass die nicht einfach nur der laune halber die ganzen magic getter & setter beim umstieg von doctrine1 auf doctrine2 entfernt haben ..

]]> Von: Steffen https://blog.ebene7.com/2010/09/27/methoden-templates-mit-call-erstellen/comment-page-1/#comment-913 Steffen Mon, 27 Sep 2010 20:14:29 +0000 http://blog.ebene7.com/?p=1468#comment-913 Ich seh das wie Harald. Es ist Teufelszeug! Es kostet Dich Performance, Wartbarkeit und Debuggen macht auch kein Spaß. Doctrine1 verwendet es zahlreich und wenn man wirklich mal, weil etwas schief gegangen ist, tracken will, ob es vielleicht einfach nur ein Fehler in Doctrine steckt, dann brauch mal reichlich Geduld. @Daniel: von Magento habe ich nicht viel gutes gehört und Deine Aussage unterstützt dieses schlechte Bild, was ich habe, nur. OFFTOPIC: Übrigens bin ich mir auch noch nicht wirklich sicher, ob Closures eine gute Erfindung haben. Vermisst habe ich sie vor 5.3 auch nicht wirklich. Ich seh das wie Harald. Es ist Teufelszeug! Es kostet Dich Performance, Wartbarkeit und Debuggen macht auch kein Spaß. Doctrine1 verwendet es zahlreich und wenn man wirklich mal, weil etwas schief gegangen ist, tracken will, ob es vielleicht einfach nur ein Fehler in Doctrine steckt, dann brauch mal reichlich Geduld.

@Daniel: von Magento habe ich nicht viel gutes gehört und Deine Aussage unterstützt dieses schlechte Bild, was ich habe, nur.

OFFTOPIC: Übrigens bin ich mir auch noch nicht wirklich sicher, ob Closures eine gute Erfindung haben. Vermisst habe ich sie vor 5.3 auch nicht wirklich.

]]> Von: Daniel https://blog.ebene7.com/2010/09/27/methoden-templates-mit-call-erstellen/comment-page-1/#comment-912 Daniel Mon, 27 Sep 2010 18:03:21 +0000 http://blog.ebene7.com/?p=1468#comment-912 Hehe, hätte mich gewundert, wenn der Artikel nicht derartige Reaktionen hervorgebracht hätte. @Jens-André: Dein Ansatz klingt zwar erstmal gut und logisch, dennoch würde ich dann doch lieber vollständige Codegeneration vorziehen, als zur Laufzeit an den Klassen rumzumachen. @Harald: Sag das mal den Leuten von Varien/Magento... Hehe, hätte mich gewundert, wenn der Artikel nicht derartige Reaktionen hervorgebracht hätte.

@Jens-André: Dein Ansatz klingt zwar erstmal gut und logisch, dennoch würde ich dann doch lieber vollständige Codegeneration vorziehen, als zur Laufzeit an den Klassen rumzumachen.

@Harald: Sag das mal den Leuten von Varien/Magento…

]]> Von: Jens-André Koch https://blog.ebene7.com/2010/09/27/methoden-templates-mit-call-erstellen/comment-page-1/#comment-910 Jens-André Koch Mon, 27 Sep 2010 16:16:35 +0000 http://blog.ebene7.com/?p=1468#comment-910 Never Say Never Again. Richtig ist, für die IDE's sind zusätzliche Annotationen notwendig. Richtig ist auch, dass jeder Magic-Call Performance frisst. Hinzu kommt noch der Performanceverlust durch das Namens-Matching mittels Regular-Expressions. Die Frage lautet also, wie kann ich Methoden für Models haben, die ich nicht kenne. Antwort: _call. Haufenweise Kommentare/Aufregung.... ,) Aber wie kann ich die Methodenerstellung und die Annotationserstellung automatisieren und die Wartbarkeit wiederherstellen? Sowohl die Annotationen, aber auch die eigentlichen Methoden die über _call aufgerufen werden, kann man automatisch erstellen lassen. Und zwar bei einer erfolgreichen Delegation, denn man kennt den Methodennamen und die Parameter. Diese Angaben kann man verwenden, um mittels Scaffolding (hat auch was mit Methoden-Templates zu tun ,) die Methode selbst zu schreiben! Günstig ist folgendes Verfahren: _call() Methode in der Parentklasse unterbringen. Per Scaffolding eine Kindklasse zur Abfrage des Models schreiben und bei erfolgreichen _calls die Methoden in diese Klasse. Dadurch reduzieren sich die Erstellungkosten, die Performancenbremsen werden rausgeworfen, die Wartbarkeit steigt automatisch an und die IDE erkennt nach und nach alle verfügbaren Methoden. Gruß Jens Never Say Never Again.

Richtig ist, für die IDE’s sind zusätzliche Annotationen notwendig. Richtig ist auch, dass jeder Magic-Call Performance frisst. Hinzu kommt noch der Performanceverlust durch das Namens-Matching mittels Regular-Expressions.

Die Frage lautet also, wie kann ich Methoden für Models haben, die ich nicht kenne. Antwort: _call.
Haufenweise Kommentare/Aufregung…. ,)

Aber wie kann ich die Methodenerstellung und die Annotationserstellung automatisieren und die Wartbarkeit wiederherstellen?

Sowohl die Annotationen, aber auch die eigentlichen Methoden die über _call aufgerufen werden, kann man automatisch erstellen lassen. Und zwar bei einer erfolgreichen Delegation, denn man kennt den Methodennamen und die Parameter. Diese Angaben kann man verwenden, um mittels Scaffolding (hat auch was mit Methoden-Templates zu tun ,) die Methode selbst zu schreiben!

Günstig ist folgendes Verfahren: _call() Methode in der Parentklasse unterbringen. Per Scaffolding eine Kindklasse zur Abfrage des Models schreiben und bei erfolgreichen _calls die Methoden in diese Klasse. Dadurch reduzieren sich die Erstellungkosten, die Performancenbremsen werden rausgeworfen, die Wartbarkeit steigt automatisch an und die IDE erkennt nach und nach alle verfügbaren Methoden.

Gruß Jens

]]> Von: Harald https://blog.ebene7.com/2010/09/27/methoden-templates-mit-call-erstellen/comment-page-1/#comment-908 Harald Mon, 27 Sep 2010 14:47:59 +0000 http://blog.ebene7.com/?p=1468#comment-908 Nie, Nie, Nie, so was in einem größeren Projekt benutzen. Es gibt IMHO keinen einzigen use-case der so etwas rechtfertigt! Der Verlust an Wartbarkeit ist einfach zu groß. Ich sag dann immer zu meinen Azubis: Faules Mädchen langes Fädchen. Nie, Nie, Nie, so was in einem größeren Projekt benutzen. Es gibt IMHO keinen einzigen use-case der so etwas rechtfertigt! Der Verlust an Wartbarkeit ist einfach zu groß. Ich sag dann immer zu meinen Azubis: Faules Mädchen langes Fädchen.

]]> Von: jami https://blog.ebene7.com/2010/09/27/methoden-templates-mit-call-erstellen/comment-page-1/#comment-906 jami Mon, 27 Sep 2010 11:52:57 +0000 http://blog.ebene7.com/?p=1468#comment-906 Ich finde das solche late binding Mechanismen die Lesbarkeit des Codes stark einschränken. Die Kopplungen sind sehr schwer zu erkennen. Vor allem findet sie kein automatisiertes Tool. Die selbe Technik habe ich in diversen CMS Systemen gesehen mit dicken Regexblöcken in __call. Meiner Meinung nach ist das einfach nicht strikt genug und erhöht die Fehlerquellen für einen zu geringen Nutzen. Ich finde das solche late binding Mechanismen die Lesbarkeit des Codes stark einschränken. Die Kopplungen sind sehr schwer zu erkennen. Vor allem findet sie kein automatisiertes Tool. Die selbe Technik habe ich in diversen CMS Systemen gesehen mit dicken Regexblöcken in __call. Meiner Meinung nach ist das einfach nicht strikt genug und erhöht die Fehlerquellen für einen zu geringen Nutzen.

]]>