Objekt konvertieren..

[uschi]

Weil ich das Problem schon des öfteren hatte und ich trotz guter Dokumentation auf php.net nicht wirklich eine gute Idee bekomme, frage ich hier.

Die Suche nach "Objekt and konvertieren" ergab hier im Forum übrigens keine Ergebnisse, leider.

// PHP 4.x

class BB
{
  var TestWert;
  function BB () { $this->TestWert = 2 }
}
class AA
{
  // .. konstruktor etc.
  function konvertiere_zu_BB ()
  {
     // ... Was muss den hier hin?
  }
}

// blabla
Objekt_AA->konvertiere_zu_BB ();
// Jetzt ist AA ein Object von BB 

[Skaschy]

Evtl. sowas ?

Bin mir grad ehrlich gesagt nicht ganz sicher was du meinst:

<?php
class BB
{

    var $TestWert;
      
    function BB () { $this->TestWert = 2; }
}

class AA extends BB
{
    
    // .. konstruktor etc.
    function konvertiere_zu_BB ()
    {
        return $this->TestWert;
        // ... Was muss den hier hin?
    }
}

// blabla
$bb = new AA();
print $bb->konvertiere_zu_BB ();
?>

[combie]

Ich verstehe es auch nicht...
Und zusätzlich wüsste ich auch nicht wie das gehen sollte....

Konvertierungen sind (meines Wissens) nur zwischen den eingebauten Datentypen möglich!
Und da man selbst keine Datentypen definieren kann, ist "aus die Maus"!

Z.B. sowas steckt PHP locker weg:

 <?php
error_reporting(E_ALL);

$a = array(3,5,2);
var_dump($a);
echo '<hr>';

$b = (object)$a;
var_dump($b);
echo '<hr>';

$c = (array)$b;
var_dump($c);
echo '<hr>';
?>

Aber was willst du überhaupt damit?
Irgendwie hört sich das an, als würdest du das Factory Design Pattern suchen...

[onemorenerd]

Nach Factory hört sich das für mich nicht an. Sie will offenbar aus einem Auto (AA) einen Baum (BB) machen; Dinge die nichts miteinander gemeinsam haben.
Skaschy hat diese Gemeinsamkeit geschaffen, indem er BB von AA ableitet. Damit ist das Problem allerdings auch ein ganz anderes geworden, denn einen VW Golf (BB extends AA) in ein Auto (AA) zu konvertieren ist eine Generalisierung, für die es sicher sinnvolle Anwendungen gibt.
Das von uschi gewollte "Morphing" ist einfach nur Murks.

$auto = new AA();
$auto->setLackfarbe('grün');
$auto->convertToBaum()

Die Methode convertToBaum() müßte jede einzelne Property übersetzen. Dieses Mapping kann man für ein Morphing von AA nach BB noch implementieren, aber man will aus AA ja auch mal CC machen oder? Ideal wäre also eine Methode convertTo('Baum') und zwar in jeder Klasse. Damit dürfte der Nachteil der Idee deutlich werden: Die Klassen (hier AA) müßten genauestens über die Struktur aller anderen Klassen (hier nur BB) bescheid wissen - der Code wäre unwartbar!

Das nächste Dilemma: Wenn $auto plötzlich ein Baum ist, hat es doch ganz andere Methoden! Woher weiß das die Applikation?
Das führt in Richtung eines globalen Objekthandler, um Laufzeitfehler zu vermeiden. Spätestens hier wird klar, dass es kein gutes OO-Design mehr ist ...

[combie]

Nach Factory hört sich das für mich nicht an. Sie will offenbar aus einem Auto (AA) einen Baum (BB) machen; Dinge die nichts miteinander gemeinsam haben.

Autos und Bäume haben "viele" gemeinsame Eigenschaften
* Höhe
* Gewicht
* sie bestehen aus irgendetwas

Auch tun sie ähnliche Dinge..
* Stoffwechsel
* im starken Wind wackeln

Also, ganz verkehrt ist das Faktory Konzept nicht, wenn man wirklich die beiden unter einen Hut bringen "muss"

Man kann kein Auto von einem Baum ableiten, auch umgekehrt machts keinen Sinn..

[onemorenerd]

Hm okay, Auto und Baum ist nicht das beste Beispiel. Sagen wir statt dessen Geld und Kälte - nix gemeinsam, passt aber immernoch auf die Problembeschreibung.

Unabhängig davon bleibe ich dabei, dass das Factory Pattern den hier gewünschten Zweck nicht erfüllt. Factory dient zum Erzeugen neuer Instanzen, hier geht es aber um das Umwandeln bereits bestehender.
Freilich könnte man mittels Factory eine neue Instanz vom Zieltyp erzeugen. Aber wie passen das Mappen (s.o.) und Ersetzen der Ursprungsinstanz ins Factory Pattern?

[combie]

Factory dient zum Erzeugen neuer Instanzen,

Erzeugen, tunse doch alle ohne gehts kaum!

Nee, der Hauptzweck des Factory Konzeptes dürfte darin bestehen, eine einheitliche Schnittstelle für austauschbare Instanzen zu bieten, welche keine gemeinsamen Vorfahren haben.
Also nicht unbedingt aus 1 Erblinie stammen müssen.
Es wäre natürlich sinnvoll und schön, diese verborgenen Klassen, von einer gemeinsammen abstrakten Klasse abzuleiten. Zumindest das selbe Interface sollten sie schon haben...


Im Grunde bin ich auch nur beim Nebelstochern an "Factory" geraten...
Normale Vererbung war ja schon ausgeschlossen!

Ja, man müsste wirklich mehr über den Kontext und über das, was überhaupt wirklich erreicht werden soll, wissen...


Los uschi, sags uns !!(bitte)
Was willst du denn wirklich erreichen???
Beschreibe das Ziel und nicht den Weg!