Ankündigung

Einklappen
Keine Ankündigung bisher.

OO-programming is a synonym for procedural-programming

Einklappen

Neue Werbung 2019

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

  • OO-programming is a synonym for procedural-programming

    Heyho hab die Frage bei laracasts gepostet (ist da vermutlich etwas untergegangen)
    und ich denke hier sitzen auch die besseren Experten^^


    Ihr dürft auch gerne auf Deutsch antworten, ist mir sogar etwas lieber.

    https://laracasts.com/discuss/channe...al-programming


    Da es mal wieder um oo und prozedurale programmierung geht, hab ich es mal unter Software-Design eingeordnet, auch wenn ich wahrscheinlich auf ner Ebene höher argumentiere, gibt aber leider kein Bereich (!(Design OR Architektur))

    Also hier mein Wall of Text:
    hoffe ich bekomme seriöse antworten..

    moin moin,

    if we look into the domin driven design (ddd) there we have services and poj-classes (entity classes)

    i know the advantages from oo
    for example there you have the

    1. single-responsibilty-principle
    2. inversion of control
    3. inheritance
    4. polymophism
    5. and and and

    but you can have these kinds of adavantages in procedural programming too
    (dereferencing of function-pointers in c/php or take a look into the vtables of c++)

    and if you code a function then these function have in most of the cases ONE responsibility.

    And now my problem point 6

    6. Data and Behaviour in one class

    Thats a problem for me!
    And it seems to be a problem for Martin Fowler too
    => Domin driven Design with service-objects (or should i say servie-procedures....)

    you just code extended scalar types: entity-classes with NO behaviour

    (for example the class circle: the draw-method would be Behaviour. the setter-method that only validates the no negative radius is set, would be just a validation mechanism that achieve that a circle is a circle and not "negative-circle" that wouldnt be a circle)

    The draw method would be defined in a service-object, because these kind of method needs maybe some more objects to achieve a correct drawing.


    So my question is why Laravel wrapps the database result into entity-objects (what in my opinion isnt oo, cause it breaks rule 6) and dont work on the raw 1D-Array which represent that entity-object?

    The performance would be higher, too, cause:

    if the servie-routine/method just need some values from the user and not all of them, then the database have just to give these values and not all of them OR if you have an array: it would be no waste of free heap/stack-memory, cause you dont have to fill up the user-object with NULL-values!

    Join-Tables, Aggregate-Tables and and and

    i think laravel do something right, but then that isnt really oo (cause of breaking rule 6)

    So my conclusion:

    Architecure-patterns like layer-models (mvc, osi, etc), and and and a very good.
    We loose here a little bit of performance too, but thats ok (and good for abstraction)

    But oo (particularly rule 6) is crimes against humanity

    And i think ddd or laravel isnt really oo... here the oo is more a synonym for prodecural-programming, or im wrong?

    oo has a problem and so servie-objects and entity-classes (seperation of data and behaviour) are invented

    how do you think about these all kind of aspects??

    lg knotenpunkt





  • #2
    Ich müsste jetzt einen riesigen Aufsatz verfassen um das ganze ins rechte Licht zu rücken. Und das hätte hier keine besondere Wirkung, da ich nur sämtliches, in Büchern bereits ausführlich behandeltes Wissen redundant wiedergeben würde. Sei mir nicht böse, wenn ich deine Frage auf diese einfache Formel runterbreche (korrigiere mich, falls ich es falsch verstanden habe):

    Sind viele der in OO formulierten Lösungen nicht eigentlich nur Stellvertreter von eigentlich besser machinenverarbeitbaren prozeduralen Lösungen?

    OO hat zwei Vorteile gegenüber prozeduraler Programmierung:
    - Menschen denken besser in Dingen und deren Interaktionen, statt in Daten und deren Beziehungen. OO ist also ein Denk- bzw. Kommunikationsmodell.
    - Objektorientierung macht Programmteile besser modular, was mit auf den ersten Grund zurückzuführen ist.

    Nun lässt sich aber nicht alles gut in OO ausdrücken oder denken. Und so gibt es viele verschiedene Flavors mit denen man die Arbeit mit Datenbanken und dem Web irgendwie auf einen Nenner bringen möchte. Das ist auch der Grund, warum es diese ganzen gruseligen ORM-Krücken gibt, die ein paar Sachen ganz toll und einfach und dafür ganz viele andere Sachen hässlich und geschwätzig machen.

    Und Laravel ist jetzt auch kein Musterstück an Objektorientierung. Die nötige Objektorientierung darfst du aber in deiner Businessdomäne freilich ausleben.

    Kommentar


    • #3
      Hallo

      hoffe ich bekomme seriöse antworten..
      Wat. inb4 'Meinungen die nicht mit deinen übereinstimmen sind unseriös'?

      Ehrlich gesagt, würde ich mich über den Text auf deutsch freuen.
      Dazu dann noch auf ein paar Sachen etwas näher eingehen, weil deine Argumentation nicht ganz stimmig bzw. die Gedankengänge dabei nicht transparent erscheinen.

      Ich weiß nichtmal sicher ob es dir jetzt wirklich um OOP an sich, Laravel oder Domain Driven Design geht. Das sind ja grundverschiedene Dinge.

      if we look into the domin driven design (ddd) there we have services and poj-classes (entity classes)

      i know the advantages from oo
      for example there you have the

      1. single-responsibilty-principle
      2. inversion of control
      3. inheritance
      4. polymophism
      5. and and and

      but you can have these kinds of adavantages in procedural programming too
      (dereferencing of function-pointers in c/php or take a look into the vtables of c++)

      and if you code a function then these function have in most of the cases ONE responsibility.
      Hier zum Beispiel.
      Dein erster Satz handelt von DDD, aber der Rest bezieht sich gar nicht mehr darauf.

      Ich bin da aber noch bei dir, funktional oder prozedural kann man die Applikation auch so gestalten, dass man sich auf diese Prinzipien beziehen kann.
      Die Frage für mich wäre, was für einen Umweg müsste ich nehmen, um Vererbung umzusetzen. Ich habe tbh keine Erfahrung in den Bereich, könnte mir nichtmal vorstellen wie das aussehen würde.

      And now my problem point 6

      6. Data and Behaviour in one class

      Thats a problem for me!
      And it seems to be a problem for Martin Fowler too
      => Domin driven Design with service-objects (or should i say servie-procedures....)
      Ist das jetzt der 6. Punkt in der Auflistung für die Vorteile von OOP?
      Wenn ich es richtig in Erinnerung habe galt es glaube ich, in einer Klasse entweder Status ODER Verhalten zu haben, den Punkt verstehe ich also nicht ganz.

      (for example the class circle: the draw-method would be Behaviour. the setter-method that only validates the no negative radius is set, would be just a validation mechanism that achieve that a circle is a circle and not "negative-circle" that wouldnt be a circle)

      The draw method would be defined in a service-object, because these kind of method needs maybe some more objects to achieve a correct drawing.


      So my question is why Laravel wrapps the database result into entity-objects (what in my opinion isnt oo, cause it breaks rule 6) and dont work on the raw 1D-Array which represent that entity-object?

      The performance would be higher, too, cause:

      if the servie-routine/method just need some values from the user and not all of them, then the database have just to give these values and not all of them OR if you have an array: it would be no waste of free heap/stack-memory, cause you dont have to fill up the user-object with NULL-values!

      Join-Tables, Aggregate-Tables and and and

      i think laravel do something right, but then that isnt really oo (cause of breaking rule 6)
      Hier geht es darum wie die Entwickler von Laravel etwas implementiert haben denke ich, kann ich nichts zu sagen.
      Was mir hier auffällt ist 'rule 6'. Aber es ging doch nicht um Regeln sondern um Vorteile von OOP bei der Aufzählung.

      Architecure-patterns like layer-models (mvc, osi, etc), and and and a very good.
      We loose here a little bit of performance too, but thats ok (and good for abstraction)
      Pattern und Architekturen liefern eine Grundlage über die man sich auf technischer Ebene unterhalten kann.
      Warum der Verlust von Performance gut für die Abstraktion ist weiß ich nicht Hast du falsche formuliert, ich denke auch dass gewisse Einbußen bei der Performance für einen Gewinn an Struktur es wert sind.

      But oo (particularly rule 6) is crimes against humanity
      ?

      oo has a problem and so servie-objects and entity-classes (seperation of data and behaviour) are invented
      Siehst du da ein Problem drin?
      Wenn etwas nicht ganz stimmig scheint, wird eben versucht die Ecken und Kanten immer noch ein bisschen weiter abzurunden.
      Also an dieser Stelle ist deine Herangehensweise völlig voreingenommen, dass du die Entwicklung von Mustern als Versuch Schwächen im Paradigma zu beheben auslegst.


      Also... ich würde die Thesen nochmal ordnen und bewerten, ob es da jetzt wirklich ein Problem mit OOP gibt oder ob es am Ende nur ein Implementations-Detail in einem Framework ist das dich stört.
      [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


      • #4
        Zitat von knotenpunkt Beitrag anzeigen
        6. Data and Behaviour in one class

        Thats a problem for me!
        And it seems to be a problem for Martin Fowler too
        => Domin driven Design with service-objects (or should i say servie-procedures....)

        you just code extended scalar types: entity-classes with NO behaviour
        [...]
        Wäre mir neu das das zu den Grundkonzepten von OOP gehört. Vielmehr ist das doch was OOP ausmacht. Das was du da beschreibst ist für mich ein Konzept um potentiellen Problemen mit OOP aus dem Weg zu gehen. Um mal bei deinem Circle zu bleiben. Muss ein Kreis wissen wie er gezeichnet wird? Was ist wenn du ein Kreis in eine SW Bitmap zeichnen willst, einer SVG, einer PDF, usw...? Wie willst du das alles testen? Natürlich muss man dabei auch das Gleichgewicht halten. Du brauchst nicht 50 Ebenen abstrahieren wenn das einzige Ziel ist das der Kreis in eine GD Image gezeichnet werden soll. KISS und YAGNI haben auch ihre Berechtigung.

        Kommentar


        • #5
          Zitat von rkr Beitrag anzeigen
          Ich müsste jetzt einen riesigen Aufsatz verfassen um das ganze ins rechte Licht zu rücken. Und das hätte hier keine besondere Wirkung, da ich nur sämtliches, in Büchern bereits ausführlich behandeltes Wissen redundant wiedergeben würde. Sei mir nicht böse, wenn ich deine Frage auf diese einfache Formel runterbreche (korrigiere mich, falls ich es falsch verstanden habe):

          Sind viele der in OO formulierten Lösungen nicht eigentlich nur Stellvertreter von eigentlich besser machinenverarbeitbaren prozeduralen Lösungen?

          OO hat zwei Vorteile gegenüber prozeduraler Programmierung:
          - Menschen denken besser in Dingen und deren Interaktionen, statt in Daten und deren Beziehungen. OO ist also ein Denk- bzw. Kommunikationsmodell.
          - Objektorientierung macht Programmteile besser modular, was mit auf den ersten Grund zurückzuführen ist.

          Nun lässt sich aber nicht alles gut in OO ausdrücken oder denken. Und so gibt es viele verschiedene Flavors mit denen man die Arbeit mit Datenbanken und dem Web irgendwie auf einen Nenner bringen möchte. Das ist auch der Grund, warum es diese ganzen gruseligen ORM-Krücken gibt, die ein paar Sachen ganz toll und einfach und dafür ganz viele andere Sachen hässlich und geschwätzig machen.

          Und Laravel ist jetzt auch kein Musterstück an Objektorientierung. Die nötige Objektorientierung darfst du aber in deiner Businessdomäne freilich ausleben.
          An dem Aufsatz wäre ich aber interessiert^^, darfst aber auch ruhig (zusätzlich) ein paar Quellen nennen, wo des im richtigen Licht steht....
          Naja in der Buisnessdomäne eben das DDD prinzip anwenden (entity-classes und service-objekts).... ist halt ne verletzung von rule 6.
          Ich finde des ja eigentlich auch praktisch hier das verhalten und einfach state/entity-classes zu trennen
          Ist dann aber auch meiner Meinung nach wieder eher prozeduraler Stil, da ich ne prozedur habe und die Daten/Datenstrukturen bekommt und diese abarbeitet (eventuell side-effects) und ein result zurückgibt
          Also für mich ist das schon super, aber nicht wirklich oo, wie würde ein strenges oo design deiner Meinung nach aussehen, welches genauso flexibel ist wie gerade genanntes?

          Zum Thema Denkmodell: ich bin prozedural/relational aufgewachsen und finde diese Art zu denken eigentlich Denkmodellqualifizierter^^


          Dein erster Satz handelt von DDD, aber der Rest bezieht sich gar nicht mehr darauf.
          In der Tat, hier habe ich etwas missverständlich formuliert
          Sollte ein einleitender Satz sein.... ich nehme ja später noch auf DDD bezug

          Ich bin da aber noch bei dir, funktional oder prozedural kann man die Applikation auch so gestalten, dass man sich auf diese Prinzipien beziehen kann.
          Die Frage für mich wäre, was für einen Umweg müsste ich nehmen, um Vererbung umzusetzen. Ich habe tbh keine Erfahrung in den Bereich, könnte mir nichtmal vorstellen wie das aussehen würde.
          naja man kann bspw. oo in der Sprache C nachbauen.
          C++ ist ja auch irgendwie entstanden.... Das Stichwort für polymorphie und damit auch Vererbung ist die indirekte Adressierung auf Assembler bzw. register-Ebene. Du kannst jedes Programm auf eine Turingmaschine reduzieren, von daher geht des! Wenn du es praktisch wissen möchtest, dann kannst du dir mal die vtables in c++ ansehen (wie es da konkret da umgesetzt ist, weiß ich selber nicht, dass es aber mittels indirekter Adressierung funktioniert, das ist mir klar)


          Wenn ich es richtig in Erinnerung habe galt es glaube ich, in einer Klasse entweder Status ODER Verhalten zu haben, den Punkt verstehe ich also nicht ganz.
          Naja das ist dann wirklich klassisch prozeudural, du überlädst hier im sprachlichen Sinne nur das Wort class^^
          Naja rule 6 kann man auch als Kapselung bezeichnen. Ein Punkt der oo wirklich auszeichnet.
          Naja die anderen Punkte polymorphie und etc, die sind meiner Meinung nach eher optional. Du musst ja nicht ne klasse ableiten und damit vererbung oder etc verwenden.
          Aber man wird schon so gut wie gezwungen wenn man ne Klasse verwendet, dass man hier die Daten und Methoden in ein "Teil" kapselt, also eigentlich das, was oo auch syntaktisch und nicht nur semantisch ausmacht

          und ddd umgeht dieses prinzip, indem es Daten und Verhalten wieder trennt -> prozedurale Semantik, also meiner Meinung nach!

          Viele Personen verwenden ja diese Herangehensweisen
          Von daher stellt sich mir die Frage, ob nicht zumindest dieser Gedanke von oo überholt ist und man nicht wieder eher ins prozudurale abruscht, aber mit den Vorteilen (polymorphie, ....) von oo und Punkt 6 ausgeschlossen!?


          Hier auch noch ne weitere Frage:
          Ich hab einen Anwendungsfall.... diesen definiere ich mittels eines Services/Prozeudur
          Wie könnte deiner Meinung nach dies streng objektorientiert aussehen, also ohne ein service zu nutzen
          Damit dieser Anwendungfall bedient werden kann muss es bspw. auf mehrere Objekte zugreifen und eventuell auch Autorisierungsobjekte, ob der Anwendungsfall an sich ausführbar sein darf für den entsprechenden Clienten oder aber sich das Verhalten je nach autorisierungfall ändert (bspw. nur teile ausführbar sind bzw. ein anders ergebnis in abhängigkeit von der autorisierung)
          -> Aspektorientierte programmierung könnte hier auch eine Lösung sein
          Naja am besten auch noch so, dass der eigentliche Anwendungsfall gar nichts von der Autorisierung mitbekommt -> heißt ich könnte diesen Anwendungsfall auch wieder wo anders verwenden, hier aber bspw. ganz ohne Autorisierung -> gute Wiederverwendbarkeit oder Änderbarkeit

          Meiner Meinung nach ist das alles ziemlich gut prozedural zu lösen und oo inklusiv rule 6 eher hindernd!
          Aber ich würde mich gerne über ein Gegenbeispiel freuen!

          Ein weiteres und nicht triviales Problem in der oo stellt folgendes dar:

          ich habe ein zusammen aus mehreren objekten gesetztes objekt. Wie erhalte ich hier eine niedrige Kopplung? Naja indem ich die unter-Objekte nicht nach außen weitergebe, aber dafür notwendige Methoden in der Head-Klasse anbieten muss um mit hidden-child-objekten kommunizieren zu können (Komplexitätssteigerung!)
          Konkretes bsp.: Klasse Mensch und Klasse Arm. Möchte ich den Arm beugen, so könnte Mensch den Arm zurückgeben und ich die beugungsoperation auf der rückgabe ausführen (client ist an arm gekoppelt).
          Möchte ich diese Kopplung nicht, muss Mensch redundant bzw. weiterleitend die schnittstellte armBeugen() anbieten, welche den Wunsch des Arm-beugens weiter delegiert
          hier baut man schnell komplexität auf, wenn das für alle Methoden und Subklassen so gelten mag. Außerdem baut man flexibilität ab!

          Also ich finde man erkennt auch anhand dieses Beispiels, dass Services die eher global statt gekapselt arbeiten, sinnvoll ist -> aber eben nicht mehr klassisch obektorientiert!




          ich denke auch dass gewisse Einbußen bei der Performance für einen Gewinn an Struktur es wert sind.
          Genau so hab ichs gemeint^^

          Also an dieser Stelle ist deine Herangehensweise völlig voreingenommen, dass du die Entwicklung von Mustern als Versuch Schwächen im Paradigma zu beheben auslegst.
          Naja DDD und servie-objekts und entity-classes sind ja eher weniger ein muster sondern viel mehr selbst ein paradigma, welches ein altes (eben rule 6) überschreibt


          Also... ich würde die Thesen nochmal ordnen und bewerten, ob es da jetzt wirklich ein Problem mit OOP gibt oder ob es am Ende nur ein Implementations-Detail in einem Framework ist das dich stört.
          Nicht das Framework oder DDD stört mich, diese finde ich sogar echt super
          Mich stört eher Regel 6, also ein Teil des oo-paradigmas


          KISS und YAGNI haben auch ihre Berechtigung
          interessante Ansätze!
          Aber ich finde man sollte wie ich oben schon gesagt habe Verbrechen an der Menschheit diskutieren und nicht einfach so hinnehmen
          praktisch gesehen code ich ja auch so, wie es meiner Meinung nach am besten funktioniert und das ist dann automatisch diesen prinzipien entsprechend^^


          hoffe ich bekomme schöne Antworten!
          Die Antworten dürfen auch gerne zitate von büchern enthalten (ich kenne auch net alle Bücher ^^)


          lg knotenpunkt

          Kommentar


          • #6
            Ich habe das Gefühl, dass ich zu vieles in deine Sichtweise hineininterpretieren muss, damit ich das auf meine Sichtweise (sagen wir besser, meinen Lernfortschritt nach 15 Jahren) übertragen kann.

            Objektorientierung ist nur eine Form, Informationen und deren Beziehung auszudrücken (Objekte, Verhalten, Interaktion).

            Ich verstehe jetzt dein Problem noch nicht so richtig. Wenn dir Prozedurale Entwicklung besser passt, dann nutze sie. Du kannst in vielen Sprachen auch das beste aus beiden Welten verbinden. In Scala kannst du mit Case-Classes Datencontainer beschreiben und mit traditionellen Klassen eben Dinge. Das Modell finde ich recht gut...

            Oder shapes @ hack-lang und das Gegenstück in Typescript...

            Kommentar


            • #7
              Eine Primärquelle zu Martin Fowler (und der von knotenpunkt formulierten „Rule 6“) in #1 ist dieser Artikel aus 2003: AnemicDomainModel. Darin finden sich entsprechende Aussagen (die man aber durchaus im Kontext betrachten darf), aber ich sage dazu gezielt nicht mehr, weil knotenpunkt eine ziemliche Querfront aufmacht, indem er – auch aus diesem Artikel – ableitet, dass OOP ein „Verbrechen an der Menschheit“ sei. Ich lehne mich mal aus dem Fenster und sage, dass das definitiv nicht der Einstellung von Fowler zu dem Thema entspricht. Anders gesagt: Die Logik in der Argumentation in #1 sehe ich an der Stelle nicht so recht gegeben. Oder noch anders gesagt: Wenn du denkst, dass Fowler auf prozedurale Programmierung setzen würde, nur weil er über das Anemic Domain Model sagt, dass es „procedural style design“ sei, dann könntest du wahrscheinlich falscher nicht liegen. Das muss man deutlich feststellen.

              Fowlers Ausführungen dazu sind auch nicht unumstritten (Link aus dem zugehörigen Wikipedia-Artikel, ich habe es nicht gelesen) und werden einfach vielfach nicht berücksichtigt (was aber auch praktische Gründe haben mag). (Ich kann leider spontan nicht sagen, wie ein optimales Domain Model nach Fowler beschaffen ist, weil ich keinen Zugriff auf das Buch habe.) Ich habe tatsächlich schon mal an anderer Stelle eine längliche Diskussion darüber geführt, ob ein „Model“ überhaupt Verhalten/Geschäftslogik enthalten darf. (rkr erinnert sich vielleicht. Ich habe meine Argumente mit ihm besprochen. ) Dabei hatte ich unter anderem genau diesen Artikel von Fowler angeführt, um meinen Standpunkt zu stützen, dass ein Model mehr sein darf als eine „geschäftslogiklose“ Entity. Mir ging es dabei einerseits um die reine Semantik („Model“ halte ich für einen generischen Begriff, der eher eine Kategorie bezeichnet als eine konkrete Form von Klassen) und andererseits darum, dass DDD nicht das einzige praktikbale oder denkbare Architekturmuster ist.

              Zurück zum Thema: Ich glaube, die Frage, ob OOP „Blödsinn“ ist und eigentlich nur prozedurale Programmierung (oder wie die These genau lautet), ist nicht produktiv. Um es ganz stumpf zu sagen: Ohne OOP(-Syntax) gibt es (in PHP) keine Kapselung. Damit ist das Thema meines Erachtens erledigt, weil Kapselung ein Feature ist, das man will oder wollen sollte. Ich glaube, die eigentliche Kritik von knotenpunkt richtet sich eher gegen bestimmte Aspekte von DDD.

              Ich tue mich außerdem in dem Kontext mit dem Begriff der „prozeduralen Programmierung“ etwas schwer und würde gern eine Definition lesen, was prozedurale Programmierung eigentlich genau ist. Ich habe nämlich bei derlei Diskussionen immer das Gefühl, dass Leute die Grenze da im Geiste so ziehen, wie es gerade gut zum Argument passt und dabei zum Beispiel auch Dinge, die in OOP-Syntax umgesetzt werden, als prozedural bezeichnen. Womit ich nicht sagen will, dass das richtig oder falsch ist.

              So was…

              Zitat von knotenpunkt
              Du kannst jedes Programm auf eine Turingmaschine reduzieren, von daher geht des!
              …ist zum Beispiel auch kein produktives Argument für oder gegen irgendwas. Auch die Verweise auf C oder C++ bringen im PHP-Kontext relativ wenig. (Gilt auch für Verweise auf sonstige Sprachen. Ist sicherlich alles legitim und auch gut für den Thread, aber halt nur sehr begrenzt übertragbar. Das sollte man bedenken, damit man nicht völlig den Fokus verliert.) Das ist ein wenig so, als würde man auf die Frage, wie man mit einem Fahrrad 160 fährt, antworten, dass es Fortbewegungsmittel gibt, die diese Geschwindigkeit erreichen. Das mag theoretisch richtig sein, ist aber praktisch eher irrelevant, weil wir hier nun mal über Fahrräder reden.

              Naja rule 6 kann man auch als Kapselung bezeichnen. Ein Punkt der oo wirklich auszeichnet.
              Es ist aber auch schon dann Kapselung, wenn es nur um Daten geht. Woher hast du eigentlich diese Regeln? Du fragst immer nach Quellen oder weiterführenden Informationen, hältst dich selbst aber dafür, dass du dieses Thema aufgemacht hast, damit etwas zurück.

              Vielleicht noch als Schlussgedanke: Ich halte eine scharfe Trennung von prozedural und OOP für nicht so recht sinnvoll. Das würde ich etwa daran festmachen, dass OOP auch nicht aus dem Nichts kommt, sondern wohl eher eine syntaktische Fortführung zuvor bestehender Konzepte darstellt. Man modelliert etwa auch „prozedural“ Datenstrukturen, die (mehr oder weniger) realweltlichen „Objekten“ entsprechen. Anders kann man meines Erachtens überhaupt nicht programmieren. Die sind dann eben gewissen Einschränkungen unterworfen, die durch OOP-Funktionalität teilweise aufgehoben werden. Auch deshalb wäre es sicher ganz hilfreich, im Zweifel einfach mal zu definieren, was man genau mit „prozedural“ und „OOP“ meint. Ich glaube nicht, dass es dabei bloß um die Syntax geht.

              Kommentar


              • #8
                Für mich liegt der Hauptunterschied zwischen prozeduraler Programmierung und OOP vor allem in der unterschiedlichen Herangehensweise an ein Problem.
                Bei OOP gilt es Verantwortlichkeiten zu bestimmen und die Aufgaben an die Verantwortlichen zu delegieren. Wenn mit OOP z.B. ein Haus gebaut werden soll, dann modelliert man das Problem, ähnlich wie in der realen Welt, mit Architekten, Statikern, Baumeistern, Fliesenlegern etc., wohingegen bei prozeduraler Programmierung meiner Ansicht nach mehr die Abfolge von Geschehen/Vorgängen im Vordergrund steht, ähnlich wie bei einer Bauanleitung wie man sie z.B. von Möbeln kennt.
                Mit OOP lernen wir beim Programmieren sozusagen wieder wie ein Mensch zu denken. Bei prozeduraler Programmierung hingegen passen wir unser Denken viel stärker an die Arbeitsweise einer Maschine an.
                VG
                Jack
                -

                Kommentar


                • #9
                  Hallo,

                  zu der Thematik wurde schon viel gesagt. Ich kann mich nur einigen Punkten von mermshaus und jack88 anschließen.

                  Jedoch muss ich auch feststellen, dass der Autor OOP noch nicht verstanden hat. Denn ansonsten wäre dieser Thread überflüssig (genauso wie sein englisches Original). Klar ist OOP anders und hat Vor- und Nachteile. Ein großer Vorteil von OOP ist, dass man ständig sich wiederholende Prozeduren in eine Methode auslagert und dann nur noch diese aufrufen muss, anstatt jedes mal das Rad neu zu erfinden zu müssen.
                  Und ja, es stimmt, dass sich ORM Objekte/Klassen kaum von Tabellen im klassischen Sinne unterscheiden. Da wären wir aber dann bei Stored Procedures bzw. ABAP und nicht bei PHP und C++, wo es soetwas gar nicht gibt! In diesem Sinne kann ich der Argumentation Tabellen vs. ORM Objekte nicht folgen. Klar gibt es kleine Hilfsklassen, die rein die Daten repräsentieren, aber das ist auch notwendig um im Kontext der OO zu bleiben. Für dessen Darstellung gibt es ebenfalls unterschiedliche Konzepte/Herangehensweisen (ORM, Active Records, DSL, usw.). Also man sollte schon Äpfel mit Birnen vergleichen und nicht Äpfel mit Äpfeln. Logisch, dass es in der Hinsicht keinen nennenswerten Vorteil zur prozeduralen Programmierung gibt.


                  MFG derwunner

                  Kommentar


                  • #10
                    Zitat von derwunner Beitrag anzeigen
                    Hallo,

                    zu der Thematik wurde schon viel gesagt. Ich kann mich nur einigen Punkten von mermshaus und jack88 anschließen.

                    Jedoch muss ich auch feststellen, dass der Autor OOP noch nicht verstanden hat. Denn ansonsten wäre dieser Thread überflüssig (genauso wie sein englisches Original). Klar ist OOP anders und hat Vor- und Nachteile. Ein großer Vorteil von OOP ist, dass man ständig sich wiederholende Prozeduren in eine Methode auslagert und dann nur noch diese aufrufen muss, anstatt jedes mal das Rad neu zu erfinden zu müssen.
                    Und ja, es stimmt, dass sich ORM Objekte/Klassen kaum von Tabellen im klassischen Sinne unterscheiden. Da wären wir aber dann bei Stored Procedures bzw. ABAP und nicht bei PHP und C++, wo es soetwas gar nicht gibt! In diesem Sinne kann ich der Argumentation Tabellen vs. ORM Objekte nicht folgen. Klar gibt es kleine Hilfsklassen, die rein die Daten repräsentieren, aber das ist auch notwendig um im Kontext der OO zu bleiben. Für dessen Darstellung gibt es ebenfalls unterschiedliche Konzepte/Herangehensweisen (ORM, Active Records, DSL, usw.). Also man sollte schon Äpfel mit Birnen vergleichen und nicht Äpfel mit Äpfeln. Logisch, dass es in der Hinsicht keinen nennenswerten Vorteil zur prozeduralen Programmierung gibt.


                    MFG derwunner
                    Das liegt daran, dass es in der Prozeduralen Programmierung konstrukte wie Methoden fehlen. Man müsste irgendwas erfinden wie ne "Funktion" oder ne "Methode" die Klassenunabhängig ist. Um sowas aber in den Kern von PHP aufzunehmen benötigt es ein Voting mit einer 2/3 Mehrheit. Und solche großen Änderungen kommen nur bei Major Versions zustande. Kannste also lange drauf warten. Vielleicht mit PHP8 oder PHP9.

                    Gruß.
                    Zitat von derwunner
                    "Ein FISI ist auf gut-deutsch der Netzwerker. Das heißt Du gehst rauß zum Kunden oder auf die Straße und verlegst Leitungen" - derwunner 2015

                    Kommentar


                    • #11
                      Zitat von CrocoBlack Beitrag anzeigen

                      Das liegt daran, dass es in der Prozeduralen Programmierung konstrukte wie Methoden fehlen. Man müsste irgendwas erfinden wie ne "Funktion" oder ne "Methode" die Klassenunabhängig ist. Um sowas aber in den Kern von PHP aufzunehmen benötigt es ein Voting mit einer 2/3 Mehrheit. Und solche großen Änderungen kommen nur bei Major Versions zustande. Kannste also lange drauf warten. Vielleicht mit PHP8 oder PHP9.

                      Gruß.
                      Soetwas gibt es doch schon? Man kann doch functions in PHP auch außerhalb von Klassen definieren. Es ist ja immer noch möglich in PHP komplett prozedural zu programmieren. Ich meinte diesbezüglich nur, dass es leichter ist, sich Methoden in Klassen mit sprechenden Namen aufzuteilen, als eine riesen Datei mit lauter functions zu haben (prozedural), in der sich keiner zurecht findet...

                      Kommentar


                      • #12
                        Oh das tut mir sehr leid. Da sind mir doch glatt die Sarkasmus-Tags verloren gegangen. Großes Entschuldigung Meinerseits. Kommt nicht wieder vor. Freut mich aber, dass du weißt dass es Funktionen gibt. Daumen Hoch!
                        Zitat von derwunner
                        "Ein FISI ist auf gut-deutsch der Netzwerker. Das heißt Du gehst rauß zum Kunden oder auf die Straße und verlegst Leitungen" - derwunner 2015

                        Kommentar


                        • #13
                          Ich glaube, er (CrocoBlack) meint so was wie das nachträgliche hinzufügen von Methoden wie bei Javascript, das nachträglich verändern von Klassen wie bei Ruby oder Implizite Klassen wie bei Scala.

                          PHP-Code:
                          object ProductUrlHelpers {
                              
                          implicit class ProductUrlHelper(productProduct) {
                                  
                          def getUrlSlug(): String product.name.toLowerCase
                              
                          }
                          }

                          import ProductUrlHelpers.ProductUrlHelper

                          case class Money(valueBigDecimal)

                          case class 
                          Product(refNoStringnameStringpriceMoney)

                          val product Product(refNo "A1234"name "Testprodukt"Money(123.99))

                          product.getUrlSlug 
                          <3

                          Kommentar


                          • #14
                            Zitat von CrocoBlack Beitrag anzeigen
                            Oh das tut mir sehr leid. Da sind mir doch glatt die Sarkasmus-Tags verloren gegangen. Großes Entschuldigung Meinerseits. Kommt nicht wieder vor. Freut mich aber, dass du weißt dass es Funktionen gibt. Daumen Hoch!
                            Aha. Ich finde es super, dass Leute, die den Sinn meines Posts nicht verstehen auch noch mit Sarkasmus glänzen!

                            Kommentar


                            • #15
                              Der Sinn deines Posts war also nicht, Vorteile von OOP aufzuzeigen?

                              Ich dachte schon das wäre der Sinn und du würdest einfach nur Blödsinn schreiben. Zum Glück war dem nicht der Fall.

                              Wünsche einen schönen Tag.
                              Zitat von derwunner
                              "Ein FISI ist auf gut-deutsch der Netzwerker. Das heißt Du gehst rauß zum Kunden oder auf die Straße und verlegst Leitungen" - derwunner 2015

                              Kommentar

                              Lädt...
                              X