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

  • #31
    Hat die Diskussion eigentlich noch einen Konsens oder wird hier bloß noch über nichts sagende Dinge gesprochen?! 20 Tausend Server, ach ne, doch lieber eine funktionale Sprache...

    Kommentar


    • #32
      Konsens ist abhängig von Erfahrung. Was soll man denn auf die Eingangsfrage antworten? Da werden so viele Mutmaßungen angestellt, die ich einfach mal nicht als harte Kriterien auslegen würde. State in einer Webanwendung kann sinnvoll sein - kommt auf die Webanwendung an. Für eine Backoffice/Admin-Anwendung macht State in gewissem Maße sicher Sinn. Kann man aber auch mit PHP machen (Amp, ReactPHP, PThreads, etc).

      Performance?
      Der Goldstandard in Sachen State-Handling und Performance sind gerade eben actor-basierte Verarbeitungsmodelle wie OTP/BEAM oder Akka, weil sie die zur Verfügung stehenden Ressourcen maximal effizient ausnutzen. Nicht ohne Grund ist Erlang da eine funktionale Sprache, bei der alle Datenstrukturen immutable sind. Willkommen in der Welt der Nebenläufigkeit.

      Das Actor-Modell kann man aber auch in PHP mit PThreads nachbauen. Allerdings gibt es da keine Immutability wie bei vielen funktionalen Sprachen. Bei PHP wird dann wirklich von allem eine Kopie erzeugt. In Java gibt es auch keine Immutability. In beiden Sprachen müsste man für effizientes Datenhandling erst die passenden Strukturen nachbauen, damit einem die Veränderbarkeit der Daten nicht alle 5 Meter bei Threadprogrammierung wieder auf die Füße fällt. Bei Java sieht man an Scala (= JVM Sprache, für die viele bereits vorhandene Datenstrukturen neu aufgebaut werden mussten), wie viel man da machen muss, um halbwegs Threadsicher zu programmieren. Bei PHP ist das ähnlich aussichtslos. Man müsste sowohl Objekte als auch Arrays überall als Kopie rumreichen, was wahnsinnig ineffizient ist, oder alles immutable machen, was nur begrenzt möglich ist - denn Erlang erstellt nicht jedes Mal von allem eine Kopie, sondern dedupliziert die vorhandenen Dateninstanzen (Liste + Neuer Eintrag = Liste von davor plus ein weiterer Eintrag).

      http://highscalability.com/blog/2016...-using-ju.html

      Und dann kommt da noch der Punkt, dass du über mehrere Maschinen skalieren willst, ohne dass sich deine Anwendung anfühlt, wie eine verteilte Anwendung. Das ist das, was Akka und Erlang/OTP im Kern machen - Aufgaben verteilen. Anwendung effizient auf 10.000 Nodes laufen lassen? Konfigurationssache. Zudem kommt, dass du als Entwickler theoretisch mit Millionen von Threads pro Node arbeiten kannst, ohne dass die Maschine weniger responsive wird.

      Sprache
      Weder PHP noch JAVA sind in irgendeiner Weise schöne Sprachen. PHP kann dank einiger IDEs sehr viel Typisierung darstellen, was bei mir erfahrungsgemäß die Fehlerquote senkt und meinen Workflow verbessert. Ich arbeite jetzt mehr als 15 Jahre unter anderem mit PHP und Java. Ich muss immer noch ständig in die Hilfe schauen, wie die Parameter lauten, oder wie sich bestimmte Internals bei bestimmter Parametrisierung verhalten. Bei Ruby und Python habe ich das nicht. Ich bin trotzdem immer noch effizienter mit PHP als mit Ruby und Python.

      Bibliotheken
      Ich glaube sowohl für PHP als auch für JAVA gibt es zu allem etwas - zumindest im Webumfeld. Auch kein Kriterium.

      Was willst du da für einen Konsens erzielen?

      Wenn du etwas in PHP schreiben willst, weil du dich damit auskennst und schneller zu Ergebnissen kommst, als mit Java, oder sonst für Zeug, dann mach das eben so. Wenn du 2018 das neue Facebook sein willst, dann wirst du an Technologien wie Akka oder Erlang/OTP (bzw. Elixir als Makrosprache für Erlang und Phoenix) nur schwer herumkommen. So what?

      Zitat von knotenpunkt Beitrag anzeigen
      Wie kommst du auf funktional?
      Wenn ich in Haskell oder in Scala Funktionen schreibe, die intern keinen state verwenden, also auch nicht im Algorithmus selbst, dann wäre es funktional.
      Jain. Wie ist das bei Monaden?

      Kommentar


      • #33
        Zitat von rkr Beitrag anzeigen
        Das Actor-Modell kann man aber auch in PHP mit PThreads nachbauen. Allerdings gibt es da keine Immutability wie bei vielen funktionalen Sprachen. Bei PHP wird dann wirklich von allem eine Kopie erzeugt. In Java gibt es auch keine Immutability. In beiden Sprachen müsste man für effizientes Datenhandling erst die passenden Strukturen nachbauen, damit einem die Veränderbarkeit der Daten nicht alle 5 Meter bei Threadprogrammierung wieder auf die Füße fällt. Bei Java sieht man an Scala (= JVM Sprache, für die viele bereits vorhandene Datenstrukturen neu aufgebaut werden mussten), wie viel man da machen muss, um halbwegs Threadsicher zu programmieren. Bei PHP ist das ähnlich aussichtslos. Man müsste sowohl Objekte als auch Arrays überall als Kopie rumreichen, was wahnsinnig ineffizient ist, oder alles immutable machen, was nur begrenzt möglich ist - denn Erlang erstellt nicht jedes Mal von allem eine Kopie, sondern dedupliziert die vorhandenen Dateninstanzen (Liste + Neuer Eintrag = Liste von davor plus ein weiterer Eintrag).
        Java ist threadsicher. Und vorallem eine schöne Sprache für die Thread Programmierung. Nach deiner Aussage müsste ich davon ausgehen, dass Du von dem Shared nothing Prinzip, dem Java synchronized Schlüsselwort usw. noch nichts gehört hast. Denn das sind gerade die Dinge, mit den man threadsicher Java programmieren kann, ohne das einem irgendwas auf die Füße fällt.
        Bei PHP gibts das übrigends auch. Hier macht man das, wie bei C++, über das Mutex.

        Dein beschriebenes Verhalten mit dem skalieren über mehrere Rechner kann übrigends auch eine MessageQueue Server wie der RabbitMQ.

        Kommentar


        • #34
          Der große Unterschied ist eben, dass man mit Java (und PHP) threadsicher programmieren _kann_. Man muss aber genau wissen, was man da tut. Und du musst eine ganze Menge Wissen, damit das ganze noch effizient die zur Verfügung stehenden Hardwareressourcen ausnutzen kann. Nebenläufigkeit ist hier alles andere als ein leichtes Thema - und ja, wenn man nicht den perfekten Plan hat, dann wird einem die Nebenläufigkeit zum ständigen Ärgernis. Zumal Raceconditions und so Zeug extrem schwer zu debuggen sind - besonders im Livebetrieb.

          Akka ist im Kern sowas wie RabbitMQ. Wenn du MassageQueues verstanden hast, dann, dann kennst du auch das Grundprinzip von Akka. Akka ist aber noch viel mehr als das.
          Fun fact: RabbitMQ wurde in Erlang geschrieben.

          Kommentar


          • #35
            Zitat von derwunner Beitrag anzeigen
            Java ist threadsicher.
            Nicht per se. Java hindert dich nicht daran Race Conditions zu verursachen.

            Zitat von derwunner Beitrag anzeigen
            dem Java synchronized Schlüsselwort
            Das falsch verwendet auch Deadlocks verursachen kann.

            Zitat von derwunner Beitrag anzeigen
            Denn das sind gerade die Dinge, mit den man threadsicher Java programmieren kann
            Kann.
            [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

            Kommentar


            • #36
              Zitat von rkr Beitrag anzeigen
              Das Actor-Modell kann man aber auch in PHP mit PThreads nachbauen. Allerdings gibt es da keine Immutability wie bei vielen funktionalen Sprachen. Bei PHP wird dann wirklich von allem eine Kopie erzeugt. In Java gibt es auch keine Immutability. In beiden Sprachen müsste man für effizientes Datenhandling erst die passenden Strukturen nachbauen, damit einem die Veränderbarkeit der Daten nicht alle 5 Meter bei Threadprogrammierung wieder auf die Füße fällt. Bei Java sieht man an Scala (= JVM Sprache, für die viele bereits vorhandene Datenstrukturen neu aufgebaut werden mussten), wie viel man da machen muss, um halbwegs Threadsicher zu programmieren. Bei PHP ist das ähnlich aussichtslos. Man müsste sowohl Objekte als auch Arrays überall als Kopie rumreichen, was wahnsinnig ineffizient ist, oder alles immutable machen, was nur begrenzt möglich ist - denn Erlang erstellt nicht jedes Mal von allem eine Kopie, sondern dedupliziert die vorhandenen Dateninstanzen (Liste + Neuer Eintrag = Liste von davor plus ein weiterer Eintrag).
              PThreads bietet mit Threaded eine Immutable Struktur für Arrays und Objekte, Primitives lassen sich weiterhin ändern. Zudem werden Threaded Objekte nicht kopiert, sie werden zwischen Kontexten geshared wie normale Objekte. Oder meinst du das Handling von Plain PHP Strukturen mit PThreads?

              Ist jetzt vielleicht nicht der richtige Thread aber wenn ihr Vorschläge zur Verbesserung von PThreads habt, immer her damit!

              Kommentar


              • #37
                Zitat von SirSnyder
                PThreads bietet mit Threaded eine Immutable Struktur für Arrays und Objekte, Primitives lassen sich weiterhin ändern.
                Hi, kannst du da mal ein Beispiel zu geben?

                Zitat von SirSnyder
                Zudem werden Threaded Objekte nicht kopiert, sie werden zwischen Kontexten geshared wie normale Objekte.
                Ich habe das vor allem auf das Verhalten bei Datenmanipulation bezogen. Bei Haskell, Erlang (und damit auch elixir) und Scala (Immutable Library) wird bei Manipulation einer Liste oder einer Struktur ein anderes System zur Projektion der Daten verwendet.

                Immutable Daten können ja nicht verändert werden. Heißt, dass ein Entwickler für eine Änderung eigentlich eine Kopie der Daten mit der von ihm gewünschten Anpassung macht. Tatsächlich wird aber idR keine echte Kopie erzeugt, sondern nur eine Referenz auf die alte Version plus die gemachte Änderung erstellt. Wird eine Struktur geändert, es gibt aber keinen weiteren Zeiger auf die alte Referenz, wird die Änderung normal direkt gemacht. Das ist noch eine sehr naive Darstellung des tatsächlichen Sachverhalts. Heißt: Vermeintlich schwergewichtige Änderungen sind häufig dann aber doch relativ leicht.

                Ich kenne jetzt die Implementierung von PHP im Bezug auf Primitives (null, bool, int, float, string, resource) nicht, hätte jetzt aber instinktiv vermutet, dass das gleiche passiert, was in anderen Sprachen auch passiert: Wenn ich einen Wert eines solchen Typs ändere, dann wird der alte Wert verworfen und der Neue zugewiesen. Da man in PHP Variablen aber referenzieren kann, kann man darauf wahrscheinlich aber auch nicht immer vertrauen.

                Pthreads alleine wird noch keine ausreichende Lösung für Nebenläufigkeit in komplexen Projekten bringen. Wie auch Amp/React und so. Alles ganz nett, aber nicht wirklich praktikabel. Für kleine Projekte aber durchaus toll.

                Kommentar


                • #38
                  moin moin,


                  xm22

                  Genau dasselbe: Du kümmerst Dich um Sachen, die momentan nicht annähernd relevant sind. Wenn Du eine so krasse Applikation erstellen willst, dann spielt es doch keine Rolle, wo sie am Ende gehostet wird.
                  Naja man muss bei seiner Softwarearchitektur schon ein Augenmerk für die spätere Integration haben. Wenn ich bspw. gegen die Cloud-Api von Google programmieren möchte, dann sollte ich das schon auch anfangs berücksichtigen.
                  Aber ja natürlich sollte meine Anwendung auch die Möglichkeit haben, später ohne die Google-Cloud-Api auszukommen. Dies hat dann ein mehr oder wenigeres Refactoring zur Folge


                  Im Internet ist es ja immer schwierig, das "herauszuhören", daher: Ist das jetzt ironisch gemeint?
                  JA^^, aber wird doch aus den ein zwei Sätzen danach klar?

                  Weil ich nicht glaube, dass Du eine rein funktionale Applikation warten möchtest. Java fällt dann flach. Eines der Kernkonzepte dieser Sprache ist OO.
                  Habe ja auch nie vorgehabt funktional zu programmieren. Mich interessiert an der Stelle nur, wie du darauf kommst, oder wo du herausgelesen hast, dass ich funktional meine?


                  Der Artikel sagt, dass es Business-Cases gibt, die in einer Transaktion abgearbeitet werden sollen - Von OO oder prozedural oder wie auch immer steht da kein Wort.
                  Vllt. ist dieser Beitrag hier besser: http://gunnarpeipman.com/2013/10/tra...cript-pattern/

                  Blöcke ist das falsche Wort. Und es gibt etliche Wege, wie die miteinander kommunizieren können.
                  Naja Blöcke== festgeschraube Objekte, so war das gemeint. Und auf welchem Wege sollen die sonst noch kommunizieren.
                  Alan Key hat das so definiert, dass Objekte Messages senden bzw. empfangen.
                  Eine explizite Methodendefinition ist im reinen OO nicht vorgesehen und sind in PHP, JAVA, C++ nur Hilfskonstrukte. SmallTalk ist hier das Stichwort^^

                  Wie kommst Du denn darauf?
                  Naja aus Erfahrung. Ein Argument das für dich eventuell zählt: Nicht ohne Grund kommt man mit PP schneller zu seinem Ziel wie mit OO....... diese Aussage ist allgemeiner Konsens
                  Aber wenn du möchtest kann ich hier auch noch ein paar Beispiele posten


                  SO kann OO aussehen, aber wo ist das Problem?
                  Ich würde sagen so MUSS.......
                  Aber wie kann OO noch aussehen?


                  Klar - Am Ende ist die Implentierung einer Logik in einer imperativen Sprache immer prozedural. Es geht ja um die Kapselung der Business-Logik.
                  Was bedeutet Buisniess-Logik?
                  1) Logik die auf scalaren, einfach Datentypen ausführbar ist? Zahlen, Strings, Booleans........?
                  2) Logik die auf ADTs ausführbar ist: Listen, Hashtables, allgemein Collections?
                  3) Oder auch Logik die auf komplexen Datenstrukturen ausführbar ist: Class Haus, Class Haus-Sachbearbeiter/Manager/Service Class Fenster usw........

                  Und genau um diesen Sachbearbeiter/Manager/Service geht es...... Ist er Bestandteil der Haus-Klassen-Collection, oder ist er ein externer Service?
                  Wobei selbst wenn er in der Haus-Klassen-Collection wäre, ist es fragwürdig ob das gutes OO ist, wobei hier mein Latein am Ende ist, wo man diese Funktionalität sonst unterbringen soll
                  Funktionalität, die nicht nur das Haus, sondern auch andere Klassen zeitgleich betrifft

                  Ich würde sagen, dass nur wenn alle 3 Punkte eingehalten sind, die Anwendung OO sein kann. Darüber hinaus darf auch keine anwendungsrelevante Logik einfach so in externe Services ausgelagert werden.


                  Du verwechselst DI mit DI-Containern.
                  Warum soll ich das verwechseln?


                  Welches Problem beschreibst Du hier?
                  Naja dass ich einen Manager direkt an der Objektwelt habe und der nicht alleine für sich steht.
                  Sprich ich muss diesen Manager/Service später auch nicht via DI irgendwo hineingeben, sondern er ist schon an entsprechender Stelle fest verankert.

                  Völlig undifferenzierte Aussage
                  Naja, dieses sogenannte psuedo-oo oder service-basierte Programmieren finde ich ja selbst sehr gut!, wobei je mehr service und desto weniger OO umso besser -> mehr flexibiltiät
                  je mehr OO -> desto weniger flexibilität, weil irgendwie alles statisch verdrahtet worden ist und später der Programmfluss nicht mehr aus dem Algorithmus heraus bestimmt wird, sondern aus der starren Objektwelt
                  Und um hier Funktionen nachzurüsten, muss man komplex in diese Objektwelt eingreifen. Das geht, ist aber aufwändig. Was daraus folgt ist guter testbarer Code, mehr aber auch nicht, Naja ein haufen Overheadprogrammierung eben noch^^


                  rkr

                  Um hier den überlegenden Vorteil von OO zu erkennen brauchen wir DI
                  DI ist ein Merkmal, dass prozedural programmiert wird, objektorientiert dagegen nur auf Metaebene. Mehr dazu gleich.


                  DI (wobei ich mich dabei hauptsächlich auf Constructor-Injection beschränke) ist doch einfach nur das Referenzieren von anderen Instanzen von Objekten, die eine bestimmte Form haben.
                  Und das ist doch genau der Punkt. Bei einem prozeduralen Programm habe ich überall statische Aufrufe zu meinen Funktionen drin. Wenn ich meine Umgebung für unterschiedliche Umgebungen konfigurieren will, dann stehe ich bei PP vor schwer lösbaren Problemen, das ich bei OO wesentlich leichter lösen kann. Bei OO brauche ich nur ein stabiles, durchdachtes Interface. Danach kann ich meine Services nach Bedarf austauschen. An zentraler Stelle, dank DI.
                  DI wird verwendet, für Services/Manager etc pp.
                  Ich lese aus deinem Abschnitt heraus, dass du mittels DI prozedurale Module konfigurierbar machst. Bspw. einen EmailService, einen RenderService, einen AccountService.
                  Mittels DI verbindest du diese Services (meist zu Programmstart) miteinander.
                  Und das meinte ich mit objektorientiert auf Metaebene. Ja du programmierst in dieser Schicht, auf der Ebene objektorientiert. Deine einzelnen Prodzurenblöcke sind schöne Objekte. Deine Programmfabrik wird schön objektorientiert aufgebaut.
                  Der eigentliche Programmablauf dagegen ist aber wieder prozedural, da deine Fabrik proezdural arbeitet. Die Daten ((anemic -> siehe Fowler) Domainobjekte) werden dann schön durch die Fabrik/Prozeduren geschickt^^
                  In einer nicht pseudo-objektorientierten Programmierweise würde es diese objektorientierte zusammengesteckte aber auf proezduralerweise arbeitedende Fabrik -> die Services nicht geben.
                  Somit wäre auch DI überflüssig^^

                  Die Frage ist aber, warum wird so programmiert, warum nicht vollständig objektorientiert?
                  Weil man prozedural einfach flexibler ist?
                  Weil man viele Probleme nicht sinnvoll mittels Objektorientierung lösen kann?
                  Weil in der OO kein Wert auf den controll-flow gelegt wird?, weil oo einfach zu kurz gedacht ist?



                  Ich habe dadurch auch noch einen anderen Vorteil. Denn für mich als Entwickler fühlt sich jedes einzelne Objekt an, wie ein kleines prozedurales Program. Ich habe in Objekten nämlich State. Wenn ich das mit PP nachbilden wollen würde, dann würde ich allen Prozeduren/Funktionen ständig wieder den State als Parameter durchreichen. Was für ein Quatsch, wenn meine Applikation das nicht zwingend so benötigt, was meiner Erfahrung nach praktisch nie der Fall ist. Methoden übergebe ich nur noch ein Minimum an Informationen. Informationen, die ich in den Layer in der Regel auch habe...
                  Warum Quatsch?
                  Das ist doch super testbar.
                  Du hast doch selbst weiter unten die funktionale Programmierung erwähnt. Die Funktionen bekommen ihre Datengrundlage auch von aussen^^


                  • Und in einem prozeduralen Programm mit globalem State zu arbeiten, haben die allermeisten Entwickler schon als ein großes Übel erkannt.
                  Deine mittels DI verbundenen Service Klassen arbeiten mit welcher Art von State?
                  Daten die von aussen kommen und meinetwegen in einem anemic Domain Objekt verpackt sind (das zwar seine Variablen mittels private schützt, diese aber dagegen via setter/getter Methoden wieder zugreifbar macht) sind für mich dem global State zuzurechnen. Selbst wenn das Domain Objekt nicht ganz so anemic ist und meinetwegen noch ein paar Buisness-Funktionen selbst implementiert.
                  Oder siehst du das anders?

                  • PP ist OOP mit wesentlich weniger Funktionsumfang.
                  Und genau das ist falsch.


                  OO ist nicht: Vererbung, Polymorphie, SOLID etc. pp
                  OO ist ein Paradigma, wie du zu programmieren hast.
                  Du schnürst Verhalten und Behaviour zusammen. (was meiner Meinung nach gut bei ADTs, einfachen Klassen geht, aber für Komplexere Dinge..........)
                  Die Objekte kommunizieren via Messages miteinander.
                  Es fliessen keine Daten^^


                  • Mit PP hat man generell wesentlich(!) weniger Möglichkeiten, sein PHP-Programm statisch zu typisieren.
                  Ja das ist ein Punkt, der das Programm gut testbar macht.
                  Aber was heisst statisch typisieren schon, wenn du mittels dynamic late binding und solchen Spielereien, das ganze wieder umgehen kannst.
                  Und du brauchst nunmal die dynamic in deinem Programm. Ein statisches Programm ist gut testbar, aber auch sehr unflexibel.
                  Die Frage hier an dich, wie würdest du die eben angesprochene dynamic mittels statischem Gerüst nachbauen? Hättest du da ein paar Beispiele für mich?

                  Du programmierst ja mittels DI und Services. Die statische Typisierung hast du nur hier. Nicht aber später wenn deine 'Fabrik' (hat nichts mit dem factory-Design-pattern zu tun, sondern mit dem, was ich oben geschrieben habe (ich verwende den Begriff eben dynamisch bzw. polymorph^^)) die Domainobjekte bearbeitet^^

                  Wenn ich jetzt aber aus dem Alogorithmus heraus entscheiden möchte, dass es vllt. ganz nett wäre eine andere EmailService-Implementierung zu verwenden........... wie würdest du das machen?


                  Besonders im Hinblick auf Performance und Skalierbarkeit
                  Ist funktionale Programmierung performancetechnisch nicht weit hinter pp oder oo?



                  lg knotenpunkt

                  Kommentar


                  • #39
                    Hi, wir diskutieren hier mittlerweile 10 verschiedene Konzepte auf einer Ebene, die keinen Nutzen für irgendwen bringt. Meine letzten Beiträge sind nach der langen Zeit und etwas Distanz aus meiner heutigen Sicht für niemanden wirklich brauchbar - zugegeben.

                    Generell kann ich dir auf praktisch jeder Ebene energisch widersprechen. Aber das führt alles zu nichts. Würden wir das Thema zerlegen und die Details diskutieren, würden wir auch einander besser verstehen.
                    • OOP ist natürlich immer auch PP, letztendlich wird jedes Programm von einer prozedural arbeitenden CPU ausgeführt.
                    • OOP ist leichter für Menschen begreifbar - wenn nachvollziehbar geschrieben.
                    • OOP ist PP + weitere Funktionen - warum sich künstlich beschränken?
                    • DI kann ein Programm für verschiedene Domänen konfigurieren (Polymorphie vorausgesetzt) - auch abhängig von (beispielsweise) einem Webrequest. Und das mache ich auch so. Und nicht nur ich
                    • FP ist da performance-technisch im Vorteil wo sich Prozesse parallelisieren lassen. Erlang/Elixir haben außerdem "Prozesse", die der Idee von Original-OOP recht nahe kommen. Abgesehen davon dürfte FP nur selten performanter sein, als PP oder OOP.

                    Kommentar


                    • #40
                      Hey,

                      rkr

                      Generell kann ich dir auf praktisch jeder Ebene energisch widersprechen. Aber das führt alles zu nichts. Würden wir das Thema zerlegen und die Details diskutieren, würden wir auch einander besser verstehen.
                      Ja ich wäre daran interessiert, Also sowohl am Widersprechen im Detail als auch an der Themazerlegung.

                      • OOP ist natürlich immer auch PP, letztendlich wird jedes Programm von einer prozedural arbeitenden CPU ausgeführt.
                      • OOP ist PP + weitere Funktionen - warum sich künstlich beschränken?
                      Also ja die CPU führt prozeduralen Maschinencode aus, aber bei den anderen Punkten muss ich widersprechen
                      siehe

                      OO ist nicht: Vererbung, Polymorphie, SOLID etc. pp
                      OO ist ein Paradigma, wie du zu programmieren hast.
                      Du schnürst Verhalten und Behaviour zusammen. (was meiner Meinung nach gut bei ADTs, einfachen Klassen geht, aber für Komplexere Dinge..........)
                      Die Objekte kommunizieren via Messages miteinander.
                      Es fliessen keine Daten^^
                      DI kann ein Programm für verschiedene Domänen konfigurieren (Polymorphie vorausgesetzt) - auch abhängig von (beispielsweise) einem Webrequest. Und das mache ich auch so. Und nicht nur ich
                      Ja du konfigurierst SERVICES mit weiteren SERVICES oder primitiven Daten.
                      Ich persönlich finde das gut. Und da es ja nicht nur du so machst, sonderen andere auch, finden die Idee andere auch gut^^
                      ABER: das ist eben kein OO, sondern nur noch pseudo-OO



                      • FP ist da performance-technisch im Vorteil wo sich Prozesse parallelisieren lassen. Erlang/Elixir haben außerdem "Prozesse", die der Idee von Original-OOP recht nahe kommen. Abgesehen davon dürfte FP nur selten performanter sein, als PP oder OOP.
                      Ja, da stimme ich dir zu.




                      lg knotenpunkt

                      Kommentar


                      • #41
                        Was ist denn dein Punkt in max 60 Worten?

                        Kommentar


                        • #42
                          Hey

                          Zitat von rkr Beitrag anzeigen
                          Was ist denn dein Punkt in max 60 Worten?
                          Der Punkt ist: Es programmiert heutzutage (fast) niemand OO, nur noch auf pseudo-Ebene.
                          Services und damit verbunden DI-Injection/Service-Locatoren etc pp sind ein eindeutiges Indiz dafür.
                          Diese Services arbeiten prozedural.

                          Und nein PP ist keine Untermenge von OO (siehe Definition von OO).
                          Das sind zwei grundverschiedene Ansätze.


                          lg knotenpunkt

                          Kommentar


                          • #43
                            Zitat von knotenpunkt Beitrag anzeigen
                            Der Punkt ist: Es programmiert heutzutage (fast) niemand OO, nur noch auf pseudo-Ebene.
                            Services und damit verbunden DI-Injection/Service-Locatoren etc pp sind ein eindeutiges Indiz dafür.
                            Diese Services arbeiten prozedural.
                            Ohne der Diskussion bisher gefolgt zu sein, würde ich hierzu gerne mal eine ganz konkrete Gegenüberstellung von "Pseudo-OO" und "OO" (nach deinem Verständnis) sehen. Mir ist nämlich nicht ganz klar was du mit "pseudo" in diesem Zusammenhang meinst.
                            [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                            Kommentar


                            • #44
                              Hey,

                              lottikarotti

                              Ohne der Diskussion bisher gefolgt zu sein, würde ich hierzu gerne mal eine ganz konkrete Gegenüberstellung von "Pseudo-OO" und "OO" (nach deinem Verständnis) sehen. Mir ist nämlich nicht ganz klar was du mit "pseudo" in diesem Zusammenhang meinst.
                              pseudo-OO ist einfach die Tatsache, dass du deine Prozeduren objektorientiert aufbaust -> Services
                              Sprich die Services kommunizieren untereinander wie Objekte. Die Aufgaben, die sie verrichten sind dagegen prozedural.

                              Siehe ein Zititat von mir:

                              DI wird verwendet, für Services/Manager etc pp.
                              Ich lese aus deinem Abschnitt heraus, dass du mittels DI prozedurale Module konfigurierbar machst. Bspw. einen EmailService, einen RenderService, einen AccountService.
                              Mittels DI verbindest du diese Services (meist zu Programmstart) miteinander.
                              Und das meinte ich mit objektorientiert auf Metaebene. Ja du programmierst in dieser Schicht, auf der Ebene objektorientiert. Deine einzelnen Prodzurenblöcke sind schöne Objekte. Deine Programmfabrik wird schön objektorientiert aufgebaut.
                              Der eigentliche Programmablauf dagegen ist aber wieder prozedural, da deine Fabrik proezdural arbeitet. Die Daten ((anemic -> siehe Fowler) Domainobjekte) werden dann schön durch die Fabrik/Prozeduren geschickt^^
                              In einer nicht pseudo-objektorientierten Programmierweise würde es diese objektorientierte zusammengesteckte aber auf proezduralerweise arbeitedende Fabrik -> die Services nicht geben.
                              Somit wäre auch DI überflüssig^^

                              Die Frage ist aber, warum wird so programmiert, warum nicht vollständig objektorientiert?
                              Weil man prozedural einfach flexibler ist?
                              Weil man viele Probleme nicht sinnvoll mittels Objektorientierung lösen kann?
                              Weil in der OO kein Wert auf den controll-flow gelegt wird?, weil oo einfach zu kurz gedacht ist?


                              lg knotenpunkt

                              Kommentar


                              • #45
                                Wenn ich mich auch mal einklinken darf:
                                Die Aufgaben, die sie verrichten sind dagegen prozedural.
                                [...]
                                Der eigentliche Programmablauf dagegen ist aber wieder prozedural
                                Ich verstehe nicht was du damit meinst, dass der normale Programmablauf oder die Aufgaben prozedural seien.

                                Der Ablauf ist normalerweise nicht prozedural.
                                Nur weil du z.B. einige Kontrollsequenzen und PHP-Funktionen nutzt ist das nicht prozedural. Es wurde lediglich das Verhalten des Objektes definiert.
                                "Software is like Sex, it's best if it's free." - Linus Torvalds

                                Kommentar

                                Lädt...
                                X