Ereditarietà multipla in PHP

Sto cercando un modo valido e pulito per aggirare il fatto che PHP5 non supporta ancora l'ereditarietà multipla. Ecco la gerarchia delle classi:

Messaggio
- TextMessage
-------- InvitationTextMessage
- EmailMessage
-------- InvitationEmailMessage

I due tipi di classi Invitation * hanno molto in comune; Mi piacerebbe avere una classe genitore comune, Invitation, da cui erediteranno entrambi. Sfortunatamente, hanno anche molto in comune con i loro attuali antenati ... TextMessage e EmailMessage. Desiderio classico di eredità multipla qui.

Qual è l'approccio più leggero per risolvere il problema?

Grazie!

Alex, la maggior parte delle volte hai bisogno di ereditarietà multipla è un segnale che la tua struttura dell'oggetto è in qualche modo errata. Nella situazione che hai delineato vedo che hai una responsabilità di classe semplicemente troppo ampia. Se Message fa parte del modello di business dell'applicazione, non dovrebbe occuparsi del rendering dell'output. Invece, potresti dividere la responsabilità e usare MessageDispatcher che invia il messaggio passato usando testo o backend html. Non conosco il tuo codice, ma fammi simulare in questo modo:

$m = new Message();
$m->type = 'text/html';
$m->from = 'John Doe <jdoe@yahoo.com>';
$m->to = 'Random Hacker <rh@gmail.com>';
$m->subject = 'Invitation email';
$m->importBody('invitation.html');

$d = new MessageDispatcher();
$d->dispatch($m);

In questo modo puoi aggiungere alcune specializzazioni alla classe Message:

$htmlIM = new InvitationHTMLMessage(); // html type, subject and body configuration in constructor
$textIM = new InvitationTextMessage(); // text type, subject and body configuration in constructor

$d = new MessageDispatcher();
$d->dispatch($htmlIM);
$d->dispatch($textIM);

Si noti che MessageDispatcher deciderà se inviare come HTML o testo normale a seconda della typeproprietà nell'oggetto Message passato.

// in MessageDispatcher class
public function dispatch(Message $m) {
    if ($m->type == 'text/plain') {
        $this->sendAsText($m);
    } elseif ($m->type == 'text/html') {
        $this->sendAsHTML($m);
    } else {
        throw new Exception("MIME type {$m->type} not supported");
    }
}

Per riassumere, la responsabilità è suddivisa tra due classi. La configurazione dei messaggi viene eseguita nella classe InvitationHTMLMessage / InvitationTextMessage e l'algoritmo di invio viene delegato al dispatcher. Questo si chiama Strategy Pattern, puoi leggere di più qui .

Forse puoi sostituire una relazione "è-un" con una relazione "ha-un"? Un invito potrebbe contenere un messaggio, ma non è necessario che sia un messaggio. Potrebbe essere confermato un messaggio di invito, che non si sposa bene con il modello Message.

Cerca "composizione vs. eredità" se hai bisogno di saperne di più.

Se posso citare Phil in questo thread ...

PHP, come Java, non supporta l'ereditarietà multipla.

In arrivo in PHP 5.4 ci saranno tratti che tenteranno di fornire una soluzione a questo problema.

Nel frattempo, faresti meglio a ripensare il design della tua classe. Puoi implementare più interfacce se stai cercando un'API estesa per le tue classi.

E Chris ...

PHP non supporta davvero l'ereditarietà multipla, ma ci sono alcuni modi (un po 'disordinati) per implementarla. Controlla questo URL per alcuni esempi:

http://www.jasny.net/articles/how-i-php-multiple-inheritance/

Pensavo che entrambi avessero link utili. Non vedo l'ora di provare i tratti o forse alcuni mixin ...

Il framework Symfony ha un plugin per mixin per questo , potresti volerlo controllare - anche solo per idee, se non per usarlo.

La risposta "design pattern" è astrarre la funzionalità condivisa in un componente separato e comporre in fase di esecuzione. Pensa a un modo per astrarre la funzionalità Invitation come una classe che viene associata alle tue classi Message in un modo diverso dall'ereditarietà.

Sto usando i tratti in PHP 5.4 come modo per risolvere questo problema. http://php.net/manual/en/language.oop5.traits.php

Ciò consente l'ereditarietà classica con estensioni, ma offre anche la possibilità di collocare funzionalità e proprietà comuni in un "tratto". Come dice il manuale:

Traits è un meccanismo per il riutilizzo del codice in linguaggi a ereditarietà singola come PHP. Un tratto ha lo scopo di ridurre alcune limitazioni dell'ereditarietà singola consentendo a uno sviluppatore di riutilizzare set di metodi liberamente in diverse classi indipendenti che vivono in gerarchie di classi diverse.

Sembra che il motivo del decoratore possa essere adatto, ma difficile da dire senza ulteriori dettagli.

Questa è sia una domanda che una soluzione ...

E la magica _ call (),metodi _get (), __set ()? Non ho ancora testato questa soluzione, ma cosa succede se crei una classe multiInherit. Una variabile protetta in una classe figlia potrebbe contenere un array di classi da ereditare. Il costruttore nella classe multi-interfaccia potrebbe creare istanze di ciascuna delle classi che vengono ereditate e collegarle a una proprietà privata, ad esempio _ext. Il metodo __call () potrebbe utilizzare la funzione method_exists () su ciascuna delle classi nell'array _ext per individuare il metodo corretto da chiamare. __get () e __set potrebbero essere usati per individuare proprietà interne, o se sei un esperto con riferimenti potresti fare in modo che le proprietà della classe figlia e le classi ereditate siano riferimenti agli stessi dati. L'ereditarietà multipla del tuo oggetto sarebbe trasparente al codice che utilizza quegli oggetti. Anche, gli oggetti interni potrebbero accedere direttamente agli oggetti ereditati, se necessario, a condizione che l'array _ext sia indicizzato in base al nome della classe. Ho immaginato di creare questa super classe e non l'ho ancora implementata perché penso che se funzionasse potrebbe portare a sviluppare alcune cattive abitudini di programmazione.

Ho un paio di domande da porre per chiarire cosa stai facendo:

1) Il tuo oggetto messaggio contiene solo un messaggio, ad es. Corpo, destinatario, orario di pianificazione? 2) Cosa intendi fare con il tuo oggetto Invito? Deve essere trattato in modo speciale rispetto a un messaggio di posta elettronica? 3) In caso affermativo COSA ha di così speciale? 4) In tal caso, perché i tipi di messaggio devono essere gestiti in modo diverso per un invito? 5) Cosa succede se si desidera inviare un messaggio di benvenuto o un messaggio OK? Sono anche oggetti nuovi?

Sembra che tu stia cercando di combinare troppe funzionalità in un insieme di oggetti che dovrebbero riguardare solo il contenuto di un messaggio e non come dovrebbe essere gestito. Per me, vedi, non c'è differenza tra un invito o un messaggio standard. Se l'invito richiede una gestione speciale, significa logica dell'applicazione e non un tipo di messaggio.

Ad esempio: un sistema che ho creato aveva un oggetto messaggio di base condiviso esteso a SMS, e-mail e altri tipi di messaggi. Tuttavia: questi non sono stati estesi ulteriormente: un messaggio di invito era semplicemente un testo predefinito da inviare tramite un messaggio di tipo E-mail. Una specifica domanda di invito riguarderebbe la convalida e altri requisiti per un invito. Dopotutto, tutto ciò che vuoi fare è inviare il messaggio X al destinatario Y che dovrebbe essere un sistema discreto a sé stante.

Stesso problema come Java. Prova a utilizzare interfacce con funzioni astratte per risolvere il problema

PHP supporta le interfacce. Questa potrebbe essere una buona scommessa, a seconda dei casi d'uso.

Che ne dici di una lezione di invito proprio sotto la classe Messaggio?

quindi la gerarchia va:

Messaggio
--- Invito
------ TextMessage
------ EmailMessage

E nella classe Invitation, aggiungi la funzionalità che era in InvitationTextMessage e InvitationEmailMessage.

So che l'invito non è davvero un tipo di messaggio, è più una funzionalità del messaggio. Quindi non sono sicuro che questo sia un buon design OO o meno.