Klasse dynamisch mit Funktionen erweitern

[christoph_999]

Hallo an alle.
Melde mich nach laanger Zeit wieder.

Ok, ich bin jetzt nach etwa 2 Wochen immer wieder Herumsuchen noch immer nicht klüger als zu Beginn.
Sogar andersrum: ich werde immer verwirrter.
Ich hab mir Dinge durchgelesen wie PHP Namespaces, Visitor Pattern, Decorator Pattern, Magic Methoden (zB: __get, __set), overloading, call_user_function , elendiglich viele Beiträge über das Erstellen eines Pluginsystems, auch hier im Forum.
Aber irgendwie blicke ich je mehr ich lese und probiere - immer weniger durch.

Das was ich machen möchte, ist eigentlich gar nicht so abwegig.
Ich möchte Dritten die Möglichkeit geben, ohne dass sie die Klasse verändern müssten, etwas einzubringen.

Als Beispiel nehme ich ganz simpel: eine Klasse, die eine Zahl nach und nach manipuliert.
Ich werde versuchen, es so einfach wie nur irgendwie möglich darzustellen.

class Produktpreis {

    function Produktpreis($produktID) {
        // Abfrage in der Datenbank nach dem netto-Preis - der Einfachheit halber lass ich die ganzen Abfragen weg
        // heraus kommt eine Zahl
        $this->preis = $resultat_aus_db_abfrage;
    }

    function steuer() {
        //Rechne auf den Preis dann Steuer auf
        // Abfrage in der Datenbank nach dem Steuersatz
        $this->preis = $this->preis * $resultat_aus_db_abfrage;
    }
    // und so weiter, es würde immer wieder $this->preis manipuliert

    

    // Nun möchte ich aber, dass die nächste Funktion von extern kommt, wie ein Plugin
    // die Funktion könnte zB so aussehen:
    function rabatt() {
        //Reduziere den Preis um irgendeinen Rabatt
        // Abfrage in der Datenbank nach dem Rabatt
        $this->preis = $this->preis - $resultat_aus_db_abfrage;
    }

    // und so weiter

} 

in einer anderen Datei möchte ich nun den Preis abfragen.
Ganz klassisch würde ich nun die Aufrufe abarbeiten:

include('die_klasse_die_sich_mit_dem_preis_beschaeftigt.php');

$produktID = '64837483';
$produktPreis = new ProduktPreis( $produktID );
$produktPreis->steuer();
$produktPreis->rabatt();
echo $produktPreis->preis; 

das wäre der "normale" Weg, ohne etwas dynamisch da hineinzubekommen, alles hardgecoded


aber was wäre, wenn jemand anderer hier in diese Klasse dynamisch eine Funktion, sagen wir: die Funktion rabatt, oder auch: alle Funktionen hier reinintegrieren möchte.
sodass der Aufruf in der anderen Datei immer gleich bleiben kann:

$produktPreis = new ProduktPreis( $produktID );
// inkludiere nun alle Funktionen von einem bestimmten Ort, zB: /ProduktPreis/*.functions.php
// könnten auch mehrere verschiedene Dateien mit je einer Funktion sein.
// der Preis wird kontinuierlich manipuliert und mit Steuer, Rabatt, Sympathiebonus, Produktnachlass und sonstigem anderem Zeugs versorgt
// und zum Schluss:
echo $produktPreis->preis; 

wie stelle ich sowas an?
ich hab mir noch was komplett anderes überlegt, alles in separaten Klassen zu machen und sie alle zu extenden:

class a extends b
class b extends c
class c extends d
// und so weiter, würde auch zum gleichen Ergebnis führen, allerdings:
// der Aufruf würde sich dann ändern: anstatt dass ich sie aufrufe mit:

$obj = new a;

// müsste ich dann den Aufruf mit:
$obj = new d;
// machen 

Versteht ihr mein Dilemma?
Ist doch wieder eine Sackgasse.
Entweder müsste sich der andere an den Klassen zu schaffen machen.
Oder er müsste dann überall den Aufruf abändern.

Hab mir noch etwas überlegt:

Damit der Aufruf dann trotzdem immer der gleiche bleibt, fange ich hintenrum an:

class a extends b
class b extends c
class c extends finalklasse

// es bliebe der Aufruf dann immer der gleiche:
$obj = new finalklasse;
// aber: derjenige müsste dann auch immer wieder nachkorrigieren, welche Klasse nun wo extendet.

// käme dann etwas dazu, dann müsste er:
class a extends b
class b extends andereklasse
class andereklasse extends finalklasse
// machen, was dann auch wieder verkompliziert und zu keinem brauchbaren Ergebnis führt. 

Boa, ich wär für Hilfe sowas von dankbar, das könnte meine Odyssee vielleicht beenden.
Ich weiss echt nicht mehr, in welche Richtung ich denken soll.
Wie realisiert man sowas?

Danke schon im Voraus für Hilfe.

[Frank]

Wie du ja schon mitbekommen hast, kannst du solche Systeme auf verschiedene Art und Weise umsetzen.
Eine Alternative zu deinen Ansätzen wären zum Beispiel Hooks.

// und so weiter, würde auch zum gleichen Ergebnis führen, allerdings:
// der Aufruf würde sich dann ändern: anstatt dass ich sie aufrufe mit:

$obj = new a;

// müsste ich dann den Aufruf mit:
$obj = new d;

Das ist richtig. Welche Klasse du tatsächlich instantiierst (a,b,c oder d) wird im Normalfall von außen konfiguriert und dann zum Beispiel durch eine Factory abstrahiert.


Wenn du es unbedingt so lösen möchtest wie du schreibst, dann fällt mir dafür nur dynamisches Laden von Traits zur Laufzeit ein. Das ist in PHP aber eigentlich (aus gutem Grund) nicht vorgesehen und lässt sich nur durch Misbrauch von eval oder include umsetzen.

[litterauspirna]

Moin,

wie Frank schon angesprochen hat sind da Hooks und Events ne recht gut Geschichte das umzusetzen.

Das könnte zB. dann auch mal so aussehen.

class CalculateByDiscount
{
    private $result;

    private $price;

    private $discount;

    public function getResult()
    {
        /**
         * CalculateResult = Event Klasse
         * $this = Objekt in dem du grad bist
         * manipulateResult = Methode welche hier greifen soll und in der CalculateResult Klasse definiert ist
         * before = Zeitpunkt wann der Wert manipuliert werden soll
         */
        $this->eventDispatcher("CalculateResult", $this, "manipulateResult", "before");
        
        $this->result = ($price - $discount);
        
        $this->eventDispatcher("CalculateResult", $this, "manipulateResult", "after");
    }
}

class CalulateResult
{
    private $object;
    
    public function setObject($object)
    {
        $this->object = $object;
    }
    
    public function manipulateResult()
    {
        return $this->object->result;
    }
} 

Du musst dich natürlich noch um einen Event Dispatcher welcher Hooks und Events verarbeiten kann kümmern, dass hier sollte nur ein Mini Beispiel sein wie man es machen kann.

Ich kann dir aber auch empfehlen dir mal Shopware 4 anzuschauen, die machen das dort mit Datenbankunterstützung. Ich fand die Idee und das Konzept dahinter recht gut.

Gruß Litter

[Gast]

das wäre der "normale" Weg, ohne etwas dynamisch da hineinzubekommen, alles hardgecoded

Dieses Konzept ist völlig falsch. Da fehlt die Idempotenz. Wenn Du steuer() mehrfach aufrufst, verändert sich jedes Mal der Preis. Die Klasse sollte auch nicht selber irgenwelche Daten abfragen (Wie z. B. den Steuersatz).

Ein sauberes Vorgehen wäre dieses hier:

Bsp.:

/**
 * Kommt aus der Datenbank und hat den Preis und Steuersatz als Attribut
 */
class Product
{
    public function getPrice()
    {
        return //...
    {
}

class ProductPriceCalculator
{
    __construct(Product $product, $discount)

    public function getFinalPrice()
    {
        $price = $product->getPrice();
        $tax = $price * $product->getTaxRate();

        return $price + $tax + $product->getDiscount();
    }

    ...
}

// Alternativ
class ProductPriceCalculator
{
    __construct(Product $product, $discount, $taxRate)

    public function getFinalPrice()
    {
        $price = $product->getPrice();
        $tax = $price * $this->taxRate;

        return $price + $tax + $product->getDiscount();
    }

    ...
} 

Damit hast Du auch sämtliche impliziten Abhängigkeiten aufgelöst. Die Berechnung könnte evtl. noch in Product statt finden. Allerdings ist Product eine Entität und die Geister scheiden sich, ob diese nun auch Operationen auf Basis ihrer Daten vornehmen können soll.

Wer auch immer nun den Calculator erweitern, in einer Komposition verwenden oder dekorieren möchte, dem steht das völlig frei.


Allerdings habe ich noch nicht den Zusammenhang zwischen "Klasse dynamisch erweitern" und dem von Dir beschriebenen erkannt

[rkr]

Distanziere dich bitte unbedingt von irgendwelchen Event-Hook-Systemen. Die führen nur schnell zu Unübersichtlichkeit und erhöhen den Wartungsaufwand. Mach es ganz einfach. Wenn du ein Problem hast, dann schaffe da eine dezidierte Lösung für. Schau dir dazu die SOLID-Prinzipen an. Als guter Softwareentwickler solltest du gewohnt sein, komplexe und undurchsichtige Probleme in atomare und damit einfach lösbare Probleme zu zerlegen.

Als Basis hast du eine Klasse, die dir gewisse Grundinformationen bereitstellt. Zum Beispiel den NettoVK. Da drum baust du dann eine Klasse, die dir einen Brutto-Preis bereitstellt. Diese Klasse weiß dann auch, wie Steuern behandelt werden und welcher Steuersatz angewandt werden sollte. Erstellt werden solche Klassen von Fabriken, die austauschbar sind [1]. Das heißt, dass jemand, dem du erlauben willst eine Implementation durch eine andere zu ersetzen, nur die Fabrik ersetzen muss. Schau dir dazu mal DependencyInjection an. Die Grundidee hinter diesem Ansatz heisst Separation of Concerns und Inversion of Control.

Diese Vereinzelung der Zuständigkeiten ist anfangs zwar mit mehr Aufwand verbunden, zeigt später aber Wirkung bei der Implementation neuer Features.

[1] Austauschbar wird eine Implementation zum Beispiel durch den Einsatz von Dependency Injection Containern. Hier wird eine theoretische Fabrik mit einer konkreten Implementation definiert. Die Entität, die diese Fabrik erstellt, wird _nicht_ von einem DiC verwaltet.

Pseudocode-Beispiel:

$productId = '64837483';

$productFactory = $dic->get(Product/Factory::class); // Product\Factory ≙ Interface
$product = $productFactory->get($productId);

$taxClassFactory = $dic->get(Product/Tax/Factory::class); // Product\Tax\Factory ≙ Interface
$taxClass = $taxClassFactory->get($product->getTaxClassId());

$priceFactory = $dic->get(Product/Price/Factory::class); // Product\Price\Factory ≙ Interface
$price = $priceFactory->create($product, $taxClass);

printf("Netto: %.2f; Brutto: %.2f; Enth. Steuern: %.2f\n", $price->getNet(), $price->getGross(), $price->getTaxTotal()); 

[Gast]

Distanziere dich bitte unbedingt von irgendwelchen Event-Hook-Systemen.

Das würde ich in dieser Pauschalität nicht stehen lassen. Was man auf keinen Fall machen sollte, ist, den Ablauf des Programms von einem Listener beeinflussen zu lassen.

$taxClass = $productFactory->get($product->getTaxClassId()); 

Du meinst $taxClassFactory, oder?

[litterauspirna]

Was man auf keinen Fall machen sollte, ist, den Ablauf des Programms von einem Listener beeinflussen zu lassen.

Was genau meinst du damit bitte?

[BlackScorp]

ich glaube sowas sollte man vermeiden

https://github.com/Opentribes/Core/b...odule.php#L126

in einem listener das resultat verändern??

[rkr]

$taxClass = $productFactory->get($product->getTaxClassId()); 

Du meinst $taxClassFactory, oder?

Danke. Habe es geändert.

Das würde ich in dieser Pauschalität nicht stehen lassen.

Bezogen auf das Thema.

[G.Schuster]

    public function getFinalPrice()
    {
        $price = $product->getPrice();
        $tax = $price * $product->getTaxRate();

        return $price + $tax + $product->getDiscount();
    } 

Ein Brutto-Rabatt? Na ja, wem's gefällt.

Ihr redet hier von Vereinfachung, aber an "Filter" denkt keiner.

class Product {
    protected $_price = 0.00;
    protected $_tax = 19;
    protected $_filters = array();
    public function registerFilter($callback) {
        if(is_callable($callback) {
            $this->_filters[] = $callback;
        }
    }
    public function getTax() {
        return $this->_tax;
    }
    public function getNet() {
        $price = $this->_price;
        foreach($this->_filters as $filter) {
            $price = call_user_func($filter, $price);
        }

        return $price;
    }
    public function getGross() {
        return $this->getNet() * (1 + ($this->getTax() / 100));
    }
}

$product = new Product(/*...*/);
$product->registerFilter(function($price) { return $price * 0.9; }); // 10% Rabatt auf den Preis
echo $product->getNet().' / '.$product->getGross(); 

K.I.S.S.!

Im Übrigen sind Entities keine dummen Datenhalter sondern sollen durchaus auch "Behavior" zeigen.

[rkr]

Naja, "Filter" ist hier auch nur eine Variante eines "Event-Dispatcher"s.

[Gast]

Ein Brutto-Rabatt? Na ja, wem's gefällt.

Himmel, das war ein Beispiel... Hast Du zufällig auch noch ein paar Rechtschreibfehler gefunden, die Du korrigieren möchtest?

Im Übrigen sind Entities keine dummen Datenhalter sondern sollen durchaus auch "Behavior" zeigen.

Hier gehen die Meinungen auseinander. Wenn man bedenkt, dass jede Klasse _eine_ Funktion haben soll, dann widerspricht das dem. Entity -> Datenhaltung.

Was ist denn an Deiner Lösung simpler? Du brauchst doch dann letzten Endes ebenfalls mehr Filter. Und diese müssen ja auch irgendwo herkommen.

[G.Schuster]

Wenn man bedenkt, dass jede Klasse _eine_ Funktion haben soll, dann widerspricht das dem. Entity -> Datenhaltung.

Ein Hund ist eine Entität, wer soll für ihn bellen?
Eine Entität ist mitnichten ein reiner Datenhalter, sonst bräuchte es weder DTOs noch DAOs noch sonstwas.

Was ist denn an Deiner Lösung simpler? Du brauchst doch dann letzten Endes ebenfalls mehr Filter. Und diese müssen ja auch irgendwo herkommen.

Was ist wohl simpler, ein paar anonyme Funktionen an einer zentralen Stelle zu übergeben oder über Factories und zig Klassen zu gehen?

[rkr]

Ein Hund ist eine Entität, wer soll für ihn bellen?

Sorry, aber das ist echt ein blödes Beispiel Klar ist der Hund eine Entität, und klar soll der Hund bellen können. Er kann aber auch Stöckchen holen, fressen, trinken, knurren, Zeitung holen, Katzen jagen, Socken reißen, Flöhe beißen, im Kreis laufen, schlafen, jaulen, Gassi gehen, oder sitzen.

Manche können dann noch blinde führen, Drogen aufspühren oder Herden zusammentreiben.

Der Bauarbeiter. Ist er eine Entität? Der kann dann noch mehr als der Hund.

Das ist Verhalten. Wie du deine Anwendungsdomäne designst, ist dir überlassen. Vielleicht braucht deine Anwendung nicht viel. Vielleicht muss der Hund bei dir nur bellen können. Alles ok. Ich sehe das auch nicht immer so dogmatisch, wie das hier vielleicht rüber kommt. Letztlich sollte man sich immer die Frage stellen, ob man sich für den jeweiligen Fall nicht einfach zu viel vornimmt und die Lösung ein möglicherweise hohes Abstraktionsniveau gar nicht benötigt. Und da kommen wir zu dem eigentlichen Punkt. Wenn man einen fest vorgegebenen Anwendungsumfang hat (was eher selten der Fall ist), dann kann man sich auf gewisse Vereinfachungen der Architektur einlassen. Wenn man im Vorfeld nicht weiss, in welche Richtung eine Applikation wachsen wird, dann ist es eher schlecht, wenn alle Komponenten ein niedriges Abstraktionsniveau haben.

Und ja, das "Bellen des Hundes" kann man sehr wohl abstrahieren. Genau so, wie du "Hund" abstrahieren kannst. Später hast du dann ein "Tier", welches per DI das Behavior "Bellen" injiziert bekommen hat. So kannst du dir leicht verschiedene Tiere zusammenpuzzlen.

Eine Entität ist mitnichten ein reiner Datenhalter, sonst bräuchte es weder DTOs noch DAOs noch sonstwas.

Das verstehe ich jetzt nicht. Datamappern ist es doch erst mal egal, ob die zu befüllenden Objekte Bahavior haben, oder nicht!?

Was ist wohl simpler, ein paar anonyme Funktionen an einer zentralen Stelle zu übergeben oder über Factories und zig Klassen zu gehen?

Das Problem ist immer, dass man so schnell zu Ergebnissen kommt, später dann aber um so länger braucht, weil man die ganzen Zusammenhänge nicht mehr klar vor sich hat.

[christoph_999]

Melde mich zurück

Ich möchte mich zuerst bei Frank, litterauspirna und xm22 bedanken für die schnellen Antworten (die ersten 3 Antworten).

Ich bin leider mit dem "Abarbeiten" eurer Antworten nicht so schnell vorangekommen. Jede Antwort hat auch wieder neue Fragen aufgeworfen, denen ich nachgegangen bin.

Ich habe zuerst versucht, das Model von litterauspirna umzusetzen, als Hook. Habe PEAR installiert und dort mit dem Event-Dispatcher probiert. Jedoch ohne Erfolg, ich habe ihn entweder nicht verstanden oder der Event-Dispatcher aus PEAR kann das nicht. Hab dann noch den Beitrag von rkr gesehen und es dann auch bleiben lassen.

Das ist richtig. Welche Klasse du tatsächlich instantiierst (a,b,c oder d) wird im Normalfall von außen konfiguriert und dann zum Beispiel durch eine Factory abstrahiert.

Diesen Ansatz habe ich nun versucht, umzusetzen.
Ich weiss leider nur noch nicht so recht, ob das was ich da gemacht hab, auch tatsächlich mit "Factory" gemeint ist.

Jedenfalls hätte ein Dritter nun die Möglichkeit, das gelieferte Objekt zu erweitern oder auch zu verändern.

So in etwa würde ich mir ein Plugin vorstellen.

Weiters hab ich versucht, meine bisherige Art, eine Klasse zu schreiben (naja, es war mehr eine Funktions-Sammlung) nun runterzubrechen auf Mini-Aufgaben. Weiters sollen die "Module" nicht mehr voneinander abhängig sein, so wie xm22 und krk schreiben (Dependencies, Separation of Concerns, KISS) .

Wobei: ich möchte noch erwähnen: ich bin weit noch nicht so fortgeschritten wie ihr, es sind alles selbst auferlegte Beispiele/Aufgaben mangels Möglichkeiten aus der Praxis.

Die erste Klasse macht eigentlich gar nichts, ausser die anderen Klassen zu laden und abzuarbeiten. Ich habe sie PermissionsFactory genannt. Die anderen 2 Klassen machen dann etwas (was auch immer sie tun, stünde dann dem "Plugin"-Ersteller frei).

<?php
class PermissionsFactory {

    static $result;

    function __construct ( ) {

        if ($handle = opendir('classes/PermissionsFactory')) {
            while (false !== ($file = readdir($handle))) {
                if( preg_match( "/([a-zA-Z0-9]+).php/", $file, $matches ) > 0 ) {               
                    require_once( 'classes/PermissionsFactory/' . $file );
                    $modules[] = new $matches[1]();
                }
            }
        }

        foreach( $modules as $moduleKey => $moduleArray ) {
            foreach( $moduleArray AS $key => $classObject ) {
                $object -> {$key} = $classObject;
            }
        }

        $this->result = $object;
    }

    function getResult(){
        return $this->result;
    }

Die "Erweiterungen" werden im gleichnamigen Unterordner mit dem Klassen-Namen als Dateiname gespeichert.
Ich hab zur besseren Übersicht die Funktionalität gleich in den Konstruktor reingesteckt (ist klar, normalerweise mach ich das nicht).

<?php

class QueryUser extends PermissionsFactory {

    function __construct( ){
        global $db;

// ich hoffe, xm22 reisst mir nicht gleich den Kopf ab, weil ich hier eine Abfrage reintue. Aber ich sehe da dann keine andere Möglichkeit wie der Pluginersteller dann die Daten herausbekommt.

        $sql = "SELECT user_id, user_adminlevel FROM " . TABLE_USERS . " WHERE user_sessionid = '" . session_id() . "'";
        $query = $db->query( $sql );
        $result = $query->fetch_assoc( );

        $this->user_id = $result['user_id'};
        $this->user_adminlevel = $result['user_adminlevel'];

    }
}

?>

<?php

class GetLoggedIn extends PermissionsFactory {

    function __construct( ){

// ich wollte hier nur sehen, ob loggedIn dann auch später verfügbar wäre

        if( true ){
            $this->loggedIn = 'blubb';
        }

    }

    function isLoggedIn( ){
        return $this->loggedIn;
    }
    
}

?>

Der Aufruf (in irgendeiner anderen Datei):

require_once( 'classes/PermissionsFactory.php' );
$user = new PermissionsFactory ; 

Was meint ihr?
Es ist klar, es ist "nur" ein Draft.
Es ist eher als Beispiel zu sehen.
Ich werde dann später versuchen, das auch auf "Preis" umzumünzen.
Ich habs bei so einer Konstellation auch nicht geschafft (zumindest beim Testen) die Funktion isLoggedIn verfügbar zu machen (die in einer der "Erweiterungen" steckt).

Aber generell?
Bin ich da am richtigen Weg?
Oder ist es Schrott?

print_r( $user ) ;
print_r( $user->getResult( ) ) ; 

gibt folgendes aus:

PermissionsFactory Object (     [result] => stdClass Object         (             [loggedIn] => blubb             [user_id] => userid             [user_adminlevel] => userwasandres         )  ) stdClass Object (     [loggedIn] => blubb     [user_id] => userid     [user_adminlevel] => userwasandres )