Ankündigung

Einklappen
Keine Ankündigung bisher.

OOP - Rekursive Verknüpfungen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • OOP - Rekursive Verknüpfungen

    So, ich hoffe mal, dass das hier rein passt - Ich habe konkret zu meiner Frage noch nichts im Forum gefunden:

    Beruflich arbeite ich mit Magento und hier wird folgendes ziemlich viel praktiziert: Und zwar werden Objekte rekursiv mit einander verknüpft. Das sieht dann - stark vereinfacht - so aus:

    PHP-Code:
    class KlasseA {
        public 
    $obj null;
    }
    class 
    KlasseA {
        public 
    $obj null;
    }
    $objA = new KlasseA();
    $objB = new KlasseB();

    $objA->obj $objB;
    $objB->obj $objA;

    //Bsp.
    $objA->obj->obj->obj 
    Das ist in manchen Fällen ganz praktisch, allerdings habe ich das bisher immer zu vermeiden versucht, allerdings ohne, dass ich jetzt einen Grund dafür nennen könnte. Wie steht ihr dazu?

  • #2
    Die Sprache kann's - wenn du es brauchst, setz es ein.
    [I]You know, my wife sometimes looks at me strangely. „Duncan“, she says, „there's more to life than Solaris“. Frankly, it's like she speaks another language. I mean, the words make sense individually, but put them together and it's complete nonsense.[/I]

    Kommentar


    • #3
      Wenn es nötig ist wieso nicht? Das Ziel bei so einem Konstrukt ist ja nicht die Rekrusion sondern die Komuikation der Objekte untereinander.

      Kommentar


      • #4
        Ja, dazu tendiere ich auch. Ich weiß, ehrlich gesagt, auch nicht, warum ich da bisher so eine Abneigung hatte. Vermutlich weil ich in meiner Anfangszeit Probleme hatte, wenn ich bei solchen Konstrukten var_dump oder print_r benutzt habe...

        Kommentar


        • #5
          im Grunde hast du so eine einfach verkettete Liste der Objekte .. spart jedenfalls Speicher gegenüber einer Datenstruktur, die deine Objekte irgendwie in Listenform enthält (um nicht Array zu schreiben)
          "Irren ist männlich", sprach der Igel und stieg von der Drahtbürste [IMG]http://www.php.de/core/images/smilies/icon_lol.gif[/IMG]

          Kommentar


          • #6
            Zitat von xm22 Beitrag anzeigen
            Ja, dazu tendiere ich auch. Ich weiß, ehrlich gesagt, auch nicht, warum ich da bisher so eine Abneigung hatte. Vermutlich weil ich in meiner Anfangszeit Probleme hatte, wenn ich bei solchen Konstrukten var_dump oder print_r benutzt habe...
            Ging mir genauso, ich hatte teil schon ein Interface eingebunden, dass bei meiner eigenen ~var_dump() Klasse dann diesen Rattenschwanz unterbunden hat.

            Sehr mächtig finde ich die Funktion der Referenzierung, wenn du Bäume aus einer flachen Hierarchie (Datenbank) einliest. Schadet also nichts, wenn du es nicht übertreibst.

            Kommentar


            • #7
              Nach diesen Antworten ist eine ziemlich Tendenz pro Verkettung zu sehen. Danke für eure Kommentare

              Kommentar


              • #8
                Was du da gebaut hast, nennt man auch "Zirkelreferenz". Solche Konstruktionen können verhindern, das ein Objekt vom GC abgeräumt wird, weil es noch referenziert wird...
                PHP-Code:
                $objA = new KlasseA();
                $objB = new KlasseB();

                $objA->obj $objB;
                $objB->obj $objA;

                unset(
                $objA);
                unset(
                $objB);

                // jetzt gibt es ein Memoryleak. $objA und $objB sind nicht mehr direkt verfügbar, 
                // allerdings existieren beide Objekte noch, da sie sich gegenseitig referenzieren. 
                // Man selber kommt nicht mehr an $objA und $objB heran, aber der GC kann den
                // Speicher auch nicht freigeben, eben weil die Objekte noch referenziert werden. 
                In PHP ist das halb so wild, weil nach dem Requestloop eh alles abgeräumt wird, in Java z.B. kann man sich so aber Memory Leaks einbauen, wenn man nicht aufpasst. Es ist durchaus möglich, ein Objekt zu "verlieren".
                Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

                Kommentar


                • #9
                  "Zirkelreferenz"
                  Stimmt - Das passt auch eher zur Bedeutung..

                  Kommentar


                  • #10
                    spart jedenfalls Speicher gegenüber einer Datenstruktur, die deine Objekte irgendwie in Listenform enthält (um nicht Array zu schreiben)
                    Ist das so?
                    [COLOR="#F5F5FF"]--[/COLOR]
                    [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                    [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                    [COLOR="#F5F5FF"]
                    --[/COLOR]

                    Kommentar


                    • #11
                      Zitat von lstegelitz Beitrag anzeigen
                      in Java z.B. kann man sich so aber Memory Leaks einbauen, wenn man nicht aufpasst. Es ist durchaus möglich, ein Objekt zu "verlieren".
                      Betonung bitte auf KANN. Der Garbage Collector der JVM soll laut Spezifikation durchaus in der Lage sein, auch solche Dinger abzuräumen.Und die Sun/Oracle-VM tut dies auch relativ zuverlässig.
                      Es gibt hier jedoch gefühlte Memory-Leaks, da der Garbage-Collector ggf. mehrere Iterationen unterscheidet und solche zirkulären Referenzen relativ niedrig priorisiert werden. Vereinfacht ausgedrückt: Je komplexer das Objektgeflecht, je langlebiger das Objekt desto eher wirds nur dann weggeräumt, wenn die VM gerade nichts besseres zu tun hat.

                      Langer Reder kurzer Sinn. In PHP gibbet keinen GC und wie von euch dargestellt gibt es ein Memory-Leak, was aufgrund der Request-/Response-Struktur weniger von Belang ist. Das ist erst wichtig, wenn man sehr viele Daten verarbeitet und so an die Problemgrenzen stößt.
                      Java kann das, auch wenn man sich nicht immer drauf verlassen kann.
                      [url]www.php-maven.org[/url] PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
                      Twitter @ [url]https://twitter.com/#!/mepeisen[/url] und Facebook @ [url]http://t.co/DZnKSUih[/url]

                      Kommentar


                      • #12
                        Wieso gibt es in PHP keinen GC?

                        Übrigens soll der Bug in 5.3 behoben sein: http://bugs.php.net/bug.php?id=33595

                        Kommentar


                        • #13
                          Zitat von nikosch Beitrag anzeigen
                          Ist das so?
                          Um das exakt zu beantworten, müsste man sich in den PHP-Interna sehr gut auskennen. Aber praktisch dürfte da nur der Platz für die Array-Struktur (oder eine passende SPL-Struktur) eingespart werden. Das ist bei kleinen "Listen" sicher nicht viel und bei großen interessierts keinen mehr. Schwerer dürfte wiegen, dass man die riesige Werkzeugkiste an Funktionen für die entsprechende Datenstruktur nicht mehr benutzen kann, um das ganze zu verwalten.

                          Zitat von mepeisen
                          In PHP gibbet keinen GC ...
                          Huch, seit wann hat man den Garbage-Collector in PHP denn abgeschafft?

                          Zitat von mepeisen
                          ... und wie von euch dargestellt gibt es ein Memory-Leak, was aufgrund der Request-/Response-Struktur weniger von Belang ist.
                          Nun, ein "echtes" Memory-Leak zeichnet sich dadurch aus, dass nach dem Beenden des Prozesses weniger Hauptspeicher da ist als vorher. Zirkuläre Referenzierung sollte nicht zu einem solchen Problem führen, kann aber zur Laufzeit des Prozesses Schwierigkeiten machen, wenn der Garbage-Collector zu dumm ist, sie zu erkennen. Deswegen hat man ja seit PHP 5.3.0 die Möglichkeit bekommen, daran herumzuschrauben.

                          ... und *mist_zu_langsam*
                          Wenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.

                          Kommentar


                          • #14
                            Alter Korinthenkacker. Das, was PHP treibt, darf man nicht GC nennen. Da sträuben sich mir als Java-Mensch die Nackenhaare Also: In PHP gibbet (Ausnahme ab 5.3 und nur bei Anforderung) nichts, was den Namen GC verdient.
                            Zum Zeitpunkt der Script-Verarbeitung ist das ein Memory-Leak. Per Definition ist ein Memory-Leak ein Stückchen Speicher, was unter normalen Umständen von der Anwendung nicht mehr adressiert/erreicht werden kann, dennoch als belegt kennzeichnet ist. Im übrigen gibt es davon tausende. Man kann mal spasseshalber PHP so kompilieren, dass es meckert am Ende des Scriptablaufes. Da kommen zig Ecken zutage, wo Memory-Leaks verwendet werden.

                            Streng genommen gibt es bei nahezu allen Programmen immer Memory-Leaks, denn viele Programme kümmern sich beim Beenden nicht darum, Speicherfragment für Speicherfragment explizit wegzuräumen. Um zu verstehen, warum das nicht schlimm ist, muss man bzgl. Speicherverwaltung etwas ausholen. Einfach ausgedrückt: Vom Betriebssystem werden 100MB angefordert, als Block. In diesen 100MB schreibt nun das Programm rein, was es schreiben will. Dass dort Teilbereiche beispielsweise für die Variable $_GET vorgesehen sind, ein anderer Teilbereich für $_POST, davon weiß das Betriebssystem nichts. Am Ende des Programms (=Requests in dem Fall) gibt es nur die Chance, den gesamten Speicher als großen Block wieder dem Betriebssystem als frei zu melden. Ob es innerhalb des Blocks zu einem Leak kam, interessiert niemanden mehr. Es interessiert erst, wenn man zur Laufzeit selbst an die Speichergrenze stößt. Dann hat man entweder die Chance, ständig neuen Speicher anzufordern, bis dir das Betriebssystem einen Vogel zeigt und sich verweigert oder man meldet einen Fehler (bei PHP eine typische Memory-Exhausted-Fehlermeldung).
                            PHP garantiert im Apache, dass es nach Fertigstellen eines Requests zu keinen Memory-Leaks kommen kann, solange die Extensions keinen Blödsinn treiben (die meisten tun das aber auch nicht). Aber selbst wenn Plugins Blödsinn treiben, sich aber an die API halten um Speicher zu reservieren, meckert PHP eventuell, kann aber trotzdem Memory-Leaks vermeiden.

                            Spannendes Thema. Aber bei 08/15 Scripten wenig relevant. Das, was sehr viel mehr Relevanz hat ist die Tatsache, dass man in jeder Sprache den Aufruf des Destruktors eines Objektes mit Vorsicht genießen sollte. Das hängt damit zusammen. Sobald ein Objekt als nicht mehr gebraucht angesehen wird, wird in diesem Zug der Destruktor aufgerufen. Sollte der Code von einem Destruktor abhängen, kriegt man irgendwann mal Probleme. Der wird eventuell irgendwann nicht mehr aufgerufen oder zu falschen Zeitpunkten, weil man an völlig anderen Ecken was geändert hat und die Objekte nicht mehr oder in einer falschen Reihenfolge weggeräumt werden.

                            Also:
                            a) Wenn akutes Problem mit Memory-Leaks innerhalb eines Requests, dann drüber nachdenken. Ansonsten nicht.
                            b) Wenn Destruktor-Code, dann aufpassen.

                            Alles andere ist philosophische oder akademische Diskussion.
                            [url]www.php-maven.org[/url] PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
                            Twitter @ [url]https://twitter.com/#!/mepeisen[/url] und Facebook @ [url]http://t.co/DZnKSUih[/url]

                            Kommentar


                            • #15
                              Zitat von mepeisen Beitrag anzeigen
                              Alter Korinthenkacker.
                              Das "alt" nimmst du zurück!

                              Das, was PHP treibt, darf man nicht GC nennen. Da sträuben sich mir als Java-Mensch die Nackenhaare Also: In PHP gibbet (Ausnahme ab 5.3 und nur bei Anforderung) nichts, was den Namen GC verdient.
                              Wenn du das sagst. Meine letzten Versuche, die Speicherverwaltung von PHP zu ergründen, liegen einige Zeit zurück. Ich wollte nur herausbekommen, ob man vorausberechnen kann, wieviel Speicher die imagecreate-Funktionen anfordern. Das war erfolglos, weil eine Funktion eine andere aufrief, die ein Macro aufrief, das wiederum eine Funktion aufrief, die ein Macro aufrief usw. usf. Irgendwann gab ich dann auf ...

                              Zum Zeitpunkt der Script-Verarbeitung ist das ein Memory-Leak. Per Definition ist ein Memory-Leak ein Stückchen Speicher, was unter normalen Umständen von der Anwendung nicht mehr adressiert/erreicht werden kann, dennoch als belegt kennzeichnet ist
                              ...
                              Meine "Definition" eines Speicher-Lecks sollte auch nur verdeutlichen, dass "nicht mehr erreichbarer" Speicher erstmal nichts "Schlimmes" bedeutet, ein "Leck" dagegen schon. Im Prinzip fast das Gleiche, was du jetzt noch mal viel schöner und mit mehr Hintergrund dargelegt hast.

                              Um mal an der Oberfläche zu bleiben: Es wäre sehr praktisch, wenn man im PHP-Script die ID (oder eben die "Referenz auf ...") eines Objektes (oder Arrays) in Erfahrung bringen könnte. Dann könnte man auf dieser Ebene das Problem (meistens) auflösen oder gleich vermeiden. Leider geht das (derzeit) nicht.
                              Wenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.

                              Kommentar

                              Lädt...
                              X