Hadi: / (PHP) OOP vs. gekapselte Funktionen

Hallo Forum,
ich entwickle nun schon seit einigen Jahren Webandwendungen in PHP und verwende dabei praktisch immer die Kapselung einzelner Aufgaben in Funktionen.

Hier ein Beispiel aus einem Onlineshop:

  • function draw_products_list($_products) - erstellt eine HTML-Liste der übergebenen Produkte unter Verwendung div. anderer Funktionen

  • function search_products($searchstring,....) - returned ein Array mit passenden/der Suche entsprechenden Artikelnummern, die dann z.B. für die Ausgabe an den User an draw_products_list() übergeben wird.

So habe ich dann z.B. auch noch Funktionen, die mir alle Produkte (bzw. deren Artikelnummer) einer Kategorie, den Warenkorb usw. usf. als Array zurückgeben, mit der ich dann wiederum eine HTML-Liste mittels draw_products_list() ausgeben kann, andererseits aber auch wieder andere Funktionen, die mir mit einem Array mit Artikelnummern CSV-Dateien generieren, einen Warenkorbinhalt speichern usw. usf.
Außerdem gibt es z.B. eine zentrale Funktion product(), von der die ganzen Daten ausgelesen werden - so können ggf. spätere Änderungen der Datenbankstruktur, das Hinzufügen neuer Produktattribute etc. pp. eingepasst werden.

Jetzt fahre ich damit eigentlich recht gut, lese aber immer wieder, dass OOP das einzig Wahre sei und ich in Zukunft alles nur noch in Objekte usw. packen soll, meine jetzige Technik sei totaler Schwachsinn.
Argumente dazu habe ich bisher jedoch noch keine wirklichen gehört - und kann auch keine finden.

In manchen Bereichen machen Objekte ja Sinn (dort verwende ich sie ja auch), aber meistens reicht es doch auch einfach, verschiedene Funktionen zu erstellen, die sich gegenseitig aufrufen und Teilaufgaben übernehmen.
Die Wiederverwertbarkeit ist auch meist gegeben, ich verwende viele Funktionen oder Funktionskombinationen in mehreren Projekten, habe da schon mein Standardreportoire...

Deshalb frage ich hier einmal: Kann mir einer sagen, was ich allgemein mit OOP - insbesondere im Vergleich zu meiner "Technik" - für Vorteile habe, gerne auch im Bezug auf obiges Shop-Beispiel.

Dass ich nichts vererben kann, ist klar, man kann Funktionen aber auch später noch erweitern, ohne die Abwärtskompatibilität zu gefährden - aber sonst?

Ich freue mich auf konstruktive Beiträge,

Hadi.

  1. Hi,

    Jetzt fahre ich damit eigentlich recht gut, lese aber immer wieder, dass OOP das einzig Wahre sei und ich in Zukunft alles nur noch in Objekte usw. packen soll, meine jetzige Technik sei totaler Schwachsinn.

    OOP ist zwar nicht das einzig Wahre, aber je komplexer eine Anwendung wird, desto sinnvoller ist OOP. Bei Dir wittere ich beispielsweise schon mal ein MVC-Pattern.

    Argumente dazu habe ich bisher jedoch noch keine wirklichen gehört - und kann auch keine finden.

    Nach Argumenten suchen auch nur die, die OOP noch nicht angewendet haben. Alle anderen brauchen keine mehr ;-)

    Deshalb frage ich hier einmal: Kann mir einer sagen, was ich allgemein mit OOP - insbesondere im Vergleich zu meiner "Technik" - für Vorteile habe, gerne auch im Bezug auf obiges Shop-Beispiel.

    Lass es mich mit einer kleinen Anekdote aus meiner Jugend[1] verbildlichen: Meine Informatiklehrerin hatte arge Probleme damit, uns Objektorientierung zu erläutern. Sie war außerdem stets bemüht, ein jedes Programm in das Hauptverzeichnis der Festplatte zu installieren - nein, nicht etwa in "C:\Programmname", sondern tatsächlich in "C:". Im Nachhinein vermute ich, dass sie selbst mit OOP nichts anfangen konnte, und dass hier eine Verbindung zu der eben genannten Vorliebe bestand. Hätte ihr OOP mehr gelegen, wären ihre Verzeichnisse wahrscheinlich auch strukturierter gewesen.

    Dass ich nichts vererben kann, ist klar, man kann Funktionen aber auch später noch erweitern, ohne die Abwärtskompatibilität zu gefährden - aber sonst?

    Was ist, wenn Du Deine Produktliste nicht nur als HTML-Liste ausgeben willst, sondern je nach Kontext als Plaintext bzw. CSV, als PDF oder als Tabelle mit diversen Details? In OOP ist das trivial lösbar mit z.B. einem Factory-Pattern für den View in MVC, bei Deinem funktionalen Ansatz müsstest Du ständig den Kontext abfragen oder komplett neue Programmkonstrukte schreiben.

    Cheatah

    [1] Der Teil der Jugend, in dem der Computer bereits erfunden war.

    --
    X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
    X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
    1. Hi Cheatah und danke für deine Antwort zu später Stunde,
      ich antworte nur ganz kurz, da ich gleich vor Müdigkeit aus dem Sessel kippe ;-)

      Was ist, wenn Du Deine Produktliste nicht nur als HTML-Liste ausgeben willst, sondern je nach Kontext als Plaintext bzw. CSV, als PDF oder als Tabelle mit diversen Details?

      Für CSV-Dateien habe ich eine csv()-Funktion. Die ist wieder unterteilt und besteht aus mehreren Funktionen, wäre zu kompliziert, das zu erläutern, aber diese braucht eben auch nur eine Produktliste als Array, die ich über die search_products() oder die category_products_list() etc. generiere ...

      PDFs generiere ich über eine modifizierte Von-der-Stange-PDF-Klasse aus der HTML-Ansicht.
      Die HTML-Ansicht kann ich mittels Templates anpassen und habe für z.B. die PDF-Ansicht ein anderes Template als für die Shopansicht, für die Ansicht im Admin-Bereich etc.

      Es sind also praktisch mehrere Funktionen, die alle einen bestimmten Teil an Aufgaben ausführen und "miteinander kommunzieren"...

      Lass es mich mit einer kleinen Anekdote aus meiner Jugend[1] verbildlichen: Meine Informatiklehrerin hatte arge Probleme damit, uns Objektorientierung zu erläutern. Sie war außerdem stets bemüht, ein jedes Programm in das Hauptverzeichnis der Festplatte zu installieren - nein, nicht etwa in "C:\Programmname", sondern tatsächlich in "C:". Im Nachhinein vermute ich, dass sie selbst mit OOP nichts anfangen konnte, und dass hier eine Verbindung zu der eben genannten Vorliebe bestand. Hätte ihr OOP mehr gelegen, wären ihre Verzeichnisse wahrscheinlich auch strukturierter gewesen.

      Ich habe mich sehr intensiv und lange mit OOP beschäftigt und kann eben für z.B. das Beispiel des Shops keinen Vorteil finden, deswegen frage ich ja ;-)
      Die Funktionen selbst sind jeweils in einzelnen *.func.php-Dateien, die wiederum sehr schön untersortiert in zig Ordnern und Unterordnern liegen.
      Ich hoffe, du hast da nicht noch was philosophisches bzw. was "zwischen den Zeilen" versteckt, das ich in meinem momentanen Geisteszustand nicht entdeckt habe?

      Gruß, Hadi.

      1. Hi Hadi!

        Es sind also praktisch mehrere Funktionen, die alle einen bestimmten Teil an Aufgaben ausführen und "miteinander kommunzieren"...

        Dieses "miteinander kommunizieren" kannst du prima in der OOP abbilden.

        Sinn der OOP ist es ja gerade mit den gegebenen Mitteln wie Vererbung und Kapselung einen Teil der realen Welt zu abstrahieren.
        Deine Angaben lassen vermuten, dass du mehrere Funktionen hast, die mit den gleichen Datenstrukturen arbeiten.
        Du könntest also deine "Produktliste als Array" locker-flockig in einen abstrakten Datentyp umwandeln. Für diesen definierst du dann deine benötigten Funktionen, wie z. B. asCSV(), asPDF() oder asXML(), die alle auf den gleichen Daten arbeiten.

        Man muss sich natürlich auch im Klaren sein, wie ein abstrakter Datentyp (in PHP also eine Klasse) intern verarbeitet wird:
        Alle Instanzen einer Klasse operieren auf ihren eigenen Daten. Durch diese Daten definiert sich der Zustand einer Instanz.
        Die Methoden allerdings sind für alle Instanzen identisch und werden demzufolge auch nur an einer Stelle im Speicher gehalten.
        Sicher gibt es auch klassenweite (statische) Klassenattribute, aber das Prinzip sollte klar sein.

        OO legt nicht einfach nur Programmierkonzepte fest. Es ist eine Philosophie und unterstützt damit nicht nur bei der Programmierung, sondern auch bei Entwicklung und Design von Software und deren Dokumentation. Dafür gibt es mittlerweile ausgereifte Hilfsmittel wie z. B. die UML.

        MfG H☼psel

        --
        "It's amazing I won. I was running against peace, prosperity, and incumbency."
        George W. Bush speaking to Swedish Prime Minister unaware a live television camera was still rolling, June 14, 2001
        Selfcode: ie:% fl:( br:> va:) ls:& fo:) rl:? n4:& ss:| de:] js:| ch:? sh:( mo:) zu:)
        1. Hello,

          Für diesen definierst du dann deine benötigten Funktionen, wie z. B. asCSV(), asPDF() oder asXML(), die alle auf den gleichen Daten arbeiten.

          was Cheatah mit der Factory angedeutet hat, man kann es noch weiter abstrahieren. Du baust dir gewissermaßen drei Ausgabeklasse hinter einem gemeinsamen Interface mit nur einer einzelnen output-Methode. Klasse 1 kann CSV, Klasse 2 XML und Klasse 3 HTML.
          Über eine Factory lässt du dir dann einfach nur noch eine Instanz der Ausgabeklasse geben und unabhängig davon wo du hinschreiben möchtest rufst du immer die output-Methode auf.

          MfG
          Rouven

          --
          -------------------
          sh:| fo:} ch:? rl:( br:& n4:{ ie:| mo:} va:) js:| de:] zu:| fl:( ss:) ls:& (SelfCode)
          "I wish it need not have happened in my time" - "So do I, and so do all who live to see such times. But that is not for them to decide. All we have to decide is what to do with the time that is given us."  --  J.R.R. Tolkien: "The Lord Of The Rings: The Fellowship Of The Ring"
          1. Hi Rouven!

            Für diesen definierst du dann deine benötigten Funktionen, wie z. B. asCSV(), asPDF() oder asXML(), die alle auf den gleichen Daten arbeiten.
            was Cheatah mit der Factory angedeutet hat, man kann es noch weiter abstrahieren.

            "Factory" ist ein Entwurfsmuster, oder? Ich habe zwar ein Buch darüber zu Hause liegen, aber im Moment muss ich erst einmal "Die Tore der Welt" zu Ende lesen. =)

            Du baust dir gewissermaßen drei Ausgabeklasse hinter einem gemeinsamen Interface mit nur einer einzelnen output-Methode. Klasse 1 kann CSV, Klasse 2 XML und Klasse 3 HTML.

            Okay, die Struktur verstehe ich.

            Über eine Factory lässt du dir dann einfach nur noch eine Instanz der Ausgabeklasse geben und unabhängig davon wo du hinschreiben möchtest rufst du immer die output-Methode auf.

            Aber wie wird dann entschieden, welche Klasse letztendlich für die Ausgabe zuständig ist?

            MfG H☼psel

            --
            "It's amazing I won. I was running against peace, prosperity, and incumbency."
            George W. Bush speaking to Swedish Prime Minister unaware a live television camera was still rolling, June 14, 2001
            Selfcode: ie:% fl:( br:> va:) ls:& fo:) rl:? n4:& ss:| de:] js:| ch:? sh:( mo:) zu:)
            1. Hello,

              Aber wie wird dann entschieden, welche Klasse letztendlich für die Ausgabe zuständig ist?

              das hängt vom Factory-Ansatz ab. Prinzipiell kann man das recht dynamisch halten, die extremste Variante wird auf Reflection (PHP Pendant unbekannt) setzen, d.h. du schnappst dir eine Konfigurationsdatei in der du einträgst ich möchte com.mypackage.MyImplClass verwenden und die Factory instanziert blind das was sie da liest. Damit kannst du also durch einen simplen Konfigurationseintrag komplett das Verhalten der Anwendung ändern.
              Etwas weniger radikal wäre die Kombination mit einem Enumeration-Pattern, d.h. du kennst eine bestimmte Anzahl von Formaten und sagst der Factory "mir ist egal wie, aber ich brauch eine Ausgabe vom Typ CSV". Die Factory wiederum hat ein Verzeichnis, in dem Typ auf Implementierung abgebildet wird.
              Wichtig ist halt in jedem Fall, dass nicht der Aufrufer entscheidet welche Implementierung er verwendet, er kennt die Auswahl gar nicht, er bekommt nur eine Klasse gem. einem definierten Interface in die Hand. Die dahinterliegende Implementierung liegt in der Verantwortung der Factory.

              MfG
              Rouven

              --
              -------------------
              sh:| fo:} ch:? rl:( br:& n4:{ ie:| mo:} va:) js:| de:] zu:| fl:( ss:) ls:& (SelfCode)
              When the only tool you've got is a hammer, all problems start to look like nails.
              1. Hellihello

                was den Einsatz von OOP angeht ist das http://framework.zend.com vielleicht von Interesse.

                Es basiert auch auf erwähnten Pattern (Singleton, MVC), ist Modular und hat u.a. auch eine Config-Klasse. Die Ordnerstruktur ergibt sich aus der Klassenstruktur.

                Dank und Gruß,

                frankx

                --
                tryin to multitain  - Globus = Planet != Welt
            2. Hi,

              was Cheatah mit der Factory angedeutet hat, man kann es noch weiter abstrahieren.

              muss man aber nicht. Es führen immer mehrere Wege zum Ziel, jeder hat seine eigenen Vor- und Nachteile. Wenn die einzige (oder fast einzige) Ausgabe bei der Produktliste stattfindet - warum nicht dort die Methoden halten?

              "Factory" ist ein Entwurfsmuster, oder?

              Ja.

              Aber wie wird dann entschieden, welche Klasse letztendlich für die Ausgabe zuständig ist?

              Wer oder was entscheidet, welche Ausgabe stattfinden soll?

              Cheatah

              --
              X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
              X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
              X-Will-Answer-Email: No
              X-Please-Search-Archive-First: Absolutely Yes
              1. Hi Cheatah!

                Aber wie wird dann entschieden, welche Klasse letztendlich für die Ausgabe zuständig ist?
                Wer oder was entscheidet, welche Ausgabe stattfinden soll?

                Rouven meinte:

                Du baust dir gewissermaßen drei Ausgabeklasse hinter einem gemeinsamen Interface mit nur einer einzelnen output-Methode. Klasse 1 kann CSV, Klasse 2 XML und Klasse 3 HTML.

                Außerdem:

                Über eine Factory lässt du dir dann einfach nur noch eine Instanz der Ausgabeklasse geben und unabhängig davon wo du hinschreiben möchtest rufst du immer die output-Methode auf.

                Die erste Aussage ist mir ja noch klar: Ich kann die Ausgabe-Methode einer Instanz der jeweiligen Ausgabeklasse über die output-Methode der Schnittstelle ansprechen.

                Aber wie ... [1]

                [2] Ich erzeuge mir also eine Instanz einer meiner drei Ausgabeklassen. Diese Ausgabeklassen wurden mit einem bestimmten Interface realisiert, das mir u. a. die Ausgabemethode "output" zur Verfügung stellt.
                Rufe ich diese Methode über meine Instanz auf, wird die entsprechende Ausgabemethode meiner Klasse aufgerufen. Richtig soweit?

                Vorteil des Interfaces ist die einheitliche Kapselung der Klassenschnittstelle und damit auch die einfachere Wartbarkeit und Verständlichkeit.
                Auch richtig?

                [1] Hier wurde mir soeben Rouvens Beschreibung klar. Siehe [2]. ;-)

                MfG H☼psel

                --
                "It's amazing I won. I was running against peace, prosperity, and incumbency."
                George W. Bush speaking to Swedish Prime Minister unaware a live television camera was still rolling, June 14, 2001
                Selfcode: ie:% fl:( br:> va:) ls:& fo:) rl:? n4:& ss:| de:] js:| ch:? sh:( mo:) zu:)
                1. Hi,

                  Aber wie wird dann entschieden, welche Klasse letztendlich für die Ausgabe zuständig ist?
                  Wer oder was entscheidet, welche Ausgabe stattfinden soll?

                  hiermit wollte ich übrigens wissen, was die Entscheidungsgrundlage ist und wann die Entscheidung stattfindet. Genauer gesagt wollte ich, dass Du es weißt ;-) da Du damit die Antwort auf Deine obige Frage findest.

                  [2] Ich erzeuge mir also eine Instanz einer meiner drei Ausgabeklassen. Diese Ausgabeklassen wurden mit einem bestimmten Interface realisiert, das mir u. a. die Ausgabemethode "output" zur Verfügung stellt.
                  Rufe ich diese Methode über meine Instanz auf, wird die entsprechende Ausgabemethode meiner Klasse aufgerufen. Richtig soweit?

                  Ja.

                  Vorteil des Interfaces ist die einheitliche Kapselung der Klassenschnittstelle und damit auch die einfachere Wartbarkeit und Verständlichkeit.
                  Auch richtig?

                  Ja.

                  [1] Hier wurde mir soeben Rouvens Beschreibung klar. Siehe [2]. ;-)

                  Ja :-)

                  Cheatah

                  --
                  X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
                  X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
                  X-Will-Answer-Email: No
                  X-Please-Search-Archive-First: Absolutely Yes
                  1. Hi Cheatah!

                    Danke!
                    *keksgeb* =)

                    MfG H☼psel

                    --
                    "It's amazing I won. I was running against peace, prosperity, and incumbency."
                    George W. Bush speaking to Swedish Prime Minister unaware a live television camera was still rolling, June 14, 2001
                    Selfcode: ie:% fl:( br:> va:) ls:& fo:) rl:? n4:& ss:| de:] js:| ch:? sh:( mo:) zu:)
            3. Hello,

              Für diesen definierst du dann deine benötigten Funktionen, wie z. B. asCSV(), asPDF() oder asXML(), die alle auf den gleichen Daten arbeiten.
              was Cheatah mit der Factory angedeutet hat, man kann es noch weiter abstrahieren.
              "Factory" ist ein Entwurfsmuster, oder? Ich habe zwar ein Buch darüber zu Hause liegen, aber im Moment muss ich erst einmal "Die Tore der Welt" zu Ende lesen. =)

              Factory-Methode ist eigentlich ein Wrapper um (ähnliche) Klassen, der verhindert, dass eine der Klassen mit falschen Rahmenbedingungen Kinder bzw. Instanzen erzeugen kann und dass ggf. noch zwischen den Klassen entschieden werden kann. Es ist also gewissermaßen die imperative Programierung  der OOP.

              Liebe Grüße aus Syburg bei Dortmund

              Tom vom Berg

              --
              Nur selber lernen macht schlau
              http://bergpost.annerschbarrich.de
              1. Hallo Tom,

                Factory und Factory-Methode sind erstmal zwei verschiedene Muster. Beide dienen sie dazu, von der Erzeugung eines Objektes zu abstrahieren. Das hat nichts mit imperativer Programmierung zu tun, man könnte eine Factory höchstens noch durch eine Funktionsreferenz ersetzen.

                Beispiel, eine Klasse, die graphisch eine Liste darstellt. Dazu werden Objekte benötigt, die einen einzelnen Eintrag darstellen. Die Implementierung soll aber nicht direkt festgelegt werden:

                abstract class Liste {

                void draw(Objekt[] objekte) {...}
                  void abstract neuerEintrag();

                }

                interface Eintrag {
                  void draw(Objekt o);
                }

                "neuerEintrag" ist eine Factory-Methode. Nun kann es passieren, dass man mehrere Klassen hat, die Objekte für die Schnittstelle Eintrag erzeugen wollen. Daher möchte man "neuerEintrag" nicht immer neu implementieren sondern auslagern:

                interface EintragFactory {
                  void neuerEintrag();
                }

                class Liste {

                Liste(EintragFactory f) {...}

                void draw(Objekt[] objekte) {...}

                }

                Nun ist auch keine Erweiterung der Klasse Liste mehr notwendig, man kann direkt eine entsprechende Implementierung von EintragFactory dem Konstruktor übergeben.

                Alternativ ist es möglich Funktions- bzw. Methodenreferenzen zu verwenden, wenn die Sprache dies unterstützt, dann würde der Konstruktor irgendwie so deklariert:

                Liste([void -> Eintrag] f) {...}

                Factories können natürlich komplexer sein und die Erzeugung verschiedener Objekte ermöglichen oder Information über die erzeugten Objekte bereitstellen, das ist aber eher selten der Fall.

                Grüße

                Daniel

                1. Hello Daniel,

                  Nicht eine Klasse entscheidet, welche objekte und Methoden instantiiert (und ggf. überschrieben werden), sondern eine Methode (auch Funktion) entscheidet, welche Klassen benutzt werden, um Objekte nebst ihren Spezifikationen (auch Methoden) zu erzeugen.

                  Die Klassen (Entwurfsmuster) selber sind dabei nicht direkt errecihbar.

                  Die Klasse ist dabei direkt an ihre umhüllende Methode/Funktion gebunden, da ja niemand anders sie erreichen kann.

                  Das ist zumindest meine Vorstellung von der Sache :-)

                  Liebe Grüße aus Syburg bei Dortmund

                  Tom vom Berg

                  --
                  Nur selber lernen macht schlau
                  http://bergpost.annerschbarrich.de
                  1. Hallo Tom,

                    Du denkst vermutlich an sowas:

                    public interface TuWas {
                      void tuWas();
                    }

                    private class Impl {
                      void tuWas() {...}
                    }

                    public class TuWasUtils {
                      public static TuWas neu() {
                        return new Impl();
                      }
                    }

                    Das gibt es zwar manchmal, ist jedoch meistens unnütz und ist keines der klassischen Entwurfsmuster. Das wird zwar manchmal als Fabrikmethode bezeichnet, ist aber nicht das, was ursprünglich mit Fabrikmethode gemeint ist.
                    Wie Du auch festgestellt hast, hat diese Variante mit Objektorientierung nichts zu tun. TuWasUtils ist ja auch keine echte Klasse, sondern nur eine Sammlung statischer Methoden. Natürlich kann so etwas auch mal hier und da in einem objektorientierten Programm hilfreich sein, groß darüber zu theoretisieren ist aber recht sinnlos.

                    Grüße

                    Daniel

                    1. Hello,

                      Das gibt es zwar manchmal, ist jedoch meistens unnütz und ist keines der klassischen Entwurfsmuster. Das wird zwar manchmal als Fabrikmethode bezeichnet, ist aber nicht das, was ursprünglich mit Fabrikmethode gemeint ist.

                      hmh, das kenne ich anders, einige andere offenbar auch. Das was du angegeben hast passt ziemlich genau zur FabrikMETHODE, es ist hingegen nicht deckungsgleich mit dem traditionellen Factory-Pattern - wobei man sich jetzt wahrscheinlich ellenlang streiten kann, wie das Verhältnis von Factory, Interface und Factorymethode ist...

                      MfG
                      Rouven

                      --
                      -------------------
                      sh:| fo:} ch:? rl:( br:& n4:{ ie:| mo:} va:) js:| de:] zu:| fl:( ss:) ls:& (SelfCode)
                      Don't lick your wounds: celebrate them. The scars you bear are the signs of a competitor.  --  character Richard Webber on Grey's Anatomy: 'Where the wild things are'
                      1. Hallo Rouven,

                        hmh, das kenne ich anders, einige andere offenbar auch.

                        Wieso, da steht doch genau, was ich sage. Evtl. erkennst Du nur den Unterschied nicht ;-)

                        Eine Fabrikmethode ist immer eine abstrakte Methode, die in abgeleiteten Klassen überschrieben wird, um benötigte Implementierungen einer Schnittstelle o.ä. zu erzeugen. Das sieht man auch sehr schön auf dem Klassendiagramm im Wikipedia-Artikel.

                        Eine Fabrikmethode ist keine statische Methode, die Objekte erzeugt. Eine Fabrikmethode erlaubt es, durch Ableitung und Überschreiben eine konkrete Implementierung einer Schnittstelle/abstrakten Klasse in eine andere Klasse einzubringen.

                        Die Beispiele im Artikel sind übringens in jedem Fall mist, da wird einfach nur irgend eine abstrakte Methode verwendet.

                        Das was du angegeben hast passt ziemlich genau zur FabrikMETHODE, es ist hingegen nicht deckungsgleich mit dem traditionellen Factory-Pattern

                        Ja, beide Entwurfsmuster stammen aus dem GoF-Buch und ich habe den Unterschied ja auch schon beschrieben. Factories sind oft eine Anwendung der Fabrikmethode, die Fabrikmethode wird praktisch in eine andere Klasse ausgelagert. Dadurch muss man nicht mehr ableiten um eine Implementierung einzubringen sondern man kann die Factory als Parameter übergeben.

                        wobei man sich jetzt wahrscheinlich ellenlang streiten kann, wie das Verhältnis von Factory, Interface und Factorymethode ist...

                        Nun, richtet man sich nach dem GoF-Buch, gibt es nicht so viel zu streiten. Nun kann man natürlich mit gutem Recht behaupten, dass man seine statische Methode Fabrikmethode nennen darf, wenn man das unbedingt tun will, aber ich bin dann doch eher dafür Begrifflichkeiten nicht zu wild durcheinander zu werfen ;-)

                        Grüße

                        Daniel

        2. Hellihello

          OO legt nicht einfach nur Programmierkonzepte fest. Es ist eine Philosophie

          s. a.
          OOP ist keine Philsophie von 1991 und von 2000: "nocheinmal an alle autoren: OOP ist keine philosophie sondern eine syntax und sollte als solche erklärt werden" unter http://www.daskochrezept.de/kochbuecher-shop/java-2-mit-methode-lernen-verstehen-anwenden_MzkzMjMxMTUzMQ==_0.html

          Meinem Gefühl nach ist der Begriff Philosophie hier auch eher irreführend, deshalb hab ich mal gegooget. "Philosophie" wäre eher für mich, wenn die zendframework-entwickler ein modulares System aufbauen, was sich etwas von dem Paradigma "convention over configuration" abgrenzen möchte und ohne "model" daherkommt. Auch die Auswahl der Pattern (Frontcontroller als Singleton, MVC) wäre für mich Philosophie.

          OOP ist für mich schlicht die Kapselung von Methoden und Daten, also eben ein "abstrakter Datentyp" wohl. Ein "abstrakter Datentyp" aber ist ja keine Philosophie, oder?

          Dank und Gruß,

          frankx

          --
          tryin to multitain  - Globus = Planet != Welt
          1. Hallo frankx,

            Deine zweite Quelle ist ein Besucherkommentar in einem Onlineshop zu einem Java-Buch? Was soll das denn Aussagen?

            Den Artikel in der "Computer-Woche" finde ich auch reichlich schwach. Er will der Objektorientierung das Philosophische absprechen, indem er sie dann als Paradigma bezeichnet? "Paradigma" ist ein wissenschaftstheoretischer Begriff und meint eine Denkweise, eine Richtung, aus der etwas betrachtet wird.
            Objektorientierung ist genau eine solche Denkweise. Die Wissenschaft, die sich mit dem Denken an sich beschäftigt, ist die Philosophie. Ob Objektorientierung also eine sinnvolle Art und Weise ist, die Realität zu beschreiben und wie dabei vorzugehen ist, ist damit im besten Sinne eine philosophische Frage.

            Objektorientierung ist zudem ganz sicher keine Syntax. Syntax kommt nicht aus dem nichts, sondern sie wird festgelegt, um Dinge aufschreiben zu können. Ohne sich Gedanken darüber zu machen, wie man nun die Realität sinnvoll modelliert, kann man auch keine Syntax schaffen, um solche Modelle zu notieren. Die objektorientierte Syntax wurde geschaffen, um die objektorientierte Vorstellung einfacher notieren zu können.

            Grüße

            Daniel

            1. Hellihello

              naja, vermutlich kann man  es so sehen. Mir hat es geholfen, nicht nach einer dahinter liegenden "Philosophie" zu suchen sondern schlicht die Erkenntnis, dass es sich um "abstratkte Datentypen" bzw. um die Kapselung von Funktionen und Eigenschaften handelt, innerhalb derer dann auf Klassenvariablen per "$this" oder "self" zugegriffen werden kann. Das und dass sie mittlerweile grundsätzlich als Referenz übergeben werden, hat für mich was die Programmierung angeht natürlich eine Bedeutung, aber mehr auch nicht.

              Sind für Dich "Pattern" wie Front-Controller, MVC oder Singleton auch Philsophien?

              Dank und Gruß,

              frankx

              --
              tryin to multitain  - Globus = Planet != Welt
              1. Hallo frankx,

                Auch "abstrakte Datentypen" sind ja schon mehr, als reine Syntax. Es sind Konzepte, wie man Systeme aufbauen kann. Und die basieren eben auf Überlegungen über die Struktur der Realität bzw. unserer Vorstellung von Realität. Abstrakte Datentypen erlauben es ja ähnlich wie objektorientierte Programmierung, Funktionen und Daten als Einheit zu betrachten und Systeme modular aufzubauen. Dem liegt eine gewisse Denkrichtung zu grunde, dass (reale) Objekte wiederum aus anderen Objekten aufgebaut sind.
                Es gibt aber ja auch andere Paradigmen wie beispielsweise funktionale Programmierung, wo sehr oft Algorithmen abstrahiert werden. Natürlich kann es hilfreich sein, das anhand einer konkreten Syntax zu erlernen. Vieles ist auch einfacher zu verstehen, wenn man es einfach mal sieht. Da lernt man die Ideen dahinter eher indirekt. Nur wenn man sich neue Konzepte ausdenken will, kann man so nicht vorgehen.

                Das und dass sie mittlerweile grundsätzlich als Referenz übergeben werden, hat für mich was die Programmierung angeht natürlich eine Bedeutung, aber mehr auch nicht.

                Wichtiger sind solche Überlegungen, um Objektmodelle zu entwerfen, also zu entscheiden, welche Objekte man braucht und in welchen Beziehungen die stehen sollen.

                Sind für Dich "Pattern" wie Front-Controller, MVC oder Singleton auch Philsophien?

                Naja, "Philosophien" klingt natürlich etwas hochtrabend. Ich würde sagen, dass hinter dem Gesamtkonzept der Entwurfsmuster eine gewisse Philosophie steckt. Da wurde ja versucht, elementare Strukturen von Modellen zu identifizieren.
                MVC und Front-Controller sind ja Architekturmuster. Die sind etwas schwammig, nicht sehr umfassend und werden auch nicht immer gleich gebraucht. Entwurfsmuster stellen ja ein Gesamtkonzept für Objektmodelle dar, MVC ist aber nicht bestandteil eines größeren Konzepts für Softwarearchitektur. Es wäre natürlich nicht schlecht, wenn sich jemand mal für Softwarearchitektur so etwas ausdenken würde, es gibt da meines Wissens aber nichts wirklich sclüssiges ;-)

                Grüße

                Daniel

                1. Hellihello Daniel,

                  Auch "abstrakte Datentypen" sind ja schon mehr, als reine Syntax. Es sind Konzepte, wie man Systeme aufbauen kann. Und die basieren eben auf Überlegungen über die Struktur der Realität bzw. unserer Vorstellung von Realität. Abstrakte Datentypen erlauben es ja ähnlich wie objektorientierte Programmierung, Funktionen und Daten als Einheit zu betrachten und Systeme modular aufzubauen.

                  Naja, "als Einheit zu betrachten"? Als einer Kategorie/Handlungseinheit/Abteilung zugehörig eher. Ist natürlich dann eine Einheit, die "Kapsel".

                  Dem liegt eine gewisse Denkrichtung zu grunde, dass (reale) Objekte wiederum aus anderen Objekten aufgebaut sind.

                  Nun mag man argumentieren, dass unsere Abstraktionen immer auf den realen Erfahrungen basiert. Ich finde da den Begriff "Objekte" fast etwas hinderlich, weil Klassen wie der "Front-Controller" oder "Dispatcher" ja fast eher wie Subjekte handeln. Ein "Objekt" kann ja eher weniger als ein "Subjekt" etwas "setten", "createn" oder "updaten". Abteilungen in einem Betrieb sind für mich da eher passende Sinnbilder.

                  Es gibt aber ja auch andere Paradigmen wie beispielsweise funktionale Programmierung, wo sehr oft Algorithmen abstrahiert werden. Natürlich kann es hilfreich sein, das anhand einer konkreten Syntax zu erlernen. Vieles ist auch einfacher zu verstehen, wenn man es einfach mal sieht. Da lernt man die Ideen dahinter eher indirekt. Nur wenn man sich neue Konzepte ausdenken will, kann man so nicht vorgehen.

                  "Paradigma" finde ich gefühlt passender als "Philosophie". Eine Philosophie ist ja eher was wie eine Weltanschauung, und daraus resutltierend zum Beispiel "Xtreme Programming" oder ein "modulares Design". Aber sicherlich verschwimmen da die Grenzen zu OOP, was ja eben auch ein "Modell" ist.

                  Das und dass sie mittlerweile grundsätzlich als Referenz übergeben werden, hat für mich was die Programmierung angeht natürlich eine Bedeutung, aber mehr auch nicht.
                  Wichtiger sind solche Überlegungen, um Objektmodelle zu entwerfen, also zu entscheiden, welche Objekte man braucht und in welchen Beziehungen die stehen sollen.

                  Jau, wie die Abteilungen oder Mitarbeiter in einem Team/Betrieb.

                  Naja, "Philosophien" klingt natürlich etwas hochtrabend. Ich würde sagen, dass hinter dem Gesamtkonzept der Entwurfsmuster eine gewisse Philosophie steckt. Da wurde ja versucht, elementare Strukturen von Modellen zu identifizieren.

                  Nun, Abstraktionen von Abläufen haben vermutlich immer was mit Philosophie zu tun.

                  MVC und Front-Controller sind ja Architekturmuster. Die sind etwas schwammig, nicht sehr umfassend und werden auch nicht immer gleich gebraucht. Entwurfsmuster stellen ja ein Gesamtkonzept für Objektmodelle dar, MVC ist aber nicht bestandteil eines größeren Konzepts für Softwarearchitektur. Es wäre natürlich nicht schlecht, wenn sich jemand mal für Softwarearchitektur so etwas ausdenken würde, es gibt da meines Wissens aber nichts wirklich sclüssiges ;-)

                  framework.zend.com finde ich ziemlich schlüssig, oder meinst du was anderes?

                  Dank und Gruß,

                  Robert aka

                  frankx

                  --
                  tryin to multitain  - Globus = Planet != Welt
                  1. Hallo frankx,

                    framework.zend.com finde ich ziemlich schlüssig, oder meinst du was anderes?

                    Ich meinte eher so etwas wie Entwurfsmuster für Softwarearchitektur. Entwurfsmuster lösen ja nur sehr kleine Probleme, wie bei Factories eben "Wie erreiche ich, dass eine Klasse von benötigten Implementierungen trenne". Wenn ich eine Anwendung entwerfe, habe ich erstmal ganz andere Probleme: Welche Komponenten brauche ich überhaupt, wie trenne ich Darstellung, Fuktionalität, Datenhaltung einerseits und trenne andererseits verschiedene funktionale Einheiten voneinander, etc.
                    Es gibt natürlich Lösungen für diese Bereiche und es gibt auch sehr gut entworfene Software (das Zend-Framework mag dazu gehören). Aber so einen Architekturbaukasten wie es den Entwurfsmusterbaukasten gibt, gibt es nicht. Nun lösen Entwurfsmuster sicher nicht alle Entwurfsprobleme, aber sie vermitteln zumindest mal eine sinnvolle Menge von Ideen.

                    Grüße

                    Daniel

                    1. Hellihello Daniel,

                      Ich meinte eher so etwas wie Entwurfsmuster für Softwarearchitektur. Entwurfsmuster lösen ja nur sehr kleine Probleme, wie bei Factories eben "Wie erreiche ich, dass eine Klasse von benötigten Implementierungen trenne".

                      Wenn ich eine Anwendung entwerfe, habe ich erstmal ganz andere Probleme: Welche Komponenten brauche ich überhaupt,

                      Suche ich mir die aus dem Framework zusammen, oder?

                      wie trenne ich Darstellung, Fuktionalität, Datenhaltung einerseits

                      MVC, anhand der vom Framework vorgeschlagenen Konventionen.

                      und trenne andererseits verschiedene funktionale Einheiten voneinander, etc.

                      Nehme ich für /artist , /location , /agency je drei verschiedene controller, wie beim Standardrouting des ZF vorgesehen, oder route ich zu einem Controller und einer View, die wiederum mit Datensätzen aus den zugrundeliegenden Tabellen gefüttert werden.

                      Es gibt natürlich Lösungen für diese Bereiche und es gibt auch sehr gut entworfene Software (das Zend-Framework mag dazu gehören).

                      Das wäre dann wohl das o.g.

                      Aber so einen Architekturbaukasten wie es den Entwurfsmusterbaukasten gibt, gibt es nicht.

                      Das kapier ich scheints nicht. Eine Abstraktionseben höher noch wohl, einen Baukasten für Baukästen? Ein Meta-Framework?

                      Nun lösen Entwurfsmuster sicher nicht alle Entwurfsprobleme, aber sie vermitteln zumindest mal eine sinnvolle Menge von Ideen.

                      Die Kombination von Front-Controller als Singleton mit MVC scheint mir recht funktional.

                      Dank und Gruß,

                      frankx

                      --
                      tryin to multitain  - Globus = Planet != Welt
                      1. Hallo frankx,

                        Suche ich mir die aus dem Framework zusammen, oder?

                        Ich meinte eher, wie gliedere ich die Anwendung in Komponenten, die ich dann selbst schreiben muss.

                        MVC, anhand der vom Framework vorgeschlagenen Konventionen.

                        MVC kümmert sich nur um zwei Ebenen, gut bei Webanwendungen ist die dritte meist die Datenbank. Außerdem sind Webanwendungen oft sehr monolitisch.

                        Nehme ich für /artist , /location , /agency je drei verschiedene controller, wie beim Standardrouting des ZF vorgesehen, oder route ich zu einem Controller und einer View, die wiederum mit Datensätzen aus den zugrundeliegenden Tabellen gefüttert werden.

                        Du erwähnst gar kein Datenmodell, anscheinend ist das Modell mit der Datenbank für Dich identisch. Bei sehr Datenbank-zentrierten Anwendungen ist das oft so. Es kann aber auch sein, dass Du ein Objektmodell hast, das von der ganzen Awendung verwendet wird, und weitere Objektmodelle, die von anderen funktionalen Komponenten (z.B. deinem /artist /location /agency) eingeklingt werden. Dieses Objektmodell muss dann wiederum in die Datenbank gespeichert werden können und das will man natürlich auch nicht zentral erledigen, sondern separat für jedes Teilmodell.

                        Das wäre dann wohl das o.g.

                        Ja, es ist eine Lösung für typische Webanwendungen. Gerade für datenbankbasierte Webanwednungen gibt es da sehr viel.

                        Das kapier ich scheints nicht. Eine Abstraktionseben höher noch wohl, einen Baukasten für Baukästen? Ein Meta-Framework?

                        Nein, Entwurfsmuster sind ja auch kein Framework, auch MVC ist kein Framework. Ich meinte eher eine Theorie, eine Herangehensweise. Vor allem eine, die nicht nur für Webanwednungen taugt. Das Thema Webanwendungen wird mit Frameworks und Standardarchitekturen ja geradezu zugeschüttet.

                        Die Kombination von Front-Controller als Singleton mit MVC scheint mir recht funktional.

                        Nur Singelton ist davon ein Entwurfsmuster und wahrscheinlich noch das fragwürdigste. Es wird nicht grundlos oft als die globale Variable der Objektorientierung bezeichnet ;-)

                        Viele Webanwedungen sind meiner Meinung nach sowieso nicht so sehr objektorientiert. Das liegt daran, dass eine Webanwendung oft nur Eingaben entgegen nimmt, mit der Datenbank kommuniziert und Daten wieder ausgibt.
                        Diese "Daten-rein-Daten-raus"-Architektur macht die Sache erstmal sehr einfach. Desktopanwendungen, wo wirklich ein objektorientiertes Datenmodell über die gesammte Anwendungslaufzeit existiert, sind da komplexer.
                        Die Komplexität der Webanwendungen steckt dann oft in irgend welchen SQL-Queries, die über die Anwedung verteilt sind. Das führt dann natürlich dazu, dass Information über die Struktur der Datenbank wild über die Anwendung verteilt ist. Mit Objektorientierung löst man das Problem allerdings auch nicht.

                        Grüße

                        Daniel

                        1. Hellihello Daniel,

                          Ich meinte eher, wie gliedere ich die Anwendung in Komponenten, die ich dann selbst schreiben muss.

                          Gut, wie Du unten schreibst ist der Spielraum bei Webseiten geringer.

                          MVC kümmert sich nur um zwei Ebenen, gut bei Webanwendungen ist die dritte meist die Datenbank. Außerdem sind Webanwendungen oft sehr monolitisch.

                          Auf _einem_ Kern aufbauend? Dem Front-Controller?

                          Nehme ich für /artist , /location , /agency je drei verschiedene controller, wie beim Standardrouting des ZF vorgesehen, oder route ich zu einem Controller und einer View, die wiederum mit Datensätzen aus den zugrundeliegenden Tabellen gefüttert werden.
                          Du erwähnst gar kein Datenmodell, anscheinend ist das Modell mit der Datenbank für Dich identisch.

                          Datenmodell? Ob Sql oder XML? Oder welche Variablen/Eigenschaften jedes Rubrikprofil mit sich bringt?

                          Bei sehr Datenbank-zentrierten Anwendungen ist das oft so.

                          Wie zentriere ich mich denn auf eine DB (== SQL?) Sie ist doch mehr oder minder "nur" Ablage für die Daten, mit denen ich hantieren möchte.

                          Es kann aber auch sein, dass Du ein Objektmodell hast, das von der ganzen Awendung verwendet wird, und weitere Objektmodelle, die von anderen funktionalen Komponenten (z.B. deinem /artist /location /agency) eingeklingt werden.

                          Das wären die Instanzen eines Action-Controllers und der View, die dann die entsprechenden Eigenschaften/getMethods kennen müssen?

                          Dieses Objektmodell muss dann wiederum in die Datenbank gespeichert werden können und das will man natürlich auch nicht zentral erledigen, sondern separat für jedes Teilmodell.

                          Ist eine XML-Struktur a la

                            
                          <schueler jahrgang="23" geschlecht="1">  
                           <name>sein name</name>  
                           <fremdsprachen>  
                            <option fremdsprache="englisch"/>  
                            <option fremdsprache="spanisch"/>  
                           </fremdsprachen>  
                          
                          

                          ggf. mit zugehöriger DTD ein solches Objektmodel? Eine Instanz eines SimpleXMLElemts zB.?

                          Das kapier ich scheints nicht. Eine Abstraktionseben höher noch wohl, einen Baukasten für Baukästen? Ein Meta-Framework?
                          Nein, Entwurfsmuster sind ja auch kein Framework, auch MVC ist kein Framework.

                          MVC wird als Entwurfsmuster von Zend bezeichnet, glaub ich, und verlinkt.

                          Ich meinte eher eine Theorie, eine Herangehensweise. Vor allem eine, die nicht nur für Webanwednungen taugt. Das Thema Webanwendungen wird mit Frameworks und Standardarchitekturen ja geradezu zugeschüttet.

                          Jau, bis hier Dedlfix irgendwann mal von ZF erzählte. Und sich das im letzten Jahr ordentlich in Kenntnis aller Konkurrenz/Alternativen entwickelt hat.

                          Nur Singelton ist davon ein Entwurfsmuster und wahrscheinlich noch das fragwürdigste. Es wird nicht grundlos oft als die globale Variable der Objektorientierung bezeichnet ;-)

                          Aha, so kam es mir auch vor. Ist es ja auch. Aber eine globale Variable gekapselt in einer Klasse ist ja so global nicht mehr.

                          Zend_Controller is the heart of Zend Framework's MVC system. MVC stands for Model-View-Controller and is a design pattern targeted at separating application logic from display logic. Zend_Controller_Front implements a FrontController pattern, in which all requests are

                          pattern != Entwurfsmuster?

                          Viele Webanwedungen sind meiner Meinung nach sowieso nicht so sehr objektorientiert. Das liegt daran, dass eine Webanwendung oft nur Eingaben entgegen nimmt, mit der Datenbank kommuniziert und Daten wieder ausgibt.

                          S.o.

                          Die Komplexität der Webanwendungen steckt dann oft in irgend welchen SQL-Queries, die über die Anwedung verteilt sind. Das führt dann natürlich dazu, dass Information über die Struktur der Datenbank wild über die Anwendung verteilt ist. Mit Objektorientierung löst man das Problem allerdings auch nicht.

                          Wieso nicht? Dann liegen die Queries im Model, die Ausgabe in der View und dazwischen, ganz schlank, ein paar Verdrahtungen.

                          Die Implementierung von Interfaces und Nutzung abstrakter Klassen geht ja ohne OOP wohl auch nicht, oder?

                          Dank und Gruß,

                          frankx

                          --
                          tryin to multitain  - Globus = Planet != Welt
                          1. Hallo frankx,

                            Auf _einem_ Kern aufbauend? Dem Front-Controller?

                            Vielleicht, aber eher der Datenbank.
                            Stellen wir uns mal eine Webanwendung aus mehreren Komponenten vor. Forum, CMS, vielleicht ein Wiki, eine Suche, ...
                            Es gibt natürlich irgendwie eine Benutzerverwaltung, die mit vielen dieser Komponenten verknüpft ist. CMS und Wiki sind ähnlich, man kann also vielleicht eine Komponente für gemeinsame Funktionalität bauen. Die Suche muss irgendwie Daten aller anderen Komponenten indexieren können. Außerdem will man die Forenfunktionalität vielleicht noch nutzen, um über Artikel im CMS oder Wiki zu diskutieren.
                            Nun gibt es für all diese Dienste bestimmte Tabellen in der Datenbank. Was man jetzt natürlich nicht will, ist, dass z.B. die Suche direkt auf den CMS-Tabellen arbeitet. Andererseits muss der Suchindex aber irgendwie auf Dokumente verweisen können, ohne etwas über die genaue Art dieser Dokumente zu wissen, Dokumente die es nicht mehr gibt, müssen aus dem Index gelöscht werden etc. An dieser Stelle wird Architektur eigentlich erst komplex.
                            Wenn man nun ein Datenmodell und Objektmodell aus einem Guss hat, das all diese Anforderungen berücksichtigt, dann geht das alles sehr einfach. Die Anwendung ist aber nicht mehr modular.

                            Wie zentriere ich mich denn auf eine DB (== SQL?) Sie ist doch mehr oder minder "nur" Ablage für die Daten, mit denen ich hantieren möchte.

                            Naja, in einem beispielhaften, objektorientierten Programm gibt es Klassen, die den Ausschnitt der Realität beschreiben, mit dem die Anwedung arbeitet. Also Beispielsweise für ein CMS: Dokument, DokumentVersion, Benutzer, Abschnitt, ...
                            Diese Objekte sind Anwendungsspezifisch, gemeint ist also nicht etwa eine reine Darstellung des Datenformats wie ein XML-Baum o.ä.
                            In diesen Klassen ist die eigentliche Funktionalität realsiiert, also Dokumente anlegen, ändern etc.
                            Bei Webanwendungen passiert das oft alles direkt in der Datenbank. Es muss ja auch nicht unbedingt sinnvoll sein, große Objektgraphen aufzubauen, wenn man das gar nicht braucht.

                            MVC wird als Entwurfsmuster von Zend bezeichnet, glaub ich, und verlinkt.

                            Entwursmuster und Designpattern sind schon das gleiche. Der Begriff Designpattern wurde aber nicht für so konkrete Dinge wie MVC eingeführt, die eine Lösung für ein ganz konkretes Problem darstellen, sondern für abstraktere Lösungen. Eben Singleton, Factory, Visiter, Composite, etc.

                            Aha, so kam es mir auch vor. Ist es ja auch. Aber eine globale Variable gekapselt in einer Klasse ist ja so global nicht mehr.

                            Naja. Das Problem damit ist im wesentlichen, dass aller Code, der direkt auf so einen Sigleton zugreift, gar nicht mehr mit einem anderen Objekt aufgerufen werden kann, als dem, dass der Singleton zurückgibt. Man kann sich damit leicht die Flexibilität seines Codes zerschießen.
                            Beispiel: Oft wird z.B. eine Datenbankverbindung o.ä. als Singleton angelegt. Will man nun plötzlich mal seine Klassen dazu verwenden, um Daten von einer Datenbank in die andere zu kopieren, hat man ein Problem, weil man sie nicht mehr einfach zwei mal für verschiedene Datenbanken instanzieren kann.

                            pattern != Entwurfsmuster?

                            Entwurfsmuster sind einfach spezielle Muster, die englische Entsprechung ist wie gesagt Desgin Pattern.
                            Nun reden die Leute von Zend da tatsächlich von Design Patterns, ihre Quelle aber tut das nicht. Die nennt das "Patterns of Enterprise Application Architecture". Also Architekturmuster für einen ganz bestimmten Anwendungstyp.
                            Entwurfsmuster == Muster für eher kleine, lokale und allgemeine Probleme beim objektorientierten Entwurf.
                            Architekturmuster: Muster die die Gesamtarchitektur der Anwendung betreffen und eher problemspezifisch.

                            Ein Entwurfsmuster würde nie irgendwie Begriffe wie "graphische Darstellung", "Anwendungsdaten", "Anwendungslogik" etc. verwenden.

                            Wieso nicht? Dann liegen die Queries im Model, die Ausgabe in der View und dazwischen, ganz schlank, ein paar Verdrahtungen.

                            Eben, die Queries liegen dann im Modell. Damit hast Du gleich zwei Probleme: Erstens kann es schwierig sein, die Queries sauber einzelnen Modellklassen zuzuordnen und wahrscheinlich werden viele Queries Information über Tabellen fremder Modellklassen benötigen. Damit änderst Du möglicherweise etwas an der Implementierung einer Modellklasse und zugehöriger Tabelle und stellst dann fest, dass Du auch noch andere Klassen ändern musst.
                            Das zweite Problem ist: Du kannst nicht mehr so flexibel auf die Datenbank zugreifen, da Du nicht einfach mal schnell ein Query über mehrere Tabellen weg ausführen kannst, sondern nur mit den Operationen auskommen musst, die das Modell bietet. Man kann dann natürlich anfangen, komplexere Abfragemöglichkeiten in das Modell zu stecken, das vergrößert dann wieder das andere Problem.

                            Um Objektorientierung und Datenbanken zusammenzubringen, gibt es Object-Relation-Mapper. Vielleicht bietet Zend auch etwas in dieser Richtung? Da kann man dann Queries auf Objektebene formulieren und SQL wird im Hintergrund automatisch erzeugt. Damit kann man dann auch gleich ganze Objektgraphen aus der Datenbank holen oder Objekte automatisch aus der Datenbank nachladen, wenn man sie braucht.
                            Das ist zwar eine ganz praktische Sache, etwas achtsam sein, was denn nun wirklich wann wo geladen wird, muss man aber auch da.

                            Die Implementierung von Interfaces und Nutzung abstrakter Klassen geht ja ohne OOP wohl auch nicht, oder?

                            Ja, aber wofür verwendest Du diese Dinge? Für Controller, View, Actions usw? Oder auch um die Daten abzubilden?

                            Grüße

                            Daniel

                            1. Hellihello

                              Beispiel: Oft wird z.B. eine Datenbankverbindung o.ä. als Singleton angelegt. Will man nun plötzlich mal seine Klassen dazu verwenden, um Daten von einer Datenbank in die andere zu kopieren, hat man ein Problem, weil man sie nicht mehr einfach zwei mal für verschiedene Datenbanken instanzieren kann.

                              Den Front-Controller aber kann es ja nur einmal geben. Dadurch wird er dann auch zu so einer Art Registrierung, weil alle Plugins sich dort eintragen.

                              Wieso nicht? Dann liegen die Queries im Model, die Ausgabe in der View und dazwischen, ganz schlank, ein paar Verdrahtungen.
                              Eben, die Queries liegen dann im Modell. Damit hast Du gleich zwei Probleme: Erstens kann es schwierig sein, die Queries sauber einzelnen Modellklassen zuzuordnen und wahrscheinlich werden viele Queries Information über Tabellen fremder Modellklassen benötigen. Damit änderst Du möglicherweise etwas an der Implementierung einer Modellklasse und zugehöriger Tabelle und stellst dann fest, dass Du auch noch andere Klassen ändern musst.

                              Weil denen dann Funktionen des Interfaces fehlen? Habe ich das Problem auch, wenn ich erst ein Iterface definiere und dann eine abstrakte Klasse als Implementierung, von der die anderen Model-Klassen erben?

                              Das zweite Problem ist: Du kannst nicht mehr so flexibel auf die Datenbank zugreifen,

                              Ob jetzt SQL-Datenbank oder XML oder serialized-data ist dabei wohl egeal, oder?

                              da Du nicht einfach mal schnell ein Query über mehrere Tabellen weg ausführen kannst, sondern nur mit den Operationen auskommen musst, die das Modell bietet. Man kann dann natürlich anfangen, komplexere Abfragemöglichkeiten in das Modell zu stecken, das vergrößert dann wieder das andere Problem.

                              Hier verstehe ich vermutlich erst, wenn mir das mal wirklich unter die Finger kommt. Eine Abfrage über Tabellen hinweg könnte doch von einer weitern Klasse realisiert werden, die dann auf die "Tabellen"-Klassen zugreift, dachte ich.

                              Um Objektorientierung und Datenbanken zusammenzubringen, gibt es Object-Relation-Mapper. Vielleicht bietet Zend auch etwas in dieser Richtung? Da kann man dann Queries auf Objektebene formulieren und SQL wird im Hintergrund automatisch erzeugt. Damit kann man dann auch gleich ganze Objektgraphen aus der Datenbank holen oder Objekte automatisch aus der Datenbank nachladen, wenn man sie braucht.

                              Zend bietet nur "V" und "C", kein "M". "model can be anything". Das deren "Philsophie", wenn ich das recht kapiere. Zumindest ist das ein sicher nicht unwesentlicher Unterschied zu RoR.

                              Die Implementierung von Interfaces und Nutzung abstrakter Klassen geht ja ohne OOP wohl auch nicht, oder?
                              Ja, aber wofür verwendest Du diese Dinge? Für Controller, View, Actions usw? Oder auch um die Daten abzubilden?

                              Was meint "Daten abbilden"? Ich hatte überlegt, ein Model-Interface zu definieren:

                                
                              interface My_Model_Interface  
                              {  
                                  function getForm();  
                                  function create();  
                                  function read();  
                                  function update();  
                                  function getList();  
                              }  
                              
                              

                              und dann eine abstrakte Klasse als Implementation.

                                
                                
                              <?php  
                              abstract class My_Model_XML_Abstract implements  My_Model_Interface  
                              {  
                                  //~ private $_model = NULL;  
                                
                                  // still missing:  
                                  private function _setData() {}  
                                  private function _getData() {}  
                                
                                
                                  function __construct($modelFileName)  
                                  {  
                                      $this->_model = My_Model_ModelReader::getModel($modelFileName);  
                                  }  
                                
                                  public function getForm()  
                                  {  
                                      return new My_Model_FormCreator($this->_model);  
                                  }  
                                
                                  // still missing:  
                                  public function create() {}  
                                  public function read() {}  
                                  public function update(){}  
                                  public function getList() {}  
                              }  
                                
                              
                              

                              Dann würden die Controller über diese Schnittstelle auf Daten zugreifen und "wüssten" nicht, ob dabei das Model die Daten aus einer XML-Datenbank oder SQL-Datenbank oder einem serialisierten File holt.

                              Ich dachte, so würde man Modularität ermöglichen. Ich könnte das Model unabhängig von den Controllern ausbauen, ohne je bei den Controllern was änderen zu müssen.

                              Zeichnet sich Modulariät nich dadurch aus, dass man immer die Möglichkeit hat, weitere Schnittstellen anzubieten (zB. innerhalb des Models) um Spezialaufgaben an u.U. neue Klassen zu deligieren, _ohne_ die bereits vorhanden Klassen dadurch zu berührern?

                              Dank und Gruß,

                              frankx

                              --
                              tryin to multitain  - Globus = Planet != Welt
                              1. Hallo frankx,

                                Den Front-Controller aber kann es ja nur einmal geben. Dadurch wird er dann auch zu so einer Art Registrierung, weil alle Plugins sich dort eintragen.

                                Ja, Sigletons sind ja auch nicht immer falsch. Man kann sich da nur leicht irren, weil man eine bestimmte Anwendung im Kopf hat. Das Problem entsteht auch weniger durch den Singleton an sich sondern dadurch, dass man darauf dann aus allen unmöglichen Stellen zugreift.

                                Weil denen dann Funktionen des Interfaces fehlen? Habe ich das Problem auch, wenn ich erst ein Iterface definiere und dann eine abstrakte Klasse als Implementierung, von der die anderen Model-Klassen erben?

                                Ich denke z.B. an so was: Du hast eine Tabelle Benutzer, eine Tabelle Gruppen und eine Zuordnungstabelle. Im Klassenmodell hast Du dann eine Klasse Benutzer und eine Klasse Gruppe. Wenn Du alle Benutzer-Objekte für eine Gruppe brauchst, würdest Du sowas machen:
                                Gruppe gruppe = BenutzerVerwaltung.getGruppe("name");
                                Benutzer[] benutzer = gruppe.getBenutzer();
                                Dazu müsstest Du intern zwei SQL-Queries ausführen: "select * from gruppen where name='name'" und "select * from benutzer as t1, gruppen2benutzer  as t2 where t1.id = t2.benutzer and t2.gruppe = gruppenid".

                                Mit SQL könntest Du direkt so etwas machen:
                                "select * from benutzer as t1, gruppen2benutzer as t2, gruppen as t3 where t1.id = t2.benutzer and t2.gruppe = t3.id and t3.name = 'gruppenname'"

                                Das lässt sich beliebig verkomplizieren, sodass Du beim objektorientierten Fall viel mehr Queries brauchst als bei direkter Verwendung von SQL.
                                Mit einem Object-Relation-Mapper könnten man Queries auf Objekt-Ebene formulieren:
                                Benutzer[] benutzer = orm.execute("from Benutzer benutzer where benutzer.gruppe.name = 'gruppenname'");

                                Ob jetzt SQL-Datenbank oder XML oder serialized-data ist dabei wohl egeal, oder?

                                Nein, jede Form von Serialisierung ist einfacher, weil man dabei schlicht alle Daten einliest und alle Abfragen dann auf dem Objektgraphen durchführt. Das Problem ist diese Möglichkeit, Daten schon in der Datenbank zu verarbeiten und im Programm selbst. Ob man eine relationale Datenbank oder eine XML-Datenbank hat, dürfte hingegen egal sein. Natürlich kann man auch bei einer Datenbank einfach erstmal alles auslesen, aber das ist wohl kein praktikabler Ansatz.

                                Hier verstehe ich vermutlich erst, wenn mir das mal wirklich unter die Finger kommt. Eine Abfrage über Tabellen hinweg könnte doch von einer weitern Klasse realisiert werden, die dann auf die "Tabellen"-Klassen zugreift, dachte ich.

                                Richtig, aber es ist oft weniger effizient. Siehe obiges Beispiel. Das führt dazu, dass man letzten endes alle Joins auf dem Objektmodell berechnet, statt das von der Datenbank machen zu lassen.

                                Zend bietet nur "V" und "C", kein "M". "model can be anything".

                                Ja, das heißt wohl "Model muss man selber machen" oder eben gar nicht. Wobei gar nicht je nach Anwendung durchaus sinnvoll sein kann, nach meiner Auffassung.

                                Zumindest ist das ein sicher nicht unwesentlicher Unterschied zu RoR.

                                Mit RoR habe ich mich noch nicht beschäftigt, aber die scheinen wohl etwas zu machen, was dem Object-Relation-Mapping-Ansatz entspricht.

                                interface My_Model_Interface
                                {
                                    function getForm();
                                    function create();
                                    function read();
                                    function update();
                                    function getList();
                                }

                                Das sieht ziemlich prozedural aus. Kann natürlich dennoch sinnvoll sein. Für obiges Benutzerbeispiel hättest Du wohl sowas:  
                                interface Benutzerverwaltung {  
                                   Gruppe getGruppe(name);  
                                   Benutzer getBenutzer(name);  
                                   Benutzer[] getBenutzerForGruppe(name);  
                                   ...  
                                }  
                                Sicher sinnvoll, man kann sicher auch dafür etwas Objektorientierung nutzen, um die Art der Datenhaltung austauschbar zu machen, das ist aber kein Datenmodell.  
                                Ein Datenmodell würde einzelne Datensätze einer Tabelle jeweils als Objekt repräsentieren. Eben eine Klasse Benutzer und eine Klasse Gruppe, wobei eine Instanz einer solche Klasse genau einen konkreten Benutzer oder eine Gruppe repräsentieren.  
                                  
                                
                                > Dann würden die Controller über diese Schnittstelle auf Daten zugreifen und "wüssten" nicht, ob dabei das Model die Daten aus einer XML-Datenbank oder SQL-Datenbank oder einem serialisierten File holt.  
                                
                                Ja, aber er könnte keine Abfrage formulieren, für die Du keine Methode vorgesehen hast. Damit musst Du letzten endes alle erdenklichen Abfragen als Funktionen bereitstellen. Wenn eine neue Komponete eine weitere Abfrage braucht, musst Du diese hinzufügen, Du kannst sie nicht in der Komponente selbst implementieren.  
                                  
                                
                                > Ich dachte, so würde man Modularität ermöglichen. Ich könnte das Model unabhängig von den Controllern ausbauen, ohne je bei den Controllern was änderen zu müssen.  
                                
                                Ja, das ist sicher eine Form von Modularität. Aber umgekehrt möchte man natürlich auch ändern können, was die Controller mit den Daten tun, ohne am Modell etwas ändern zu müssen, jedenfalls zu einem gewissen Grad.  
                                  
                                
                                > Zeichnet sich Modulariät nich dadurch aus, dass man immer die Möglichkeit hat, weitere Schnittstellen anzubieten (zB. innerhalb des Models) um Spezialaufgaben an u.U. neue Klassen zu deligieren, \_ohne\_ die bereits vorhanden Klassen dadurch zu berührern?  
                                
                                Ja und dadurch, die Implemetierung bestehender Klassen ändern zu können, ohne darauf aufbauende Klassen ändern zu müssen. Das erfüllt Dein Ansatz aber nur eingeschränkt, Du musst Die Modell-Klasse ändern, wenn der Controller weiter Abfragen ausführen muss.  
                                Wenn Du mehrere Modell-Klassen für unterschiedliche Funktinalitäten hast (Beispiel: Benutzerverwaltung, Dokumentverwaltung) gibt es zudem keinen logischen Ort, wo man bestimmte Queries unterbringen könnte. Wenn Dokumenten beispielsweise eine Benutzergrupppe zugeordnet ist, die das Dokument ändern darf, hätte man eventuell gerne so eine Funktion:  
                                boolean canUserChangeDocument(docid, userid);  
                                Wenn man das wieder mit einem SQL-Query bestimmen will, muss man wissen, wie Benutzer und Gruppen zugeordnet werden und wie Dokumente Gruppen referenzieren. Bringt man die Methode in der Klasse für Dokumente unter, muss man diese Klasse ändern, sobald man z.B. die Benutzerverwaltung so ändert, dass Gruppen wiederum Gruppen enthalten können o.ä. Bringt man die Methode in der Klasse der Benutzerverwaltung unter, hat man die Methode da drin, selbst wenn man die Komponente Dokumentenverwaltung gerade gar nicht benötigt. Ändert man etwas an der Dokumentenverwaltung, z.B. mehrere Gruppen können einem Dokument zugeordnet werden, muss man zudem auch die Benutzerverwaltung ändern.  
                                Das ist, was ich mit schlechter Modulariät meine.  
                                  
                                Für eine typische Webanwendung aus einem Guss muss das wie gesagt kein Problem sein. Wenn man diese Modularität gar nicht braucht, kein Objektmodell braucht, um darauf irgendwelche komplexeren Verfahren zu implementieren, dann ist Dein Ansatz durchaus eine vernünftige herangehensweise. Man muss die Dinge ja nicht komplizierter machen, als sie schon sind.  
                                  
                                Ich hab' gerade mal nach ORM-Werkzeugen für PHP gesucht und hab' das hier gefunden: <http://ezcomponents.org/docs/tutorials/PersistentObject>  
                                Keine Ahnung, wie gut das ist, ich kenne solche Dinge nur von Java, beispielsweise: <http://www.hibernate.org/>  
                                Auch ORM löst nicht alle Probleme und bringt auch erstmal zusätzliche Komplexität mit sich, es lohnt sich aber bestimmt, sich das mal anzusehen.  
                                  
                                Grüße  
                                  
                                Daniel  
                                  
                                
                                
                                1. Hellihello Daniel,

                                  merci für Deine Ausführungen.

                                  Gruppe gruppe = BenutzerVerwaltung.getGruppe("name");
                                  Benutzer[] benutzer = gruppe.getBenutzer();
                                  Dazu müsstest Du intern zwei SQL-Queries ausführen: "select * from gruppen where name='name'" und "select * from benutzer as t1, gruppen2benutzer  as t2 where t1.id = t2.benutzer and t2.gruppe = gruppenid".

                                  Mit SQL könntest Du direkt so etwas machen:
                                  "select * from benutzer as t1, gruppen2benutzer as t2, gruppen as t3 where t1.id = t2.benutzer and t2.gruppe = t3.id and t3.name = 'gruppenname'"

                                  Das lässt sich beliebig verkomplizieren, sodass Du beim objektorientierten Fall viel mehr Queries brauchst als bei direkter Verwendung von SQL.

                                  Ja, sowas schwante mir doch.

                                  Hier verstehe ich vermutlich erst, wenn mir das mal wirklich unter die Finger kommt. Eine Abfrage über Tabellen hinweg könnte doch von einer weitern Klasse realisiert werden, die dann auf die "Tabellen"-Klassen zugreift, dachte ich.
                                  Richtig, aber es ist oft weniger effizient. Siehe obiges Beispiel. Das führt dazu, dass man letzten endes alle Joins auf dem Objektmodell berechnet, statt das von der Datenbank machen zu lassen.

                                  Was wiederum heißt, dass das dann bei den Controllern liegt, "SQL zu können".

                                  Zend bietet nur "V" und "C", kein "M". "model can be anything".
                                  Ja, das heißt wohl "Model muss man selber machen" oder eben gar nicht. Wobei gar nicht je nach Anwendung durchaus sinnvoll sein kann, nach meiner Auffassung.

                                  Ich fand die Stellen dazu auch erstmal nicht unüberzeugend.

                                  interface My_Model_Interface
                                  {
                                      function getForm();
                                      function create();
                                      function read();
                                      function update();
                                      function getList();
                                  }

                                  
                                  > Das sieht ziemlich prozedural aus.  
                                    
                                  Was daran ist denn "prozedural"? Oder anders: welche Funktion wäre nicht prozedural? Das getBenutzerForGruppe()?  
                                    
                                    
                                  
                                  > Ja, aber er könnte keine Abfrage formulieren, für die Du keine Methode vorgesehen hast. Damit musst Du letzten endes alle erdenklichen Abfragen als Funktionen bereitstellen. Wenn eine neue Komponete eine weitere Abfrage braucht, musst Du diese hinzufügen, Du kannst sie nicht in der Komponente selbst implementieren.  
                                    
                                  Jau, man schreibt quasi ein Sub-SQL bzw. eben datenbankunabhängige Funktionen, die man dann in xpath oder sql-queries umwandelt. Wenn das aber alles in den Controllern landet, dann ließe sich aber das Datenbankmodell nicht modular austauschen, was ja vielleicht auch nicht sinnvoll ist. Ich hänge irgendwie an dem XML unter anderm der schönen xpath-queries wegen und aber auch der human-readability wegen. Und dachte aber: wer weiß, wird das irgendwann mal zuviel für xml, brauch ich wegen Schnelligkeit oder Zugriffskontrolle doch lieber SQL, könnte ich umstellen. Aber das Erfinden eigener Query-Syntax in den Klassenmethoden ist mir auch nicht wirklich geheuer.  
                                    
                                  
                                  > > Zeichnet sich Modulariät nich dadurch aus, dass man immer die Möglichkeit hat, weitere Schnittstellen anzubieten (zB. innerhalb des Models) um Spezialaufgaben an u.U. neue Klassen zu deligieren, \_ohne\_ die bereits vorhanden Klassen dadurch zu berührern?  
                                  > Ja und dadurch, die Implemetierung bestehender Klassen ändern zu können, ohne darauf aufbauende Klassen ändern zu müssen. Das erfüllt Dein Ansatz aber nur eingeschränkt, Du musst Die Modell-Klasse ändern, wenn der Controller weiter Abfragen ausführen muss.  
                                    
                                  Aber wäre das nicht ein Singel-Point-Of-Change in der abstrakten Modelklasse?  
                                    
                                  
                                  > Wenn Du mehrere Modell-Klassen für unterschiedliche Funktinalitäten hast (Beispiel: Benutzerverwaltung, Dokumentverwaltung) gibt es zudem keinen logischen Ort, wo man bestimmte Queries unterbringen könnte. Wenn Dokumenten beispielsweise eine Benutzergrupppe zugeordnet ist, die das Dokument ändern darf, hätte man eventuell gerne so eine Funktion:  
                                  > boolean canUserChangeDocument(docid, userid);  
                                  > Wenn man das wieder mit einem SQL-Query bestimmen will, muss man wissen, wie Benutzer und Gruppen zugeordnet werden und wie Dokumente Gruppen referenzieren. Bringt man die Methode in der Klasse für Dokumente unter, muss man diese Klasse ändern, sobald man z.B. die Benutzerverwaltung so ändert, dass Gruppen wiederum Gruppen enthalten können o.ä. Bringt man die Methode in der Klasse der Benutzerverwaltung unter, hat man die Methode da drin, selbst wenn man die Komponente Dokumentenverwaltung gerade gar nicht benötigt. Ändert man etwas an der Dokumentenverwaltung, z.B. mehrere Gruppen können einem Dokument zugeordnet werden, muss man zudem auch die Benutzerverwaltung ändern.  
                                  > Das ist, was ich mit schlechter Modulariät meine.  
                                    
                                  Grmpf.  
                                    
                                  
                                  > Für eine typische Webanwendung aus einem Guss muss das wie gesagt kein Problem sein. Wenn man diese Modularität gar nicht braucht, kein Objektmodell braucht, um darauf irgendwelche komplexeren Verfahren zu implementieren, dann ist Dein Ansatz durchaus eine vernünftige herangehensweise. Man muss die Dinge ja nicht komplizierter machen, als sie schon sind.  
                                    
                                  Hm.  
                                    
                                  
                                  > Ich hab' gerade mal nach ORM-Werkzeugen für PHP gesucht und hab' das hier gefunden: [http://ezcomponents.org/docs/tutorials/PersistentObject](http://ezcomponents.org/docs/tutorials/PersistentObject)  
                                  > Keine Ahnung, wie gut das ist, ich kenne solche Dinge nur von Java, beispielsweise: [http://www.hibernate.org/](http://www.hibernate.org/)  
                                  > Auch ORM löst nicht alle Probleme und bringt auch erstmal zusätzliche Komplexität mit sich, es lohnt sich aber bestimmt, sich das mal anzusehen.  
                                    
                                  Und ich fand noch <http://framework.zend.com/wiki/display/ZFPROP/Zend_Generator_Orm+-+Thomas+VEQUAUD> in <http://www.zfforums.com/zend-framework-general-discussions-1/general-q-zend-framework-2/zend-orm-268.html>  
                                    
                                    
                                  Und auch <http://www.zietlow.net/zend-framework/mvc-model%E2%80%93view%E2%80%93controller-im-zend-framework/16/>  
                                    
                                  "MVC im Zend Framework  
                                    
                                  Das Zend Framework ist nach dem MFC Architekturmuster aufgebaut.  
                                  Die MVC Theorie sollte klar sein, ab hier wird jetzt die technische Umsetzung im Zend Framework beschrieben.  
                                  Model  
                                    
                                  Derzeit – und ich denke auch in Zukunft – gibt es keine generelle Komponente für das Model.  
                                  Wir wissen, dass das Model die Geschäftslogik und die Daten beinhaltet.  
                                    
                                  Bei dem Model handelt es sich also um Klassen, die Daten aus Datenbanken, Web Services, Feeds, Konfigurationsdateien, Dateisystem und anderen Quellen „her holen“ und diese – je nach Geschäftslogik – verarbeiten.  
                                  Das ist meist so individuell das es keinen Sinn macht das Model vorzuschreiben.  
                                    
                                  Doch das Zend Framework bietet für die verschiedensten Zugriffe Unterstützung an, zum Beispiel:  
                                    
                                      \* Zend\_Db: auf Datenbanken zuzugreifen  
                                      \* Zend\_Service\_\*: Entsprechenden Webservices aufrufen  
                                      \* Zend\_Config: Konfigurationsdateien auszulesen"  
                                    
                                    
                                  Dank und Gruß,  
                                    
                                  [frankx](http://community.de.selfhtml.org/visitenkarten/view.php?key=82)
                                  
                                  -- 
                                  [tryin to](http://sauer-ernst.de) [multitain](http://multitain.de)  - Globus = Planet != Welt 
                                  
                                  1. Hallo frankx,

                                    Was daran ist denn "prozedural"? Oder anders: welche Funktion wäre nicht prozedural? Das getBenutzerForGruppe()?

                                    Doch, sowas wie getBenutzerForGruppe() ganz besonders.
                                    Prozedural ist die Schnittstelle, weil sie einfach eine Menge von Algorithmen zur Datenabfrage zur Verfügung stellt. Es kommt ein Aufruf mit Parametern rein und eine Menge von Daten zurück. Eine Objektorientierte Schnittstelle würde die Daten in Objekte strukturieren (die Benutzer- und Gruppen-Objekte im Beispiel) und die Algorithmen auf diese Objekte aufteilen.

                                    Jau, man schreibt quasi ein Sub-SQL bzw. eben datenbankunabhängige Funktionen, die man dann in xpath oder sql-queries umwandelt. Wenn das aber alles in den Controllern landet, dann ließe sich aber das Datenbankmodell nicht modular austauschen, was ja vielleicht auch nicht sinnvoll ist.

                                    Das Modell auszutauschen ist meist nicht sinnvoll. Ein Controller braucht ohnehin gewisse Information über das Modell. Man kann natürlich Klassen haben, die nur von bestimmten Eigenschaften des Modells abhängen, wozu man dann nur bestimmte Schnittstellen festlegt und Modelle müssen lediglich solche Schnittstellen implementieren, damit der Controller damit klar kommt. Ein ORM kann durchaus auch ermöglichen, dass man Queries bezüglich bestimmter Schnittstellen formuliert.

                                    Aber das Erfinden eigener Query-Syntax in den Klassenmethoden ist mir auch nicht wirklich geheuer.

                                    Ja, ist erstmal etwas verwirrend, vor allem, weil man nicht immer so sicher ist, was da eigentlich genau passiert. Es ist aber ungemein nützlich ;-)

                                    Aber wäre das nicht ein Singel-Point-Of-Change in der abstrakten Modelklasse?

                                    Nein, der "Single-Point-Of-Change" sollte genau der Controller sein, indem die neue Funktionalität realisiert werden soll. Die Modelklasse wäre eine Klasse mit schlechtem Zusammenhalt, weil sie Funktionen mit unterschiedlichsten Aufgaben enthält. (Das wird auch oft als Kohäsion bezeichnet.) Man kann ja nicht einfach sagen, wenn ich alles in eine Klasse schmeiße, habe ich keinerlei Kopplung mehr zwischen Klassen und daher keinerlei Probleme mit Änderungen.

                                    Und ich fand noch [...]

                                    Dieser Zend Generator ORM scheint nur ein Codegenerator zu sein, der aus einem DB-Schema ein Klassenmodell macht oder umgekehrt. Das ist schon was, aber nicht besonders viel.

                                    http://code.google.com/p/zend-framework-orm/ wurde in dem Thread erwähnt und das scheint ein bisschen was zu können. Dass es da allerdings eine Objekt-Query-Sprache gibt, kann ich nirgens sehen. Scheint also eher einfach zu sein. Object-Relation-Mapping kann recht kompliziert werden und dann muss das Werkzeug schon einiges können.

                                    "Derzeit – und ich denke auch in Zukunft – gibt es keine generelle Komponente für das Model. [...]"

                                    Ja, da haben sie sicher recht, ein Modell kann man nicht vorgeben. Man kann allerdings die Serialisierung des Modells in Dateien oder Datenbanken unterstützen. Frameworks wie Zend machen das nach meinem Eindruck eher selten bis gar nicht. Manche Frameworks geben gewisse Regeln vor, wie Modellklassen zu definieren sind. RoR tut wohl so etwas und kümmert sich irgendwie wohl auch um OR-Mapping.
                                    Es spricht aber auch nichts dagegen, ein Framework wie Zend zu nehmen und für das Modell irgend etwas anderes einzusetzen, vorausgesetzt es gibt für PHP etwas, das wirklich gut genug ist. Wenn man zuviel um die Schwächen eines OR-Mappers herumprogrammieren muss, dann bringt das wahrscheinlich nichts mehr.

                                    * Zend_Db: auf Datenbanken zuzugreifen
                                    * Zend_Service_*: Entsprechenden Webservices aufrufen
                                    * Zend_Config: Konfigurationsdateien auszulesen"

                                    Nuja, bei all diesen Schnittstellen muss man Objekte von Hand abbilden. Das ist also kein Ersatz für einen ORM. Auch für Webservices gibt es ja solche Bibliotheken, die automatische Objekte in XML-Nachrichten konvertieren und zurück. Nun kommt es sehr auf den Webservice an, ob das wirklich sinnvoll ist. Wenn man Webservices aber als RPC-Ersatz verwendet, möchte man das eher nicht mehr von Hand tun.

                                    Grüße

                                    Daniel

                                    1. Hellihello Daniel,

                                      Was daran ist denn "prozedural"? Oder anders: welche Funktion wäre nicht prozedural? Das getBenutzerForGruppe()?
                                      Doch, sowas wie getBenutzerForGruppe() ganz besonders.
                                      Prozedural ist die Schnittstelle, weil sie einfach eine Menge von Algorithmen zur Datenabfrage zur Verfügung stellt. Es kommt ein Aufruf mit Parametern rein und eine Menge von Daten zurück. Eine Objektorientierte Schnittstelle würde die Daten in Objekte strukturieren (die Benutzer- und Gruppen-Objekte im Beispiel) und die Algorithmen auf diese Objekte aufteilen.

                                      Prozedural ist sie, weil sie selbst keine Eigenschaften hat? "Muss" ich jedes mal "new Benutzer($id)" machen oder innerhalb der Gruppe "new Gruppe ($groupName)" werden dann die Benutzer nach ihrer Gruppenzugehörigkeit geladen?

                                      Wenn ich mit XML-Daten hantiere, kann ich in PHP mir die in SimpleXMLObjects laden, die selbst noch Methoden mitbringen wie ->hasAttributes() ->attributes() oder ->getName(); Das Model sollte eigentlich nur dazu dienen, diese XML-Objekte einzusammeln.

                                      Das Modell auszutauschen ist meist nicht sinnvoll.

                                      Das Modell meint jetzt die Datenstruktur und ihre Zusammenhänge (Benutzer mit all seinen Eigenschaften, Gruppen mit ihren n->m Relationen) oder mein Modell die Art der Speicherung (XML, SQL)?

                                      Ein Controller braucht ohnehin gewisse Information über das Modell.

                                      Die Frage wäre, so wie ich das sehe, was genau "gewisse" heißt. Nicht wissen muss der Contoller wohl, wie die DB heißt und wie er sich damit verbindet. Vom "Model" würde er wohl eben eine ResourceHandle erwarten, und dann die entsprechenden Queries machen, zumindest eine Variante, die mir in einer ZF-Beispielanwendung unter kam.

                                      Man kann natürlich Klassen haben, die nur von bestimmten Eigenschaften des Modells abhängen, wozu man dann nur bestimmte Schnittstellen festlegt und Modelle müssen lediglich solche Schnittstellen implementieren, damit der Controller damit klar kommt.

                                      Ja sowas dachte ich mit o.g. Ansatz irgendwie näher zu kommen.

                                      Aber das Erfinden eigener Query-Syntax in den Klassenmethoden ist mir auch nicht wirklich geheuer.
                                      Ja, ist erstmal etwas verwirrend, vor allem, weil man nicht immer so sicher ist, was da eigentlich genau passiert. Es ist aber ungemein nützlich ;-)

                                      Mh, was ist daran "nützlich"? Und wieso ist man nicht so sicher, was da passiert? Model->getList("Benutzer) würde ein Array of SimpleXMLObjekts zurückgeben zB.. Model->get($Benutzer, $id) ein SXO des Benutzer mit der genannte ID. Ich könnte natürlich auch eine Benutzer-Klasse haben, die im Konstruktor die $id verwurstet (s.o.) und dann mit $Benuter->getName() dessen Namen ausgibt oder mit $Benutzer->update($params = array()) gewisse Eigenschaften setzt.

                                      Nein, der "Single-Point-Of-Change" sollte genau der Controller sein, indem die neue Funktionalität realisiert werden soll.

                                      Das heißt, die Modelklasse weiß nur, wie sie ein ResourceHandle herstellt? Also zB. dass die Datei für "Benutzer" "BenutzerData.xml" heißt und im Ornder "data" liegt? Das muss der Controller ja nicht wissen, oder?

                                      Die Modelklasse wäre eine Klasse mit schlechtem Zusammenhalt, weil sie Funktionen mit unterschiedlichsten Aufgaben enthält. (Das wird auch oft als Kohäsion bezeichnet.)

                                      Oder Single-Responsibility-Prinzip?

                                      Man kann ja nicht einfach sagen, wenn ich alles in eine Klasse schmeiße, habe ich keinerlei Kopplung mehr zwischen Klassen und daher keinerlei Probleme mit Änderungen.

                                      Nein, das war mir auch schon klar. Ich dachte halt, dass - vielleicht klappt das nur im kleinen Rahmen - der Conroller eben nur die Requests an die entsprechende Abfrage weitergibt. In meinem Fall wären das zB. Artists, Locations, Agencies, oder aber Schüler, Lehrer, Eltern. Die Profilanzeige würde sich aus den Eigenschaften ergeben und wäre ja eh Sache der View, Listenausgabe ungefiltert ist auch ident, und deshalb die Idee mit dem ->getList(). Der Controller könnte dann u.U. noch die Zugangsberechtigung checken (darf der und der das und das anzeigen, was bei Artists/Locations/Agencies weniger der Fall wäre, bei einem schulinternen(!) "...VZ" schon eher).

                                      Und ich fand noch [...]
                                      Dieser Zend Generator ORM scheint nur ein Codegenerator zu sein, der aus einem DB-Schema ein Klassenmodell macht oder umgekehrt. Das ist schon was, aber nicht besonders viel.

                                      Heißt, zum Lernen gut, aber nicht optimiert?

                                      » http://code.google.com/p/zend-framework-orm/ wurde in dem Thread erwähnt und das scheint ein bisschen was zu können. Dass es da allerdings eine Objekt-Query-Sprache gibt, kann ich nirgens sehen. Scheint also eher einfach zu sein. Object-Relation-Mapping kann recht kompliziert werden und dann muss das Werkzeug schon einiges können.

                                      Auha, ich dachte, irgendwann hört das mal auf mit dem immer nochwas dazulernen müssen (;-).

                                      Ja, da haben sie sicher recht, ein Modell kann man nicht vorgeben. Man kann allerdings die Serialisierung des Modells in Dateien oder Datenbanken unterstützen. Frameworks wie Zend machen das nach meinem Eindruck eher selten bis gar nicht. Manche Frameworks geben gewisse Regeln vor, wie Modellklassen zu definieren sind. RoR tut wohl so etwas und kümmert sich irgendwie wohl auch um OR-Mapping.

                                      Na RoR baut doch gleich die Datenbank im Hintergrund auf, wenn ich das recht kapiert habe.

                                      Es spricht aber auch nichts dagegen, ein Framework wie Zend zu nehmen und für das Modell irgend etwas anderes einzusetzen, vorausgesetzt es gibt für PHP etwas, das wirklich gut genug ist. Wenn man zuviel um die Schwächen eines OR-Mappers herumprogrammieren muss, dann bringt das wahrscheinlich nichts mehr.

                                      Na ich suche einen Weg, mich da (modular) von einfach nach kompliziert hochzuarbeiten.

                                      * Zend_Db: auf Datenbanken zuzugreifen
                                      * Zend_Service_*: Entsprechenden Webservices aufrufen
                                      * Zend_Config: Konfigurationsdateien auszulesen"
                                      Nuja, bei all diesen Schnittstellen muss man Objekte von Hand abbilden. Das ist also kein Ersatz für einen ORM. Auch für Webservices gibt es ja solche Bibliotheken, die automatische Objekte in XML-Nachrichten konvertieren und zurück. Nun kommt es sehr auf den Webservice an, ob das wirklich sinnvoll ist. Wenn man Webservices aber als RPC-Ersatz verwendet, möchte man das eher nicht mehr von Hand tun.

                                      http://de.wikipedia.org/wiki/XML-RPC noch so ein Fremdwort (;-).

                                      Dank und Gruß,

                                      frankx

                                      --
                                      tryin to multitain  - Globus = Planet != Welt
                                      1. Hellihello

                                        Immerhin mal was gefunden, was meiner ursprünglichen Überlegung nahe zu kommen scheint. Was ja nicht heißen muss, dass das so am sinnvollsten ist:
                                        http://cakebaker.42dh.com/2007/02/26/should-you-use-modelquery-in-the-controller/

                                        Dank und Gruß,

                                        frankx

                                        --
                                        tryin to multitain  - Globus = Planet != Welt
                                      2. Hallo frankx,

                                        Prozedural ist sie, weil sie selbst keine Eigenschaften hat?

                                        Ja so ungefährt. Sie repräsentiert ja auch kein konkretes Objekt wie "Benutzer" sondern nur etwas sehr technisches wie "Datenbankschnittstelle". Natürlich gibt es auch immer solche technischen Objekte, bei Dir gibt es aber nur solche technischen Objekte.

                                        "Muss" ich jedes mal "new Benutzer($id)" machen oder innerhalb der Gruppe "new Gruppe ($groupName)" werden dann die Benutzer nach ihrer Gruppenzugehörigkeit geladen?

                                        Naja bei ORM-Ansatz würdest Du die Objekte aufbauen, als ob es keine Datenbank gäbe:

                                        class Benutzer {
                                          String name;
                                          Gruppe gruppe;
                                          ...
                                        }

                                        class Gruppe {
                                          String name;
                                          Benutzer[] benutzer;
                                          ...
                                        }

                                        Dann würde man zusätzlich noch irgend welche Zusatzinformationen in den Code oder in eine zustäztliche Configurationsdatei schreiben, die z.B. festlegen, dass Gruppe.bennutzer das gegenstück zu Benutzer.gruppe ist.

                                        Wenn man dann orm.execute("from Bentzer where name='foo') ausführt, würde man ein Benutzer-Objekt erhalten. Je nach Konfiguration wurde da die Gruppe gleich mit geladen oder auch noch nicht.
                                        Der ORM manipuliert den Code der Klassen (jedenfalls macht das Hibernate für Java so), sodass, wenn man dann benutzer.getGruppe() oder gruppe.getGruppen() aufruft, das entsprechende SQL-Query ausgeführt wird, ohne dass man das selbst implementieren müsste. Man kann also weitgehend so programmieren, als gäbe es gar keine DB.
                                        Außerdem hat man eben diese Objekt-Query-Sprache, mit der man dennoch sehr effiziente Abfragen formulieren kann.

                                        Das Modell auszutauschen ist meist nicht sinnvoll.
                                        Das Modell meint jetzt die Datenstruktur und ihre Zusammenhänge (Benutzer mit all seinen Eigenschaften, Gruppen mit ihren n->m Relationen) oder mein Modell die Art der Speicherung (XML, SQL)?

                                        Modell meint ersteres. Das Model ist eine logische Darstellung der Dinge, mit denen das Programm eigentlich arbeitet. XML oder eine Datenbank haben damit erst einmal nichts zu tun.

                                        Nicht wissen muss der Contoller wohl, wie die DB heißt und wie er sich damit verbindet.

                                        Richtig, Modell meint hier aber wirklich die logische Struktur und das logische Verhalten, nicht die Form der Speicherung. Und diese Struktur muss ein Controller ja kennen.
                                        Meist muss er auch noch etwas über die Speicherung wissen, ob da irgendwie eine Datenbank, Dateien oder sonst irgend etwas dahinter steckt, macht oft einen unterschied. Eine Datenbank erlaubt z.B. Transaktionen, es gibt mehrere Benutzer die gleichzeitig Änderungen vornehmen könnnen, es können bestimmte Fehler auftreten. Solche Eigenschaften wirken sich doch meist auch auf den Controller aus. Welche Datenbank das ist, ob es XML-Datein oder ein anderes Format ist etc. spielt aber keine Rolle.

                                        Vom "Model" würde er wohl eben eine ResourceHandle erwarten, und dann die entsprechenden Queries machen, zumindest eine Variante, die mir in einer ZF-Beispielanwendung unter kam.

                                        Ja, so einen Einstiegspunkt benötigt man natürlich immer. Selbst wenn man sich nur von Objekt zu Objekt hangelt, muss man ja mal irgendwie das erste Objekt abrufen. Beim ORM-Ansatz gibt es da ja auch immer ein Objekt hinter dem sich letztenendes die DB-Verbindung bzw. die Transaktion verbergen.

                                        Mh, was ist daran "nützlich"?

                                        Nützlich ist, dass man effiziente Queries direkt auf Objekt-Ebene formulieren kann und nicht doch wieder irgendwo SQL schreiben und seine Objekte von Hand zusammensetzen muss. Abgesehen davon, dass SQL teilweise von der DB abhängen kann.

                                        Und wieso ist man nicht so sicher, was da passiert?

                                        Naja, man weiß nicht genau, was für SQL-Queries entstehen. Wenn man z.B. ein Query bezüglich einer Schnittstelle oder abstrakten Klasse macht, kann es sein, dass da mehrere Subqueries für die Tabellen konkreter Klassen abgesetzt werden. Das kommt auch darauf an, wie die Vererbungshierarchie auf Tabellen abgebildet wird. Das ist etwas, was man dem Query nicht gleich ansieht, was man aber natürlich schon ungefähr wissen sollte, aber am Anfang eben nicht unbedingt weiß.

                                        Model->getList("Benutzer) würde ein Array of SimpleXMLObjekts zurückgeben zB.. Model->get($Benutzer, $id) ein SXO des Benutzer mit der genannte ID. Ich könnte natürlich auch eine Benutzer-Klasse haben, die im Konstruktor die $id verwurstet (s.o.) und dann mit $Benuter->getName() dessen Namen ausgibt oder mit $Benutzer->update($params = array()) gewisse Eigenschaften setzt.

                                        Ja, letzteres wäre der "übliche" Weg. Wobei der Code zur Verarbeitung von XML eigentlich nicht in den Modell-Klassen stehen sollte, sondern in einer Bibliothek, sodass man so etwas machen kann:

                                        Model model = XMLSerialization->read(file);
                                        Benutzer name = model.getBenutzer("name");
                                        ...
                                        XMLSerialization->write(model, file);

                                        Das heißt, die Modelklasse weiß nur, wie sie ein ResourceHandle herstellt?

                                        Die Modelklasse_n_ wissen im Idealfall nur, wie das Modell logisch aufgebaut ist. Das Abbilden zwischen Modell und XML übernimmt eine Bibliothek.
                                        Da man bei Datenbanken dieses einmalige Auslesen und Speichern wegen der Datenmenge nicht machen kann, kann man da SQL in die Modellklassen packen, das ist aber wie gesagt auch nur eine Behelfslösung. Nach der "reinen Lehre" sollte ein Modell völlig unabhängig von der Speicherung sein.

                                        Also zB. dass die Datei für "Benutzer" "BenutzerData.xml" heißt und im Ornder "data" liegt? Das muss der Controller ja nicht wissen, oder?

                                        Richtig, diese Information liegt aber eigentlich ganz außerhalb der MVC-Klassen. Entweder hat man irgendwo noch einen Singleton rumfahren, der diesen Einstiegspunkt zur Verfügung stellt. Sowas in der Art:
                                        Model model = Storage.getInstance().read();
                                        Storage.getInstance().save(model);
                                        Oder man hat irgendwo einen Programmteil, der dafür zuständig ist, den Controller zu instanzieren, und man kann an dieser Stelle ein "ResourceHandle" erzeugen und als Parameter mit geben.
                                        Bei Desktopprogrammen muss der Controller auch oft wissen, wo die Daten gespeichert werden, da es sich bspw. um Dokumente handelt, die man mit dem Programm bearbeitet.

                                        Oder Single-Responsibility-Prinzip?

                                        So könnte man es wohl auch nennen. "Coupling and Cohesion" sind die klassischen, akademischen Bezeichnungen und wurden 1974 von irgend welchen IBM-lern eingeführt oder so. Hat also erstmal nichts mit objektorientierung zu tun ;-)

                                        Nein, das war mir auch schon klar. Ich dachte halt, dass - vielleicht klappt das nur im kleinen Rahmen - der Conroller eben nur die Requests an die entsprechende Abfrage weitergibt.

                                        Ja, ich denke das klappt ganz gut, so lang man das Objektmodell nicht wirklich braucht und man die Anwendung entweder nicht so funktional gliedern muss oder die Komponenten so unabhängig sind, dass es dazwischen ohnehin kaum Verknüpfungen gibt.

                                        In meinem Fall wären das zB. Artists, Locations, Agencies, oder aber Schüler, Lehrer, Eltern. Die Profilanzeige würde sich aus den Eigenschaften ergeben und wäre ja eh Sache der View, Listenausgabe ungefiltert ist auch ident, und deshalb die Idee mit dem ->getList(). Der Controller könnte dann u.U. noch die Zugangsberechtigung checken (darf der und der das und das anzeigen, was bei Artists/Locations/Agencies weniger der Fall wäre, bei einem schulinternen(!) "...VZ" schon eher).

                                        Ja, sowas könnte man evtl. auch in eine Schicht zwischen Controller und Model legen. Hier bekommt man aber auch schon wieder Probleme damit, dass man eine DB hat. Üblicherweise würde man Berechtigungen wohl im Model abhandeln, so nach der Art:
                                        benutzer.getDetails(benutzer2);
                                        Da würden dann die Rechte geprüft für benutzer2 und gegebenfalls ein Fehler zurückgegeben. Bei einer Datenbank will man aber evtl. auch das Berechtigungssystem der Datenbank nutzen, um Daten zu schützen. Wenn man dem Controller außerdem erlaubt, direkt Queries abzusetzen, muss man dafür auch noch die Rechte prüfen. Eine Lösung wäre vielleicht eine Zwischenschicht, sodass man die Rechtekonrolle zumindest an einer Stelle implementieren kann. Wenn man die verteilt, macht man leichter Fehler.

                                        Heißt, zum Lernen gut, aber nicht optimiert?

                                        Nein, das heißt, man bekommt schonmal den Modell-Code, die ganzen SQL-Queries und das Aufbauen des Modells muss man aber noch selber schreiben.

                                        Auha, ich dachte, irgendwann hört das mal auf mit dem immer nochwas dazulernen müssen (;-).

                                        Ich glaube nicht ;-)

                                        Na RoR baut doch gleich die Datenbank im Hintergrund auf, wenn ich das recht kapiert habe.

                                        Ja, aber ja Aufgrund des eigenen Klassenmodells, ob man nun das Klassenmodell aus dem Datenbankmodell oder umgekehrt erzeugt, ist ja erstmal egal. Klassenmodelle aus dem Datenbankmodell zu erzeugen, ist eigentlich nur dann interessant, wenn man das Datenbankmodell vorgeschrieben bekommt, weil man z.B. eine bestehende Datenbank verwenden muss.

                                        http://de.wikipedia.org/wiki/XML-RPC noch so ein Fremdwort (;-).

                                        Naja, klingt geheimnisvoller, als es ist. Letztenendes werden einfach nur Daten und Funktionsaufrufe einer Spracher über ein Netzwerk transportiert. Man kann damit recht schön verteilte Anwendungen schreiben, ohne selbst irgend welche Protokolle implementieren zu müssen.

                                        Grüße

                                        Daniel

                                        1. Hellihello Daniel,

                                          Naja bei ORM-Ansatz würdest Du die Objekte aufbauen, als ob es keine Datenbank gäbe:

                                          class Benutzer {
                                            String name;
                                            Gruppe gruppe;
                                            ...
                                          }

                                          class Gruppe {
                                            String name;
                                            Benutzer[] benutzer;
                                            ...
                                          }

                                          Wenn man dann orm.execute("from Bentzer where name='foo') ausführt, würde man ein Benutzer-Objekt erhalten. Je nach Konfiguration wurde da die Gruppe gleich mit geladen oder auch noch nicht.

                                          Mh, das entspricht doch aber meiner Interfacemethode My_Model->read(). Der würde ich mitgeben $category und $id, und sie würde mir ein Locationobjekt oder Artistobjekt zurückgeben.

                                          Der ORM manipuliert den Code der Klassen (jedenfalls macht das Hibernate für Java so), sodass, wenn man dann benutzer.getGruppe() oder gruppe.getGruppen() aufruft, das entsprechende SQL-Query ausgeführt wird, ohne dass man das selbst implementieren müsste.

                                          Gut, diese Funktionalität ließe sich ja in der Rückgabeklasse einbauen.

                                          Man kann also weitgehend so programmieren, als gäbe es gar keine DB.
                                          Außerdem hat man eben diese Objekt-Query-Sprache, mit der man dennoch sehr effiziente Abfragen formulieren kann.

                                          Genau. Ich (also Hybernate) könnte theoretisch im Hintergrund alle Objekt-Queries in XML-xpath-Abfragen umwandeln, das würde den Kontrollerteil überhaupt nicht beeinträchtigen. Nur so eine eigene Erfindung ist halt recht proprietär. Wobei man ja bei Hibernate abkupfern kann. PHPDoc entstand ja auch aus JavaDoc. Vermutlich sowieso nicht falsch, bei den Geschichten um OOP doch mal einen Blick auf/in Java zu werfen. Ich hatte mal ein Buch "Java ist eine Sprache" aber das kam dann leider abhanden dem Verleiher.

                                          Naja, man weiß nicht genau, was für SQL-Queries entstehen. Wenn man z.B. ein Query bezüglich einer Schnittstelle oder abstrakten Klasse macht, kann es sein, dass da mehrere Subqueries für die Tabellen konkreter Klassen abgesetzt werden. Das kommt auch darauf an, wie die Vererbungshierarchie auf Tabellen abgebildet wird. Das ist etwas, was man dem Query nicht gleich ansieht, was man aber natürlich schon ungefähr wissen sollte, aber am Anfang eben nicht unbedingt weiß.

                                          Genau, aber das ist doch die Implementation einer Schnittstelle, die dann bei Hibernate/Java an die Rückgabeobjekte gekoppelt ist. Was ja vermutlich schlau ist.

                                          Ja, letzteres wäre der "übliche" Weg. Wobei der Code zur Verarbeitung von XML eigentlich nicht in den Modell-Klassen stehen sollte, sondern in einer Bibliothek, sodass man so etwas machen kann:

                                          Model model = XMLSerialization->read(file);
                                          Benutzer name = model.getBenutzer("name");
                                          ...
                                          XMLSerialization->write(model, file);

                                          Der Kohäsion wegen? Ich hätte nun gedacht, der Kontroller spricht nur mit dem Model. Model::init() oder new Model("location"). Ob dann Model noch eine Helferklasse bräuchte, daran hatte ich nicht gedacht. Aber o.g. hast Du ja sicher nicht grundlos dahingeschrieben.

                                          Die Modelklasse_n_ wissen im Idealfall nur, wie das Modell logisch aufgebaut ist. Das Abbilden zwischen Modell und XML übernimmt eine Bibliothek.

                                          Mussichdrübernachdenken. Findet sich das so bei Hibernate auch. Anschauen immer besser als Nachdenken.

                                          Da man bei Datenbanken dieses einmalige Auslesen und Speichern wegen der Datenmenge nicht machen kann, kann man da SQL in die Modellklassen packen, das ist aber wie gesagt auch nur eine Behelfslösung. Nach der "reinen Lehre" sollte ein Modell völlig unabhängig von der Speicherung sein.

                                          Aber die orm-Klasse darf (;-).

                                          Also zB. dass die Datei für "Benutzer" "BenutzerData.xml" heißt und im Ornder "data" liegt? Das muss der Controller ja nicht wissen, oder?
                                          Richtig, diese Information liegt aber eigentlich ganz außerhalb der MVC-Klassen. Entweder hat man irgendwo noch einen Singleton rumfahren, der diesen Einstiegspunkt zur Verfügung stellt. Sowas in der Art:
                                          Model model = Storage.getInstance().read();

                                          Warum Singleton? Statische Klassen kennt Java auch? Storage.getInstance() soll ein Instanz der Storage-Klasse hergeben (Singleton, also "die eine" Instanz) und .read() gibt dann den Datenbankinhalt zurück? Model wäre demnach die komplette XML-Struktur/Baum?

                                          Storage.getInstance().save(model);

                                          Das Speichern übernimmt dann wieder die Storage-Klasse, indem ihr das zu speichernde Model übergeben wird.

                                          Bei Desktopprogrammen muss der Controller auch oft wissen, wo die Daten gespeichert werden, da es sich bspw. um Dokumente handelt, die man mit dem Programm bearbeitet.

                                          Aha, das kann er nicht vom Storage/Model erfragen Storage::whereAreMyFiles()?

                                          Oder Single-Responsibility-Prinzip?
                                          So könnte man es wohl auch nennen. "Coupling and Cohesion" sind die klassischen, akademischen Bezeichnungen und wurden 1974 von irgend welchen IBM-lern eingeführt oder so. Hat also erstmal nichts mit objektorientierung zu tun ;-)

                                          De Marco 1975 - WikipediaDiskussion

                                          http://de.wikipedia.org/wiki/GRASP,

                                          ... oder die Komponenten so unabhängig sind, dass es dazwischen ohnehin kaum Verknüpfungen gibt.

                                          Das spielt wohl eine entscheidende Rolle.

                                          Dank und Gruß,

                                          frankx

                                          --
                                          tryin to multitain  - Globus = Planet != Welt
                                          1. Hi,

                                            http://de.wikipedia.org/wiki/GRASP,

                                            IMHO: I miss grasp of the subject ;-)

                                            Vinzenz

                                            1. Hellihello

                                              http://de.wikipedia.org/wiki/GRASP,

                                              IMHO: I miss grasp of the subject ;-)

                                              What subjects grasp is missing. Du vermisst den Zugriff auf das Thema?

                                              Dank und Gruß,

                                              frankx

                                              --
                                              tryin to multitain  - Globus = Planet != Welt
                                          2. Hallo frankx,

                                            Mh, das entspricht doch aber meiner Interfacemethode My_Model->read(). Der würde ich mitgeben $category und $id, und sie würde mir ein Locationobjekt oder Artistobjekt zurückgeben.

                                            Ja, nur dass Du trennen kannst, zwischen der eigentlichen Abfrage und was dafür genau an SQL notwendig ist. Wenn Du nur SQL verwendest, musst Du entweder Deinem "My_Model" eine Methode für jedes Query hinzufügen, oder Du erlaubst dem Controller direkt Queries auszuführen, womit der Controller vom konkreten SQL-Dialekt (lässt sich evtl halbwegs in Grenzen halten, wenn man versucht nur Standard-SQL zu verwenden) abhängt und außerdem solche Dinge wie Queries über Schnittstellen nicht gehen. Dazu müsste der Controller ja wissen, welche Implementierungen es gibt und das hart in den Controller zu codieren ist natürlich ziemlich unflexibel.

                                            Gut, diese Funktionalität ließe sich ja in der Rückgabeklasse einbauen.

                                            Ja, wäre möglich.

                                            Genau. Ich (also Hybernate) könnte theoretisch im Hintergrund alle Objekt-Queries in XML-xpath-Abfragen umwandeln, das würde den Kontrollerteil überhaupt nicht beeinträchtigen.

                                            Ja, diesen Teil der ORM-Funktionalität kann man direkt in die Modell-Klassen hineinschreiben. Es ist eben eine recht aufwendige und auch langweilige Angelegenheit ;-)

                                            Model model = XMLSerialization->read(file);
                                            Benutzer name = model.getBenutzer("name");
                                            ...
                                            XMLSerialization->write(model, file);

                                            Der Kohäsion wegen?

                                            Nein, der Abstraktion von der Art der Serialisizerung bzw. von der Art des Modells.
                                            Die Modellklassen beschreiben die Struktur, Beziehungen etc.
                                            Die Serialisierungsschnittstelle (einen Standardbegriff gibt es dafür irgendwie nicht) implementiert das speichern und laden beliebiger Modelle.
                                            Wenn ich XPath- oder SQL-Queries direkt in meinem Modell habe, dann binde ich damit das Modell ja an die Datenbank, den XMLParser etc. Außerdem muss ich das für jedes Modell neu machen.
                                            Wenn ich eine Bibliothek habe, die Modelle auf Datenbanktabellen oder XML abbildet, kann ich diese für jedes Modell verwenden. Außerdem kann ich eine Instanz eines Modells in verschiedenen Resourcen abspeichern.
                                            Es geht also sowas:

                                            Transaction t = orm.begin();
                                            Benutzer[] benutzer = t.select("form Benutzer");
                                            benutzer.add(new Benutzer("foo"));
                                            t.commit();
                                            XMLSerializer.store("bar.xml", benutzer);

                                            Damit könnte ich dann erreichen, dass der Benutzer "foo" der Datenbank hinzugefügt wurde und außerdem die Liste in eine XML-Datei gespeichert.
                                            Jedenfalls vom Prinzip her, in der Praxis wird man wohl etwas aufpassen müssen, dass die XMLSerialisierung nicht irgend welche Daten abfragt, die man gar nicht serialisiert haben wollte oder sonstwas.

                                            Aber o.g. hast Du ja sicher nicht grundlos dahingeschrieben.

                                            Ja das Modell repräsentiert ja das, was in der Datenbank bzw in der Datei ist. Typischerweise muss man noch irgendwie die Resource repräsentieren und Operationen darauf. Bei Dateien ist das mit lesen und schreiben recht einfach, bei Datenbanken deutlich komplizierter.

                                            Mussichdrübernachdenken. Findet sich das so bei Hibernate auch. Anschauen immer besser als Nachdenken.

                                            Ja, Hibernate stellt wenig Bedingungen an das Modell, aber es wird beschrieben, wie man Modellklassen auf Datenbanken abbildet. Das könnte helfen.

                                            Aber die orm-Klasse darf (;-).

                                            Die tut das aber zur Laufzeit ;-)

                                            Warum Singleton? Statische Klassen kennt Java auch?

                                            Ja, statische Methoden gibt es natürlich auch. Würde auch gehen. Singletons erzeugen eben immer noch Objekte, die man auch so per Referenz weiter geben kann, dadurch muss man nicht gleich allen Code fest an die globale Information binden.

                                            Storage.getInstance() soll ein Instanz der Storage-Klasse hergeben (Singleton, also "die eine" Instanz) und .read() gibt dann den Datenbankinhalt zurück?

                                            Ja

                                            Model wäre demnach die komplette XML-Struktur/Baum?

                                            Model wäre ein logisches Objekt, die Klasse Storrage kapselt den Code, der irgend eine Konfigurationsdatei einliest, um festzustellen, wo die Daten liegen und dann diese irgendwie einliest. Das ist also eine Schnittstelle, die völlig davon abstrahiert, wo die Daten liegen und wie sie gespeichert sind.

                                            Aha, das kann er nicht vom Storage/Model erfragen Storage::whereAreMyFiles()?

                                            Naja, typischerweise muss man ja ein Dialog öffnen und den Benutzer fragen. Das öffnen irgend welcher Dialoge und das Aufrufen irgendwelcher Aktionen mit den Daten, die in diese Dialoge eingegeben wurden, ist ja typischerweise Aufgabe des Controllers. Streng genommen könnte man sagen, dass das Dateisystem mit zum Modell einer Desktopanwendung gehört.

                                            De Marco 1975

                                            Ach der, naja über das Thema kann man endlos philosophieren und es wurde auch getan und viele tun es immer noch ;-)

                                            http://de.wikipedia.org/wiki/GRASP

                                            Hm, das scheint eine Mischung aus bekannten Konzepten zu sein.
                                            Ein bisschen Coupling/Cohesion, Entwurfsmuster und MVC. Das entsprechende Buch ist erst von 2004. Vielleicht ist es eine schlüssige Gesamtdarstellung oder es ist nur ein neuer Aufguss alter Konzepte. In diesem Bereich gibt es sehr viel von Letzerem ;-)

                                            Grüße

                                            Daniel

                                            1. Hellihello Daniel,

                                              Mh, das entspricht doch aber meiner Interfacemethode My_Model->read(). Der würde ich mitgeben $category und $id, und sie würde mir ein Locationobjekt oder Artistobjekt zurückgeben.
                                              Ja, nur dass Du trennen kannst, zwischen der eigentlichen Abfrage und was dafür genau an SQL notwendig ist. Wenn Du nur SQL verwendest, musst Du entweder Deinem "My_Model" eine Methode für jedes Query hinzufügen, oder Du erlaubst dem Controller direkt Queries auszuführen, womit der Controller vom konkreten SQL-Dialekt (lässt sich evtl halbwegs in Grenzen halten, wenn man versucht nur Standard-SQL zu verwenden) abhängt und außerdem solche Dinge wie Queries über Schnittstellen nicht gehen. Dazu müsste der Controller ja wissen, welche Implementierungen es gibt und das hart in den Controller zu codieren ist natürlich ziemlich unflexibel.

                                              Genau das war ja der Ansatz. Keine direkten speichermethodenabhängigen Queries im Controller. Jetzt verstehe ich Dich so, dass Du sagst: im Model auch nicht, denn das Model ist das logische Abbild der Datenstruktur, auch unabhängig von der Speichermethode. Klingt plausibel. Dann kommt dann also noch eine Speicherklasse dazu, wie ja auch u. und o.g..

                                              Genau. Ich (also Hybernate) könnte theoretisch im Hintergrund alle Objekt-Queries in XML-xpath-Abfragen umwandeln, das würde den Kontrollerteil überhaupt nicht beeinträchtigen.
                                              Ja, diesen Teil der ORM-Funktionalität kann man direkt in die Modell-Klassen hineinschreiben. Es ist eben eine recht aufwendige und auch langweilige Angelegenheit ;-)

                                              Jau, das war das, was mir nicht "geheuer" war. Aber bei Hibernate ist ja ein guter Hinweis, was zB. etwaige Methoden, Parameter und Namenskonstrukte angeht.

                                              Model model = XMLSerialization->read(file);
                                              Benutzer name = model.getBenutzer("name");
                                              ...
                                              XMLSerialization->write(model, file);

                                              Der Kohäsion wegen?
                                              Nein, der Abstraktion von der Art der Serialisizerung bzw. von der Art des Modells.

                                              Aber doch auch der Kohäsion wegen, oder? Das Model soll einen Benutzer rausrücken können, aber es muss nicht wissen, wie er gespeichert ist. Sind das nicht zwei Aufgabenbereiche?

                                              Die Modellklassen beschreiben die Struktur, Beziehungen etc.
                                              Die Serialisierungsschnittstelle (einen Standardbegriff gibt es dafür irgendwie nicht)

                                              komisch...

                                              implementiert das speichern und laden beliebiger Modelle.

                                              Genau. Der sag ich, wie das Model heißt, und dann macht die Schnittstelle los und bringts mir von irgendwo. Mir doch egal von wo.

                                              Wenn ich XPath- oder SQL-Queries direkt in meinem Modell habe, dann binde ich damit das Modell ja an die Datenbank, den XMLParser etc. Außerdem muss ich das für jedes Modell neu machen.

                                              Jau, der Groschen scheint jetzt gefallen zu sein.

                                              Wenn ich eine Bibliothek habe, die Modelle auf Datenbanktabellen oder XML abbildet, kann ich diese für jedes Modell verwenden. Außerdem kann ich eine Instanz eines Modells in verschiedenen Resourcen abspeichern.

                                              dit.

                                              Warum Singleton? Statische Klassen kennt Java auch?
                                              Ja, statische Methoden gibt es natürlich auch. Würde auch gehen. Singletons erzeugen eben immer noch Objekte, die man auch so per Referenz weiter geben kann, dadurch muss man nicht gleich allen Code fest an die globale Information binden.

                                              Ich dachte Singleton erlaugt nur _eine_ Instanz. Deshalb brauch ich das Objekt nicht weiterzugeben, weil mir ja MySingelton::getInstance() immer den aktuellen Zustand des Objektes liefert. So scheint mir das zumindest beim FrontController im ZF zu sein. Objekte werden ja _immer_ per Referenz übergeben ab PHP 5.

                                              Streng genommen könnte man sagen, dass das Dateisystem mit zum Modell einer Desktopanwendung gehört.

                                              Ah, zum Verständnis ist "streng genommen" immer gut (;-).

                                              De Marco 1975
                                              Ach der, naja über das Thema kann man endlos philosophieren und es wurde auch getan und viele tun es immer noch ;-)

                                              Also doch Philosophie. Gut. Einverstanden.

                                              http://de.wikipedia.org/wiki/GRASP
                                              Hm, das scheint eine Mischung aus bekannten Konzepten zu sein.
                                              Ein bisschen Coupling/Cohesion, Entwurfsmuster und MVC. Das entsprechende Buch ist erst von 2004. Vielleicht ist es eine schlüssige Gesamtdarstellung oder es ist nur ein neuer Aufguss alter Konzepte. In diesem Bereich gibt es sehr viel von Letzerem ;-)

                                              Ein Philosophieprofessor höre ich noch dunkel in Erinnerung sagen, Habermaß oder sonstwer hätte behauptet, Philosophie sei nix weiter als Aristoteles und Plato zu kommentieren. "Weisheitsliebe" ist wohl die direkte Übersetzung aus dem Griechischen.

                                              Dank und Gruß,

                                              frankx

                                              --
                                              tryin to multitain  - Globus = Planet != Welt
                                              1. Hallo frankx,

                                                Genau das war ja der Ansatz. Keine direkten speichermethodenabhängigen Queries im Controller. Jetzt verstehe ich Dich so, dass Du sagst: im Model auch nicht, denn das Model ist das logische Abbild der Datenstruktur, auch unabhängig von der Speichermethode. Klingt plausibel. Dann kommt dann also noch eine Speicherklasse dazu, wie ja auch u. und o.g..

                                                Richtig.

                                                Jau, das war das, was mir nicht "geheuer" war. Aber bei Hibernate ist ja ein guter Hinweis, was zB. etwaige Methoden, Parameter und Namenskonstrukte angeht.

                                                Ja.

                                                Aber doch auch der Kohäsion wegen, oder? Das Model soll einen Benutzer rausrücken können, aber es muss nicht wissen, wie er gespeichert ist. Sind das nicht zwei Aufgabenbereiche?

                                                Doch, von daher auch der Kohäsion wegen, aber man muss erstmal feststellen, dass es zwei Bereiche sind ;-)

                                                komisch...

                                                Liegt vielleicht daran, dass sich MVC eben nicht um die Speicherung kümmert, sondern um die Bedienoberfläche. Speicherung ist sozusagen auf der anderen Seite des Modells.

                                                Ich dachte Singleton erlaugt nur _eine_ Instanz.

                                                Naja, ein Beispiel: Irgendwelche Konfigurationsdaten für Dein Programm sind per Singleton zugreifbar:
                                                Config config = Config.getInstance();

                                                Nun könntest Du irgendwo eine Methode haben, die die Konfiguration benötigt:
                                                void tuWas(Config config)
                                                Statt die Konfiguration mitzugeben, könnte sich die Methode die Konfiguration auch selbst holen, so hast Du aber leicht die Möglichkeit, den Singleton später durch etwas anderes zu ersetzen und die Methode mit verschiedenen Konfigurationen aufzurufen.
                                                Im Prinzip das gleiche, wie bei einer globalen Variable. Du kannst den Wert immernoch an einigen Stellen als Parameter übergeben, statt direkt auf die Variable zuzugreifen. Damit hast Du die Möglichkeit, die globale Variable wieder abzuschaffen.
                                                Außerdem könnte ein Singleton natürlich noch irgend welche Schnittstellen implementieren. Das sind zugegebenermaßen alles eher technische Gründe. Singleton ist aber auch nicht viel mehr als ein Hilfskonstrukt, in denen man direkt einzelne Objekte angeben kann, benötigt man das ja ohnehin nicht.

                                                Grüße

                                                Daniel

                                    2. Hellihello Daniel,

                                      http://code.google.com/p/zend-framework-orm/ wurde in dem Thread erwähnt und das scheint ein bisschen was zu können. Dass es da allerdings eine Objekt-Query-Sprache gibt, kann ich nirgens sehen. Scheint also eher einfach zu sein. Object-Relation-Mapping kann recht kompliziert werden und dann muss das Werkzeug schon einiges können.

                                      Im Folder .../models findet sich u.a.
                                      "class Project extends Zsamer_Db_Table_Orm"

                                      und entsprechend dann:

                                      "Zsamer_Db_Table_Orm extends Zend_Db_Table_Abstract"

                                      Zend_Db_Table_Abstract kommt dann mit Methoden daher wie: delete(), fetchAll() und find().

                                      Zend_Db_Table_Select ist dann eine eigene Klasse, mh.

                                      Dank und Gruß,

                                      frankx

                                      --
                                      tryin to multitain  - Globus = Planet != Welt
  2. Hi,

    der größere Vorteil der OOP liegt m.E. nicht im objektorientierrten Programmcode, sondern im objektorientierten Design, zu dem dich eine objektorientierte Sprache eher zwingt. Es liegt der menschlichen Denke näher.

    Das führt dazu, dass die Sofware-(Architektur) in sich schlüssiger designed wird, leichter nachvollziehbar ist, besser gekapselt und dadurch fehlerresistenter, leichter (auch automatisiert) testbar, einfacher erweiterbar,

    Dies ist umso wichtiger, je größer die Projekte werden und um so mehr verschiedene Menschen (auch nacheinander) daran beteiligt sind. Objektorientiert zu programmieren heisst nicht, Funktionen gegen Objekte auszutauschen, sondern es beginnt viel eher.

    Es gibt Entwickler, die kriegen auch mit einer OOP-Sprache kaum ein objektorientiertes Modell hin, ebenso kann man mit einer proceduralen Sprache durchaus objektorientiert entwickeln.

    Ciao, Stefanie

    1. Hello,

      Es gibt Entwickler, die kriegen auch mit einer OOP-Sprache kaum ein objektorientiertes Modell hin, ebenso kann man mit einer proceduralen Sprache durchaus objektorientiert entwickeln.

      *wow*

      Für diese Aussage (Sinngemäß: Ich habe OOP schon mit Assembler betrieben) bin ich hier schon geächtet worden. Ich stimme Dir aber vollkommen zu, nicht dass das falsch verstanden wird.

      Und meine Meinung ist, dass zu einer gesunden OOP-Entwicklung auch immer ein leistungsstarkes Entwicklungssystem gehört. Ich hatte irgendwann zwischendurch aufgegeben, weil es für die PC-Welt nur noch teure Systeme mit schlechter Basis (C/C++ portiert nach DOSen) von MS gab (Borland und Andere waren quasi ausgekickt, UNIX(tm) konnte ich mir nicht leisten, Unixoide hatte ich noch nicht genug im Blick).

      Seit es Eclipse gibt, bin ich immer interessierter daran, wieder mitzuspielen...

      Reflection/Reflexion gibt es auch noch nicht sooo lange, dass man das als Oldie schon eingeatmet haben könnte, auch wenn man seinen eigenen frühen "OOP"-Elaboraten sowas ähnliches schon eingehaucht hat. Aber auf einem 8086 war da nicht wirklich viel Platz für Selbsterkenntnis.

      Ich sammele übrigens immer noch Threads usw. wie diesen hier.
      Meine Meinung, dass OOP oft nur um ihrer selbst Willen benutzt wird, festigt sich immer weiter...

      Liebe Grüße aus Syburg bei Dortmund

      Tom vom Berg

      --
      Nur selber lernen macht schlau
      http://bergpost.annerschbarrich.de
      1. Hellihello

        Seit es Eclipse gibt, bin ich immer interessierter daran, wieder mitzuspielen...

        für PHP? http://www.phpeclipse.de/

        Dank und Gruß,

        frankx

        --
        tryin to multitain  - Globus = Planet != Welt
        1. Hello Robert,

          Seit es Eclipse gibt, bin ich immer interessierter daran, wieder mitzuspielen...

          für PHP? http://www.phpeclipse.de/

          Damit werde ich mich auch noch auseinandersetzen. Ich hoffe, die Zeit zwischen den Jahren dafür nutzen zu können. Zumindest habe ich das so auf meinem Plan stehen :-)

          Erstmal ist noch die Analyse dran, was denn der generelle Unterschied bei WinDOSen und Unixoiden in Bezug auf die OOP mit C++ ist. Das Shared-Library-Konzept von Linux scheint mir doch viel simpler zu funktionieren, als die DLLs bei WinDOSen.

          Liebe Grüße aus Syburg bei Dortmund

          Tom vom Berg

          --
          Nur selber lernen macht schlau
          http://bergpost.annerschbarrich.de
    2. Hallo Stefanie,

      der größere Vorteil der OOP liegt m.E. nicht im objektorientierrten Programmcode, sondern im objektorientierten Design, zu dem dich eine objektorientierte Sprache eher zwingt. Es liegt der menschlichen Denke näher.

      In gewisser Weise ja, da man sein Programm strukturieren kann, wie man üblicherweise auch die Realität strukturiert. Allerdings muss man sich dafür auch wirklich die Struktur, die man Abbilden will, bewusst machen. Außerdem braucht man noch ein gewisses Abstraktionsvermögen, da man für ein objektorientiertes Modell eben doch in strengeren Formalismen (Objekten und Beziehungen) denken muss, als das die normale Wahrnehmung der Realität ist. Zudem schrenken objektorientierte Sprachen die Abstraktionsmöglichkeiten auch ein, sodass sich nicht jede Vorstellung auch sinnvoll als Objektmodell umsetzen lässt.
      Daher mag OOP zwar in gewisser weise natürlich sein, ist aber für viele doch recht schwer erlernbar, jedenfalls ist das mein Eindruck.

      Das führt dazu, dass die Sofware-(Architektur) in sich schlüssiger designed wird, leichter nachvollziehbar ist, besser gekapselt und dadurch fehlerresistenter, leichter (auch automatisiert) testbar, einfacher erweiterbar,

      Auch hier muss man aufpassen. Mit OOP kann man erstmal, vorausgesetzt man investiert auch die notwendige Überlegung, erreichen, dass ein Programm einfacher erweiterbar ist und dass Fehler besser behoben werden können. Das erreicht man durch die typische, stärkere Modularisierung. Wenn das gut gemacht ist, kann man Anpassungen durch Änderung einzelner Module vornehmen.
      Testbarkeit ist nicht unbedingt so einfach zu erreichen. Zwar ist JUnit-Testing einzelner Klassen sehr verbreitet, aber objektorientierte Programme realisieren oft komplexeres Verhalten durch zusammenspiel vieler Objekte. Das zu testen kann sehr schwierig sein, jedenfalls viel schwieriger, als eine Prozedur mit einem Satz von Parametern aufzurufen. Auch das Debugging kann recht kompliziert sein, wenn man es eben mit nicht-lokalen Effekten zu tun hat. Also Fehlern, die erst durch das Zusammenspiel vieler Objekte entstehen.

      Ich will hier wirklich nicht die objektorientierte Programmierung kritisieren, aber man sollte schon erwähnen, dass man all diese wünschenswerten Eigenschaften nur erreicht, wenn man sich darum bemüht, sie zu erreichen und dass es meist viel mehr benötigt, als einfach nur mal verstanden zu haben, was ein Objekt ist.

      Grüße

      Daniel

      1. Hellihello

        Ich will hier wirklich nicht die objektorientierte Programmierung kritisieren, aber man sollte schon erwähnen, dass man all diese wünschenswerten Eigenschaften nur erreicht, wenn man sich darum bemüht, sie zu erreichen und dass es meist viel mehr benötigt, als einfach nur mal verstanden zu haben, was ein Objekt ist.

        Umgekehrt würde ich sagen: wenn man die Grundzüge des zend-framework nachvollziehen kann, dann muss mans eigentlich kapiert haben. Und das finde ich persönlich nicht wirklich einfach.

        Dank und Gruß,

        frankx

        --
        tryin to multitain  - Globus = Planet != Welt