Ankündigung

Einklappen
Keine Ankündigung bisher.

(java vs php) + frameworks

Einklappen

Neue Werbung 2019

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

  • #46
    Hey

    JaMa

    Es geht darum, dass ich mein Programm so programmiere:
    Ich habe eine Prozedur: In diese gebe ich parameter hinein, also von aussen. Und dann macht die irgendwas, holt sich selbst weitere Daten, hat Seiteneffekte etc. pp

    Diesem Muster folgen Service-Klassen auch. Ein Daten and Verhalten-Gebundensein gibt es hier nicht mehr.

    Und ich dachte gerade das macht die objektorientierung aus.
    Ich selber sehe das aber problematisch, Daten und Verhalten gehören meiner Meinung nach nicht wirklich zusammen...... Das sehen all diejenigen die ServiceKlassen programmieren offensichtlich genauso!
    Dann aber noch zu behaupten das wäre OO, finde ich nicht so toll. Das ist kein OO mehr!^^

    Wie unterscheideset du oo-Programme von pp-Programmen?
    Was muss jeweils anders sein, um in die entsprechende Kategorie zu fallen?

    lg knotenpunkt

    Kommentar


    • #47
      Was meinst du mit "holt sich selbst weitere Daten"? Prinzipiell sollte man mit Dependency Injection arbeiten. Also alle Parameter, die eine Klasse braucht, sollten im Konstruktor übergeben werden. Da wird sich nichts selbst geholt.

      Aber an irgendeiner Stelle muss eine Klasse Daten holen. z.B. eine Datenbankklasse, die Daten aus der Datenbank lädt. Diese muss die Daten schließlich nachladen. Anders kann sie gar nicht funktionieren. Wenn für dich sowas schon das Ausschlusskriterium für "OOP" ist, dann ist "OOP" komplett unbrauchbar und nur ein theoretisches Hirngespinst.

      Kommentar


      • #48
        Hm ich habe ein paar Schwierigkeiten deinen Texten zu folgen.

        Ich habe eine Prozedur: [...] hat Seiteneffekte etc. pp
        Diesem Muster folgen Service-Klassen auch [...]
        Und ich dachte gerade das macht die objektorientierung aus.
        Ich selber sehe das aber problematisch, Daten und Verhalten gehören meiner Meinung nach nicht wirklich zusammen
        Das sehen all diejenigen die ServiceKlassen programmieren offensichtlich genauso!
        Für mich widerspricht da ein Satz dem anderen.

        Gehen wir mal davon aus, dass du den ersten so meinst wie er da steht.

        Dann würden Service-Klassen also auch: irgendwas machen, weitere Daten holen, Seiteneffekte haben
        In wie fern sollte das die Objektorientierung ausmachen? Das ist doch nichtmal ansatzweise worum es dabei gehen sollte

        Und als nächstes siehst du "das" problematisch... aber warum machst du es dann so? Und wenn die Service-Klassen Programmierer das auch so sehen... warum machen die das dann auch so? Und woher willst du überhaupt wissen, dass die es problematisch sehen wenn sie es doch so machen.

        An welcher Stelle wurden denn jetzt eigentlich Daten und Verhalten zusammen geworfen? Nach dem was ich bisher so gelesen habe gibt es doch viele die eine Trennung von Objekten in die Kategorien "Datenstruktur" und "Verhalten" propagieren.
        Die Service-Klassen würden, zumindest in meinem Code, das "Verhalten" darstellen. Dafür bekommen sie die entsprechende "Datenstrukturen" die sie verarbeiten können und andere "Verhalten"-Klassen die evtl. denZugriff auf weitere Daten ermöglichen. Aber das ist ja keine Willkür, dass da irgendwelche Daten geholt werden sondern definiertes Verhalten und Umgang mit Komponenten.
        [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
        [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

        Kommentar


        • #49
          Geht es jetzt im speziellen um Services bzw. SOP? (Muss zugeben ich habe auch nicht alles gelesen)

          Daten und Verhalten gehören meiner Meinung nach nicht wirklich zusammen
          Das macht u.a. prozedurale Programmierung ausmacht. Eine Prozedur definiert einen Algorithmus, der etwas macht (Verhalten) und keine eigenen Daten besitzt (du musst alle Daten der Prozedur übergeben). Dabei ist durch die Implementation der Prozedur festgelegt, welche Daten verarbeitet werden können (andernfalls verletzt du das SRP Prinzip).
          Services definieren aber z.B. Schnittstellen für die Daten mit denen der Service arbeiten kann. Den Service konfigurierst kannst du in der Regel auch konfigurieren (z.B. DI). Dann hat der Service entsprechend seiner Schnittstellendefinitionen auch ein Verhalten um die Daten zu nutzen.

          Falls du etwas darüber lesen möchtest, hier ein Paper über OOP und SOP (speziell Kapitel IV): https://pdfs.semanticscholar.org/f82...f849170135.pdf

          "Software is like Sex, it's best if it's free." - Linus Torvalds

          Kommentar


          • #50
            Hey,

            Zitat von hellbringer Beitrag anzeigen
            Was meinst du mit "holt sich selbst weitere Daten"? Prinzipiell sollte man mit Dependency Injection arbeiten. Also alle Parameter, die eine Klasse braucht, sollten im Konstruktor übergeben werden. Da wird sich nichts selbst geholt.

            Aber an irgendeiner Stelle muss eine Klasse Daten holen. z.B. eine Datenbankklasse, die Daten aus der Datenbank lädt. Diese muss die Daten schließlich nachladen. Anders kann sie gar nicht funktionieren. Wenn für dich sowas schon das Ausschlusskriterium für "OOP" ist, dann ist "OOP" komplett unbrauchbar und nur ein theoretisches Hirngespinst.
            Die Parameter die du via DI bekommst, sind weitere Service-Klassen/Konfigurationsparameter und keine Domainenobjekte.
            Die Daten, die von der Datenbank geholt werden sind deine "BuisnessObjekte/Daten"
            Das ist meiner Meinung nach dann aber ein prozeduraler Programmentwurf bzw. pseudo-oo-Programmentwurf.

            VPh


            Dann würden Service-Klassen also auch: irgendwas machen, weitere Daten holen, Seiteneffekte haben
            In wie fern sollte das die Objektorientierung ausmachen? Das ist doch nichtmal ansatzweise worum es dabei gehen sollte
            Sie holen sich doch bspw. die Daten aus der Datenbank^^, oder arbeiten bspw. auf einem auf dem Heap-liegenden Objektgraphen.
            Und richtig, das macht keine objektorientierung aus, sondern eben eine prozedurale Programmierung.

            Und als nächstes siehst du "das" problematisch... aber warum machst du es dann so? Und wenn die Service-Klassen Programmierer das auch so sehen... warum machen die das dann auch so? Und woher willst du überhaupt wissen, dass die es problematisch sehen wenn sie es doch so machen.
            Ich sehe die OO im reinen als problematisch an, weil ich der Meinung bin dass Daten und Verhalten schlecht kombinierbar sind.

            Deshalb wird versucht das Verhalten von den Daten wieder zu trennen: Services + externe Daten (und das machen ja viele so)

            Die Service-Klassen würden, zumindest in meinem Code, das "Verhalten" darstellen. Dafür bekommen sie die entsprechende "Datenstrukturen" die sie verarbeiten können und andere "Verhalten"-Klassen die evtl. denZugriff auf weitere Daten ermöglichen. Aber das ist ja keine Willkür, dass da irgendwelche Daten geholt werden sondern definiertes Verhalten und Umgang mit Komponenten.
            ja, das ist kein OO mehr, das ist pseudo-oo bzw. prozedural.
            Finde ich gut........... ist aber wie gesagt keine OO


            Warum passen eigentlich Daten und Verhalten nicht zusammen
            Ein BSP:

            class A
            {
            T memVariable1;
            T memVariable2;
            T memVariable3
            }

            class B
            {
            T memVariable4;
            T memVariable5;
            T memVariable6
            }


            procedur1()
            {
            //arbeitet auf memVariable1+memvarable2+memVariable4
            }

            procedur2()
            {
            //arbeitet auf allen memVariablen
            }

            procedur1()
            {
            //arbeitet auf memVariable1+memVariable3
            }

            Das ist jetzt sehr vereinfacht...... aber dann habe ich noch proceduren, die arbeiten auf memVariablen1-100 von x-verschiedenen Datenstrukturen


            JaMa


            Services definieren aber z.B. Schnittstellen für die Daten mit denen der Service arbeiten kann. Den Service konfigurierst kannst du in der Regel auch konfigurieren (z.B. DI). Dann hat der Service entsprechend seiner Schnittstellendefinitionen auch ein Verhalten um die Daten zu nutzen.
            Ja ein kleiner Mehrwert für die Services besteht darin, dass ich sie konfigurieren kann.
            Was du aber jetzt genau mit der Schnittstellendefinition meinst bzw. worin hier der Vorteil liegen mag, da konnte ich dir noch nicht ganz folgen.


            Das PDF scheint ganz interessant zu sein, das werde ich mir später mal näher ansehen.


            lg knotenpunkt

            Kommentar


            • #51
              Sie holen sich doch bspw. die Daten aus der Datenbank^^, oder arbeiten bspw. auf einem auf dem Heap-liegenden Objektgraphen.
              Services holen sich keine Daten aus der Datenbank, zumindest nicht die die sich um die Abarbeitung der Logik kümmern. Dafür gibt es einen anderen Layer dessen Objekte aber evtl. dem Service als 'Ansprechpartner' zu Verfügung steht.

              Und richtig, das macht keine objektorientierung aus, sondern eben eine prozedurale Programmierung.
              Versuchst du da gerade die Argumentationskette zu verdrehen?
              Mein Einwand war an der Stelle genau darauf gerichtet, dass das was du geschrieben hattest eben nicht stimmt. Dass die Programmierung mit Service-Klassen eben NICHT dem entspricht was du vorher für deine prozedurale Programmierung beschrieben hast.

              a, das ist kein OO mehr, das ist pseudo-oo bzw. prozedural.
              Also dann interessiert mich wirklich mal deine Definition von OO. Und ob die auch mit irgend jemandes Definition übereinstimmt.


              Ich weiß nicht wirklich was du mit deinem Beispiel darstellen möchtest. 'Warum passen eigentlich Daten und Verhalten nicht zusammen' - aber in wie fern wird das von dem Beispiel demonstriert?
              Und in wie fern hat das etwas mit OO zu tun, ich denke SO stellt sich hier niemand seinen Code vor. Gehst du vielleicht einfach von einem anderen (scheinbar bedeutend niedrigeren) Niveau der User hier aus als ich es tue?
              [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
              [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

              Kommentar


              • #52
                knotenpunkt
                Mir fehlt immer noch ein ganz konkretes Code-Beispiel um deinen Kritikpunkt wirklich erfassen zu können und zu verstehen wie *du* "objektorientiert" und "prozedural" deutest. Nehmen wir doch mal dein EmailService-Beispiel. Wie schaut das jeweilis in "Pseudo-OO" und "OO" aus? Und weiter interessiert mich wie du durch korrektes OO das Thema DI vollständig aus der Gleichung streichst und was mit der Konfiguration passiert.

                Bitte, Code. Der sagt manchmal mehr als tausend Worte
                [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                Kommentar


                • #53
                  Zitat von knotenpunkt Beitrag anzeigen
                  Diesem Muster folgen Service-Klassen auch. Ein Daten and Verhalten-Gebundensein gibt es hier nicht mehr.
                  Falsch.
                  Ich instanziiere eine Service-Klasse ja vorher. Und bei dieser Instanziirung gebe ich der Service-Klasse ihre Konfiguration mit. Das muss nicht immer so sein, aber bei meinen Applikationen ist das praktisch immer so. Beispielsweise ist der aktuell angemeldete Session-User immer so ein Objekt, dass über Constructor-Injection vielen Service-Klassen übergeben wird.
                  Heißt aber auch, dass ich eine Service-Klasse woanders AdHoc mit einem anderen User initialisieren kann und kann so die gleichen Service-Funktionen nutzen - nur in einem anderen Kontext. Das impliziert eine völlig andere Arbeitsweise, die so gar nicht mit PP möglich ist.

                  Kommentar


                  • #54
                    knotenpunkt Ich komme (glaube ich) Deinem Problem mit OO langsam näher. Es ist leider ungünstig, dass Du Begriffe benutzt, die außer Dir niemand richtig zuordnen kann (Bsp. "Pseudo-OO").

                    Liege ich richtig, wenn ich sage, dass es Dich einfach stört, dass bei OO, wie es benutzt wird, nicht nur die Daten, sondern auch die Logik in Objekte gekapselt ist?

                    Kommentar


                    • #55
                      Hey

                      Zitat von rkr Beitrag anzeigen

                      Falsch.
                      Ich instanziiere eine Service-Klasse ja vorher. Und bei dieser Instanziirung gebe ich der Service-Klasse ihre Konfiguration mit. Das muss nicht immer so sein, aber bei meinen Applikationen ist das praktisch immer so. Beispielsweise ist der aktuell angemeldete Session-User immer so ein Objekt, dass über Constructor-Injection vielen Service-Klassen übergeben wird.
                      Heißt aber auch, dass ich eine Service-Klasse woanders AdHoc mit einem anderen User initialisieren kann und kann so die gleichen Service-Funktionen nutzen - nur in einem anderen Kontext. Das impliziert eine völlig andere Arbeitsweise, die so gar nicht mit PP möglich ist.
                      Das mag sein, dass du das machst, also die Servive-Klassen konfigurieren

                      Deine Service-Klasse wird später aber andere Objekte/Structs sehr serviceorientiert sprich prozedural bearbeiten. Der Grossteil der Logik liegt also in der Service-Klasse und nicht nicht bei den domainen-spezifischen Objekten.
                      Und das bezeichne ich als psuedo-oo.
                      Da das Konfigurieren der Service Klasse den Eindruck macht, das ganze wäre OO.


                      Liege ich richtig, wenn ich sage, dass es Dich einfach stört, dass bei OO, wie es benutzt wird, nicht nur die Daten, sondern auch die Logik in Objekte gekapselt ist?
                      xm22 ja ich störe mich daran, da das nicht sinnvoll machbar ist. Andere Leute stören sich auch daran, ein Indiz dafür ist die ausgeprägte Service-Klassen-Orientierte-Pseudo-OO-Programmierung.

                      Damit möchte ich diese Programmierweise zwar nicht direkt angreifen, eigentlich sogar unterstüzzen. Viel stärker sieht man daran, dass OO in vielen Teilen als gescheitert angesehen werden kann.


                      lg knotenpunkt

                      Kommentar


                      • #56
                        Zitat von knotenpunkt Beitrag anzeigen
                        Das mag sein, dass du das machst, also die Servive-Klassen konfigurieren
                        Naja, anders würde es ja kaum einen Sinn machen, welche zu haben. Andernfalls könnte ich mit "statischen" Klassen arbeiten und hätte im Grunde genommen PP mit Pseudonamespaces.

                        Zitat von knotenpunkt Beitrag anzeigen
                        Deine Service-Klasse wird später aber andere Objekte/Structs sehr serviceorientiert sprich prozedural bearbeiten.
                        Ja, und? Aber die Service-Klasse an sich ist von der Architektur-Perspektive her nicht-statisch. Wie schon früher gesagt: Alles, was ein einmal instanziiertes OO-Konstrukt nachher macht, ist im Grunde genommen Prozedural - mit Ausnahmen.

                        Und noch mal: Trotzdem kann ich mit prozeduraler Programmierung nachher ganz viele Sachen nicht machen, die ich mit OOP kann.

                        Zitat von knotenpunkt Beitrag anzeigen
                        Der Grossteil der Logik liegt also in der Service-Klasse und nicht nicht bei den domainen-spezifischen Objekten.
                        Irgendwie werde ich mit deiner Definition einer Service-Klasse nicht warm. Warum beispielsweise ist eine Service-Klasse (bzw. eine Instanz dieser) kein domain specific object?

                        Kommentar


                        • #57
                          Zitat von rkr Beitrag anzeigen
                          Trotzdem kann ich mit prozeduraler Programmierung nachher ganz viele Sachen nicht machen, die ich mit OOP kann.
                          Es gibt nichts was nur OOP kann, man kann Alles auch mit rein prozeduraler Programmierung machen.
                          Aber manches nur umständlich, unübersichtlich, fehleranfällig und mit Mitteln welche heutzutage als No-Go gelten wie z.B.
                          - globale Variablen
                          - ellenlange Parameterlisten für Funktionen




                          Kommentar


                          • #58

                            Zitat von jspit Beitrag anzeigen
                            Es gibt nichts was nur OOP kann, man kann Alles auch mit rein prozeduraler Programmierung machen. Aber manches nur umständlich, unübersichtlich, fehleranfällig und mit Mitteln welche heutzutage als No-Go gelten wie z.B. - globale Variablen - ellenlange Parameterlisten für Funktionen
                            Wie schon früher geschrieben, wird am Ende alles immer von einer prozedural arbeitenden CPU ausgeführt. Somit ist alles was man in einer OOP-Spache beschreibt im Ergebnis eine prozedural arbeitende Anwendung und dementsprechend muss alles, was man mit OOP kann, sich auch in prozeduralem Code ausdrücken lassen.

                            Aber das habe ich nicht gemeint. Ich bin schon ganz zu Anfang in diesem Thread drauf eingegangen, dass OOP vor allem eine Ausdrucksweise ermöglicht, die mit prozeduraler Programmierung nicht möglich ist - bzw. nur mit wesentlich mehr Aufwand. Und da wird es für mich nachher leicht unterscheidbar. Wenn ich für einen Task in einer OOP-Sprache nur einen Bruchteil der Zeit brauche, um eine komplexe Programmarchitektur zu beschreiben, die sich im Nachhinein leicht anpassen lässt und man so auf neue Entwicklungen (neue Businessrules, neue Komponenten, neue Sprachkonstrukte) schneller reagieren kann, dann kann ich mit OOP etwas machen, was ich mit PP nicht kann. Ich berücksichtige immer auch den Faktor "Zeit" mit.

                            Zu sagen, dass OOP in einigen Fällen zu Verbesserungen führt, kann ich aus der Praxis nicht ableiten. Ich kann mir nur sehr einfache Programmkonstrukte vorstellen, die sich mit PP in PHP schneller und übersichtlicher realisieren lassen, als mit OOP. Jede PHP-Anwendung, die in PP geschrieben wurde, hat mir bislang meine Sicht der Dinge bestätigt: Schwer nachvollziehbarer Müll.

                            Kommentar


                            • #59
                              Hey,

                              rkr

                              Ich möchte noch folgendes anfügen:

                              Du hast geschrieben, dass du bspw. die User-Session injectest.

                              Jetzt ist es ja bei PHP so, dass der ganze State nach jeder Abarbeitung eines Requests wieder weg ist.

                              Im Umkehrschluss kann man daraus folgendes folgern:

                              Du machst also nichts anderes wie

                              new ServiceKlasse() -> inject userSession -> proccessSth -> destruct ServiceKlasse()

                              So oder so ähnlich würdest du das also machen müssen, wenn du das ganze bspw. in die JavaWelt portieren würdest.

                              Dabei die Frage an dich, ist es wirklich so sinnvoll, "process"-objekte zu erstellen, dann eine processMethode aufzurufen um es schließlich wieder zu destruieren, also wieder ressourcen-Aufwändig vom Heap zu entfernen?


                              Zum Thema OO:

                              Nicht die Verwendung von Klassen, der Einsatz von Polymorphie oder Vererbung macht die OO aus, sondern wie genau der Algorithmus später aufgeteilt ist.

                              Die Verwendung von Service-Klassen, in deren die Hauptarbeit stattfindet ist ein eindeutiges Indiz dafür, dass nicht OO programmiert wird.
                              Zu behaupten, man würde so OO programmieren ist einfach falsch! Das ist fast klassisches PP, eben mit nem Touch "neuartiger"-Syntax und Sprachkeywords/features.
                              Und ja da gebe ich dir recht, die Features können unter Umständen ganz nice sein.



                              Es gibt nichts was nur OOP kann, man kann Alles auch mit rein prozeduraler Programmierung machen.
                              Aber manches nur umständlich, unübersichtlich, fehleranfällig und mit Mitteln welche heutzutage als No-Go gelten wie z.B.
                              - globale Variablen
                              - ellenlange Parameterlisten für Funktionen
                              Nur weil ich die Parameter via Structs/Assoziative Arrays/POJOS übergebe oder ich den globalen Namensraum via DI etwas strukurierter gestalte, ist das noch lange kein OO^^



                              lg knotenpunkt


                              Kommentar


                              • #60
                                Eine Session ist nach der Abarbeitung eines Request nicht automatisch weg.

                                Nicht die Verwendung von Klassen, der Einsatz von Polymorphie oder Vererbung macht die OO aus, sondern wie genau der Algorithmus später aufgeteilt ist.
                                Wie wärs wenn du einfach mal anhand realem Code/Projekten verdeutlichst, was "richtiges" OOP ist und was nicht. Das ganze hier ist eine Wortklauberei die fernab von jeglicher Realität ist.
                                "Software is like Sex, it's best if it's free." - Linus Torvalds

                                Kommentar

                                Lädt...
                                X