Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Wann ein Objekt übergeben und wann Vererben?

Einklappen

Neue Werbung 2019

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

  • [Erledigt] Wann ein Objekt übergeben und wann Vererben?

    Hallo zusammen,

    in den schönen guten Büchern findet man ja immer so "praxisnahe" aber zumindest vorstellbare Beispiele wie z.B. die Klasse Porsche erbt von der Klasse Auto...

    Nun hatte ich in der Vergangenheit ein Programm entwickelt, welches ich in 2 Klassen abstrahiert hatte.

    1. Daten Erfassung
    2. Daten Auswertung

    Bei der Daten Erfassung wurden die für die Auswertung nötigen Werte erfasst. In der Auswertung wurde an Hand dieser Werte ein Vergleichswert "Rankingwert" zu anderen ähnlichen Datenstrukturen geschaffen.

    Damals hatte ich es so gelöst, dass die Klasse Auswertung direkt von der Klasse Erfassung abgeleitet wird. Im Nachhinein erhielt ich jedoch die Erkenntniss, dass es wohl sinnvoller gewesen wäre, hätte ich der Klasse Auswertung einfach ein Objekt der Klasse Erfassung übergeben.

    Nach wie vor ist mir jedoch noch nicht ganz klar, wann es Sinn macht von einer Klasse zu erben oder der neuen Klasse einfach ein Objekt zu übergeben?

    Habt ihr hier eventuell ein gutes Beispiel an Hand einer PHP praxisbezogenen Anwendung?

    Vielen Dank!


  • #2
    Dein Beispiel wäre ein Beispiel für übergeben von Objekten.

    Vererbung ist dafür gut dass du bestimmte Codestücke nicht doppelt schreiben musst. Wenn du zwei verschiedene Klassen hast die verschiedene Dinge tun ABER bestimmte Funktionen oder Variablen oder sowas gemein haben. Dann kannst du eine Klasse machen die diesen gemeinsamen Code enthält und die Klassen die davon erben implementieren dann spezifischen Code.

    Zum Beispiel könntest du ein Formularelement als Klasse darstellen. Du hast die Eigenschaften Name, Wert, default Wert. Diese Eigenschaften haben ALLE Formularelement gemeinsam. Dann gibts z.b. noch die Methoden "isEmpty" und "getValue" und "setDefaultValue".

    Und dann willst du die einzelnen Formularelemente als Klassen darstellen. Z.B. eine Klasse für Textfelder, eine für Selectfelder, eine für Checkboxen und so weiter. Alle diese Klassen erben von der Basisklasse, somit hat jedes Formularelement shconmal diese wichtigen gemeinsamen Eigenschaften. Aber du kannst noch zusätzliche Eigenschaften und Methoden implementieren. Zum Beispiel bei der Selectbox der Wert für "size".

    Kommentar


    • #3
      Mit einer Vererbung konkretisierst du ein Objekt, indem du in der Klasse weitere Eigenschaften und Methoden definierst. Je weiter du in der Hierarchie nach oben gehst, desto allgemeiner musst du werden.

      Unter einer Klasse Auswertung oder Erfassung kann ich mir jetzt nur schwer etwas vorstellen. Vermutlich denkst du noch zu prozedural. Jedenfalls hört es sich für mich nicht so an, als ob beide Klassen irgendetwas gemeinsam hätten. Vererbung würde sich daher wohl eher nicht anbieten.
      http://hallophp.de

      Kommentar


      • #4
        Zitat von Flor1an Beitrag anzeigen
        Vererbung ist dafür gut dass du bestimmte Codestücke nicht doppelt schreiben musst. Wenn du zwei verschiedene Klassen hast die verschiedene Dinge tun ABER bestimmte Funktionen oder Variablen oder sowas gemein haben.
        Die Erklaerung finde ich nicht gut, weil sie nicht zwingend auf fuer Vererbung vorgesehenen Programmcode zutrifft, sondern viel mehr umfasst.

        Vererbung musst du dir wie in der Biologie vorstellen, als Teil-/Untermenge/Spezialform. Immer wenn die Beziehung nicht mehr als "ist Teilmenge von" beschrieben werden muss, sondern nur mit "verwendet", solltest du keine Vererbung vornehmen.

        Haeufiger Fehler:
        User extends MySQL:
        Der Benutzer ist Teilmenge von MySQL? ... oder anders: Eine Person ist eine Spezialform einer Datenbank? Sicherlich nicht. Es geht ja um die Gesamtheit der Eigenschaften und Funktionalitaeten. Macht eine Methode connect() oder query() der MySQL in einer User-Tabelle Sinn? Ne.

        Schwierig wirds halt bei abstrakten Dingen wie eben deiner Datenerfassung. Aber Erfassung und Auswertung sind nicht vererbar untereinander. Sie verwenden ja nur die Daten des Vorgaengers weiter.
        "Mein Name ist Lohse, ich kaufe hier ein."

        Kommentar


        • #5
          [MOD: verschoben]
          --

          „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
          Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


          --

          Kommentar


          • #6
            Zitat von Chriz Beitrag anzeigen
            Die Erklaerung finde ich nicht gut, weil sie nicht zwingend auf fuer Vererbung vorgesehenen Programmcode zutrifft, sondern viel mehr umfasst.

            Vererbung musst du dir wie in der Biologie vorstellen, als Teil-/Untermenge/Spezialform. Immer wenn die Beziehung nicht mehr als "ist Teilmenge von" beschrieben werden muss, sondern nur mit "verwendet", solltest du keine Vererbung vornehmen.

            Haeufiger Fehler:
            User extends MySQL:
            Der Benutzer ist Teilmenge von MySQL? ... oder anders: Eine Person ist eine Spezialform einer Datenbank? Sicherlich nicht. Es geht ja um die Gesamtheit der Eigenschaften und Funktionalitaeten. Macht eine Methode connect() oder query() der MySQL in einer User-Tabelle Sinn? Ne.

            Schwierig wirds halt bei abstrakten Dingen wie eben deiner Datenerfassung. Aber Erfassung und Auswertung sind nicht vererbar untereinander. Sie verwenden ja nur die Daten des Vorgaengers weiter.
            Was aber IMHO bei
            User extends MySQL_DataObject
            wieder anders ist, da es meiner Meinung nach dann eine Teilmenge von der DB Zugriffsebene ist...
            Es kommt doch auf die Architektur an...

            Kommentar


            • #7
              Was aber IMHO bei
              User extends MySQL_DataObject
              wieder anders ist,
              Sehe ich nicht so.

              MySQL_DataObject extends MySQL_DB : ja-jain
              User extends MySQL_DataObject : nein

              Eine Person ist keine Datenbank. Zugriff auf eine Datenmenge kann komponiert, User selbst können per Factory erzeugt werden.
              --

              „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
              Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


              --

              Kommentar


              • #8
                Wäre das eine Factory:
                PHP-Code:

                class user extends DataObject
                {
                protected 
                $table 'user';
                ..

                public static function 
                createFromId($id)
                {
                $user = new ...
                //daten holen
                return $user;
                }
                public function  
                isGuest()
                {
                return 
                foobar;
                }

                Weil das ist das was ich meine...

                Kommentar


                • #9
                  Nö, nicht wirklich. Das hat im User-Objekt nichts verloren. Der User kann sich ja nicht selbst erstellen.
                  --

                  „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                  Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                  --

                  Kommentar


                  • #10
                    Doch...
                    zB


                    $userdata = User::createFromId(4);
                    echo 'Benutzer '. $userdata->getName() . 'ist ' . $userdata->getStatus();


                    Aber wir weichen hier vom Thema ab finde ich

                    Kommentar


                    • #11
                      Ja, das nennt sich Factorymethode, grundsätzlich gilt hier aber die selbe Kritik - Ein User ist keine Datenbank, ein Produkt (User) ist keine Fabrik (User Factory). Factorymethode ist auch schon so ein halbes Anti-Pattern.
                      --

                      „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                      Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                      --

                      Kommentar


                      • #12
                        Hallo zusammen,

                        danke soweit für eure Antworten.

                        Klasse vererben
                        Also hätte ich eine Klasse User und wollte verschiedenen Usergruppen erstellen mit unterschiedlichen Rechten (-> Normalo kann sein Profil nicht ändern, Admin schon ...) würde ich von der Klasse User erben und beispielsweise die Klasse Admin erstellen. Das ist soweit richtig?

                        Objekt übergeben
                        Wenn ich eine Klasse User habe und dieser User für eine Klasse beispielsweise Schule benötigt wird. Würde ich das Objekt übergeben. Da nur die Instanz benötigt wird. Das dürfte auch soweit richtig sein?

                        Klasse User und Thematik -> neuen User erstellen
                        Nun weiß ich nicht ob ich die letzten Antworten richtig interpretiere. Wenn ich also eine Klasse User hab, wäre es falsch dieser Klasse eine Methode zu geben, welche einen neuen User erstellt? Beispielsweise in Form einer statischen Methode der Klasse? Ich denke genau für solche Aspekte gibt es statische Methoden?

                        Vielen Dank!

                        Kommentar


                        • #13
                          Klasse vererben
                          Also hätte ich eine Klasse User und wollte verschiedenen Usergruppen erstellen mit unterschiedlichen Rechten (-> Normalo kann sein Profil nicht ändern, Admin schon ...) würde ich von der Klasse User erben und beispielsweise die Klasse Admin erstellen. Das ist soweit richtig?
                          Naja, auch das hinkt. Besser ist Vererbung auf Kontexte anzuwenden, die sich in Ihrem Verhalten unterscheiden, aber in ihrem „Äußeren“ ähneln. Eine Rechteverwaltung ist eigentlich eher ein Thema für sich, keine Eigenschaft eines Users.
                          Bsp: Ist Autofahrer eine Erweiterung von User? Schließlich ist das Hauptkriterium doch, dass er ein Autoobjekt besitzt, was ihn zum Autofahrer macht. Sicher käme man nicht auf die Idee, jetzt dem User Methoden wie Lenke(), StarteWagen(), KurbeleFensterRunter() und soweiter zuzuordnen. Man könnte jetzt argumentieren, ein Autofahrer müßte eine Fahrausbildung besitzen, das wäre dann allerdings ein sehr enger Kontext (rufeAutofahrwissenAb()), was i.A. nicht Zweck der Vererbung ist.

                          Nun weiß ich nicht ob ich die letzten Antworten richtig interpretiere. Wenn ich also eine Klasse User hab, wäre es falsch dieser Klasse eine Methode zu geben, welche einen neuen User erstellt? Beispielsweise in Form einer statischen Methode der Klasse? Ich denke genau für solche Aspekte gibt es statische Methoden?
                          Naja, wie gesagt, in meinen Augen ist Factory Method ein weit verbreitetes Pattern, aber irgendwo auch ein Anti-Pattern. Während echte Factories erweiterbar sind, kriegst Du bei Factory Method bereits bei der Ableitung der Klasse arge Probleme. Ebenfalls, wenn die Factory andere Ressourcen (DB) oder Objekte benötigt. Dann bekommst Du riesige Methoden-Parameterlisten und dergl.

                          [edit]
                          Ich lese gerade, dass Fabrik Methode im eigentlichen Sinne auch noch was anderes meint, auf das meine Kritik dann nicht mehr zutrifft: http://de.wikipedia.org/wiki/Factory_Method

                          [edit2]
                          Das Beispiel mit den Restaurants ist eigentlich recht vielsagend: http://de.wikipedia.org/wiki/Factory...iel_in_C.2B.2B
                          --

                          „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                          Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                          --

                          Kommentar


                          • #14
                            Hallo nikosch,

                            danke für deine Antwort. Interessante Thematik.

                            Kommentar


                            • #15
                              Ich finde Factory-Methoden eigentlich nicht schlimm. Mit PHP 5.3, late static binding und __callStatic würden sich da theoretisch schon coole Sachen basteln lassen.


                              MySQL_DataObject extends MySQL_DB : ja-jain
                              User extends MySQL_DataObject : nein
                              Sehe ich genau umgekehrt. Einfach mal den "ist ein"-Test machen:
                              User ist ein MySQL_DataObject. Jep, kann sein.
                              MySQL_DataObject ist eine MySQL_Db. Nein, definitiv nicht.
                              Create your own quiz show.

                              Kommentar

                              Lädt...
                              X