Dynamische Methodenparameter

PHP 5.1.4 @Linux
Array
(
[direct] => 0.0220710000
[reflection] => 0.0465050000
[difference] => 0.024434
)

Überraschend! Also ist der Overhead der Reflection gar nicht so groß und offensichtlich weit von einem "mehrere-Sekunden"-Bereich entfernt. Dass das nur Spaßklassen sind ist imho sekundär, für PHP sind die genau so ernst, haben Methoden und sind abgeleitet. Selbst wenn sie umfangreicher wären und es dadurch 8 Mal so lange dauert, wird man sicher trotzdem selten mehr als 1000 Instanzen haben

Habs jetzt selbst mal getestet, und komme zu ähnlichen Ergebnissen (auch mit "echten" Klassen …*wobei hier ein 8000-facher durchlauf ein klitzekleinesbisschen länger läuft ) … da hat sich dann wohl was getan, seit dem ich das letzte mal mit der PHP-Reflection rumgespielt habe.

Leider ist mein Blog grade down, da hatte ich das ganze mal in einem Sniffer verwurstet, der Klassen auf bestimmte Regeln prüft. Ich weiß noch, dass das unendlich langsam war.

Zitat von AmicaNoctis

Das ist aber eine derart versteckte und feste Abhängigkeit, dass es dem Singleton Antipattern in nichts nachsteht und imho noch schlimmer ist, als der Ansatz des TO. Seiner unterstützt dabei wenigstens noch Legacy- und native Klassen.

Die Abhängigkeit steckt hier:

vom TO:
Die Werte der Parameter ergibt sich vorher durch einige Daten aus einer Config.

Ich frage nur, ob die Parameter wirklich im Konstruktor gebraucht werden. Sind sie wirklich notwendig, um das Objekt in den Initialzustand zu versetzen?
Von nativen Klassen sehe ich hier nichts - der TO inkludiert fleißigst.
Legay-Klassen sind das sicher auch nicht. Falls doch, könnte er sich Wrapper erzeugen ... ach was das führt doch schon wieder zu weit. Bleiben wir bei dem was wir wissen: Der TO bastelt so eine Art Autoloader und scheinbar braucht bei ihm jeder Ctor spezifische Parameter, die er in der App-Config abgelegt hat, was nur geht, weil sie schon zur Programmierzeit feststehen.

Wenn man die grunsätzlichen Fehler ausmärzt, sehe ich hier nichts, was über die normale Anwendung eines Autoloaders hinausgeht und für einen Autoloader braucht man i.d.R. keine Reflection.

Ich habe mal aus den vorherigen Codefetzen eine Reflection basierende mini DI Einrichtung gebaut.

Gefallen tut mir das so noch lange nicht....

PHP-Code:

<?php
error_reporting(-1);
ini_set('display_errors', TRUE);
setlocale(LC_ALL,'de_DE@euro', 'de_DE',  'de', 'ge');
date_default_timezone_set('Europe/Berlin');
 


class Combie_DB 
{
}

class Combie_Model_User 
{
    public function __construct(Combie_DB $db) 
    {
        echo 'wurde gerufen<br>';
    }
}

function fabrik(Array $registry,$klassenBezeichner)
{
  $rc = new ReflectionClass($klassenBezeichner);
  $rcconstructorparam=$rc->getConstructor()->getParameters();
  $params = array();
  foreach($rcconstructorparam as $param)
  {
    $p_class = $param->getClass();
    if(empty($registry[$p_class->name])) throw new Exception('bad Param');
    $params[] = $registry[$p_class->name];
  }
  return $rc->newInstanceArgs($params);
}

$registry = array();
$registry['Combie_DB'] = new Combie_DB('blabla');

$die_neue = fabrik($registry,'Combie_Model_User');
    
    
?>

<hr>
<pre>
<?php
 var_export($die_neue);
?> 
</pre>

Da bleibe ich doch lieber bei meinen alten DI Containern...
Evtl später mal um die php5.3 Closures/Lambdas aufgemotzt.

Zitat von Quetschi

PHP 5.1.4 @Linux
Array
(
[direct] => 0.0220710000
[reflection] => 0.0465050000
[difference] => 0.024434
)

Nach Update auf 5.2.8 deutlich langsamer

Array (
[direct] => 0.0530550000
[reflection] => 0.1483920000
[difference] => 0.095337
)

Ich habe mal eine Frage zu dem Thema. Die Sache mit dem Autoload und der SPL wurde ja schon angesprochen. Spricht irgend etwas dagegen es über diesen Weg zu lösen?

Der SPL-Autoload-Mechanismus ist die momentane Best Practise. Aber was genau willst du damit lösen? Das Laden von Klassen oder wie der TO irgendwelche Injections?

Also so wie ich das verstanden habe, initiiert der TO verschiedene Klassen, die natürlich verschiedene Parameter im Konstruktor haben können. Ich habe darüber letztes Jahr mal 'n Blogbeitrag geschrieben.

Danach kann ich doch alle Klassen, sofern sie in einer entsprechenden Verzeichnisstruktur aufbereitet sind, mit den entsprechenden Parametern initiieren und muss dies nicht umständlich über die vom TO beschriebene Klasse tun.

Irgendwie habe ich gerade Angst, dass ich total am Thema vorbei denke.

Du verwechselst initiieren mit instanziieren, aber das nur nebenbei

Inwiefern hat denn die Verzeichnisstruktur der Klassendateien etwas mit deren Konstruktorparametern zu tun? Und was hat das mit Autoloading zu tun. Autoloading ist für das Laden zuständig, nicht für automatische Instanziierung. Bitte aufklären.

Autoloading hat doch den enormen Vorteil, dass ich Klassen nicht mehr per require einbinden muss. Genau das macht ja der TO. Er bindet bei Bedarf die im Array festgehaltenen Klassen ein und instanziert sie mit den im Array festgehaltenen Parametern.

Mit Autoloading kann ich eine Klasse egal von welchem Ort automatisch laden und erspare mir das übergeben der Parameter über eine gesonderte Klasse oder Funktion.

Was hat die Ordnerstruktur damit zu tun? Ich habe mir angewöhnt meine Klassen in umfangreichen Projekten nach der Verzeichnisstruktur zu benennen. Ähnlich wie es das Zend Framework auch tut.

Beispiel:
Die Klasse DataUserEditor liegt nach dem Klassennamen dann im Verzeichnis Lib/Data/User und hat den Dateinamen Editor.class.php. Meine Autoload Funktion bröselt den Klassennamen dann entsprechend auf. Deswegen auch eine durchdachte Verzeichnisstruktur, wie sie in diesem Thread schon mal kurz angesprochen wurde.
Direkt mit den Konstruktorparametern hat dies natürlich nichts zu tun.

Zitat von ezkimo

Mit Autoloading kann ich eine Klasse egal von welchem Ort automatisch laden und erspare mir das übergeben der Parameter über eine gesonderte Klasse oder Funktion.

Was denn für Parameter?

Deine Erklärung (soweit ich sie verstanden habe) klingt nach dem ganz normalen Verfahren, wie man SPL Autoloading vor PHP 5.3 üblicherweise benutzt hat. Ich verstehe also nicht ganz, worauf du hinaus willst.

Der TO hatte da ja noch ganz andere Sachen im Sinn. Nur zum Verständnis: das meinst du nicht, ja?