Ankündigung

Einklappen
Keine Ankündigung bisher.

(java vs php) + frameworks

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

  • #61
    Zitat von knotenpunkt Beitrag anzeigen
    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?
    Performance? Macht praktisch keinen Unterschied. Ich muss mich ja auch im nichts wirklich kümmern - das meiste wird - dank Autowiring und Garbage Collection - automatisch für mich gemacht.

    Der Ablauf sieht in etwa so aus, wie du es beschreibst. Mit ein paar Abweichungen im Detail. Die Injektion erfolg nicht nach der Instanziierung, sondern während der Instanziierung (Constructor-Injection / Autowiring).
    Autowiring funktioniert ein wenig wie Autoloading, mit dem Unterschied, dass ich nicht Zugriff auf Klassen bekomme, ohne sie explizit zu importieren, sondern fertig instanziierte Objekte bekomme, ohne was dafür tun zu müssen.

    Lass mal die Perspektive wechseln. Wenn du in der prozeduralen Welt unterwegs bist, dann wirst du immer das Problem haben, State rumzureichen. Nehmen wir einfach mal einen Webshop. Da werden bestimmte Informationen im Bootstrap gesammelt:
    • Ist der User eingeloggt?
      • Hat der eingeloggte User irgendwelche speziellen Rabatte auf Produkte?
      • Kann der eingeloggte User Elemente auf der Seite sehen, die andere User nicht sehen können?
      • Oder: Kann der eingeloggt User Elemente auf der Seite nicht sehen...
    • Was ist die aktuell ausgewählte Sprache?
    • Befinden sich Elemente im Warenkorb?
      • Haben die im Warenkorb befindlichen Elemente eine Auswirkung auf andere Elemente auf der Seite?
        • Versandkostenfreie Artikel machen ggf. alles Versandkostenfrei, weil sie die Versandkosten schon finanzieren)
        • Rabatte, die dadurch aktiviert werden, dass man Produkt X mit Produkt Y zusammen kaufen kann
    Das kann man beliebig aufblähen. Wie hast du zu jedem beliebigen Punkt in deiner Anwendung Zugriff auf diese Informationen? Oder anders gefragt: Woher weißt du auf unterster Ebene, welche in der Call-Kaskade deiner Funktionen angesprochenen Funktionen welche Informationen benötigen, die du bis dahin durchschleifen musst, ohne diese Informationen global bereitzustellen?

    Mit DI ist das recht simpel. Du hast eine Klasse, die in ihrem Konstruktor andere Klassen erwartet. Die Objekte, die Methoden dieses Klassenobjekts aufrufen, wissen nicht, welche Hilfsmittel dieses Objekt benötigt, um seine Aufgabe zu erfüllen. In der Funktionalen Welt kann man das zum Teil durch Currying oder Monaden abbilden. Bei traditioneller prozeduraler Programmierung kannst du das so nicht abbilden. Da musst du möglichst flache Hierarchien schaffen, um nicht zu viel State durch Prozeduren zu schleifen, die diesen State selbst gar nicht benötigen. Oder du musst mit globalen Informationen arbeiten, was automatisiertes Testen extrem schwierig macht. Ich bilde zum Teil sogar scalare Werte in Form von Klassen ab, die dann dank Autowiring den Klassen zur Verfügung gestellt werden, die diese Werte benötigen.

    Und ich kann in Objekten Informationen cachen. Ich muss ja nur einmal am Anfang die benötigten Informationen abfragen. In folgenden Calls werden diese Informationen bereits in den Objektinstanzen vorgehalten. Die Architektur ist simpel - ich muss die Informationen immer nur da einbinden, wo ich sie wirklich brauche. Wenn ich irgendwann das State-Modell meiner Applikation anpassen will, kann ich ggf. sogar Teile der Anwendung noch auf einem alten Modell weiterlaufen lassen und baue dann - wenn notwendig - Wrapper-Klassen, die mit das alte State-Modell in ein neues übersetzen.
    Standards - Best Practices - AwesomePHP - Guideline für WebApps

    Kommentar


    • #62
      Hey

      rkr

      erkläre mir mal den unterschied zwischen folgenden zwei codebeispielen.


      public Result x(configurationsDataStruct, parameter);

      und

      tmp=new XProcessor(configurationsDataStruct);
      tmp.proccess(parameter);
      //destruct tmp


      beide Codebeispiele machen dassselbe.

      nur dass bei zweiterem unnötigerweise, der heap-speicher beansprucht wird (ok kommt auf CompilerOptimierung und programmiersprache an, aber das ist jetzt nicht weiter relevant)

      Ein zweiteres Problem sehe ich bei Zweiterem:
      ich möchte diesen configurationsDataStruct-Kontext bei jedem Call geändert haben. Sprich ich muss für jeden call ein new..... Aufruf machen.

      Ich bin also bei ersterem weitaus ressourcen-schonender UND flexibler!

      Warum also pseudo-OO dem klassischen PP vorziehen?
      Der Punkt mit dem DI, wird bei Zweiterem einfacher zu realisieren sein, wobei es auch für ersteren Code Techniken gibt, in bestimmten Kontexten die Konfiguration dynamisch zu injecten.


      Mit DI ist das recht simpel. Du hast eine Klasse, die in ihrem Konstruktor andere Klassen erwartet. Die Objekte, die Methoden dieses Klassenobjekts aufrufen, wissen nicht, welche Hilfsmittel dieses Objekt benötigt, um seine Aufgabe zu erfüllen.
      Was übernimmt das DI für dich?
      Also User-Session-State wird bei dir injected (wobei das auch nur in PHP sinn macht, nicht bei Anwendungen, die länger laufen)
      Sicher auch andere Service-Klassen/KonfigurationsDaten (das wird vermutlich in vielen Programmiersprachen so gemacht)
      Injectest du sonst noch was?

      Ich gehe davon aus, dass du keine Domainenobjekte an sich injectest
      //ich trenne hier jetzt den Begriff Domaine von der Service-Domaine


      Also ist DI/Service-Klassen an sich ein Indiz dessen, das PP (bzw. pseudo-OO) programmiert wird und nicht OO
      Das ist jetzt kein Kritikpunkt, ich finde PP eh viel besser, aber wie bereits geschrieben, sollten eben auch Leute, die von sich behaupten "anscheinend" OO zu programmieren - sollten sie übermäßigen Gebrauch von Service-klassen/DI machen -, zugeben, dass sie PP programmieren und das auch gut heissen^^



      JaMa


      Eine Session ist nach der Abarbeitung eines Request nicht automatisch weg.
      Darum gehts hier auch nicht.
      Die Session wird in PHP bei jedem Request erneut injected. Sie war also im Sinne des Programmkontextes weg^^


      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.
      Ich würde sagen, ein Code, der kein DI/Service-Klassen enhält ist schonmal auf gutem wege zu OO


      sprich du hasst Klassen und Beziehungen untereinander dieser Klassen.

      Diese Klassen repräsentieren domainenspezfische Dinge und haben ihrer Domaine zu Folge ensprechendes Verhalten.

      BSP Mensch:

      class Hand, Fuß, Bauch, Magen, Lunge, MenschZusammenHalter, Kopf


      die Hand kann bestimmte Dinge tun, der Magen andere usw.

      Auch hier habe ich jetzt einen Art Service, der das ganze koordiniert, wie z.B den Kopf.
      Der Kopf ist aber fest im Menschen integriert und Teil von diesem.
      Hier wird kein DI oder sonstiges benötigt.


      Was ist aber das Problem von dem Ganzen: Es ist sehr unflexibel, da alles "fest"-verdrahtet ist.

      bei PP kann ich schön zur Laufzeit, den Algorithmus beeinflussen.

      Möchte ich bei PP eine veränderte Algorithmusausführung sehen, dann calle ich statt foo(1) einfach foo(2)
      Bei OO ist aber die 1 bzw. 2 bereits via Membervariable fix festgelegt: tmp=new ProcessObject(1); tmp->foo();

      möchte ich da jetzt eine Veränderung sehen muss ich entweder ein neues new..... machen oder tmp->Change(2); tmp->foo()
      Beides scheint mir sehr unsinnig zu sein.
      Oder wie seht ihr das?




      lg knotenpunkt

      Kommentar


      • #63
        Die Session wird in PHP bei jedem Request erneut injected. Sie war also im Sinne des Programmkontextes weg
        In PHP gibt es keinen richtigen Programmkontext. Da muss alles bei jedem Request neu aufgebaut werden (Caches außenvorgelassen).

        Und wie soll das Hirn z.b. die Hände steuern ohne diese zu kennen? Soll das Hirn selber Hände erzeugen? Nein. Also gibst du dem Hirn die Hände mit. Oder noch besser du hast einen Service der die Methode "hebeAn" hat und entsprechend die Kommunikation zwischen Hirn und gegebener Hand steuert. Damit hast du dann auch eine Separation of Concerns.

        Wie du das ganze verständlicher mit prozeduraler Programmierung realisieren würdest, würde mich doch interessieren. Ich sehe da nur Potential für eine Menge unverständlichen Spaghetti-Code.


        bei PP kann ich schön zur Laufzeit, den Algorithmus beeinflussen.

        Möchte ich bei PP eine veränderte Algorithmusausführung sehen, dann calle ich statt foo(1) einfach foo(2)
        Bei OO ist aber die 1 bzw. 2 bereits via Membervariable fix festgelegt: tmp=new ProcessObject(1); tmp->foo();
        Wenn der Wert direkt bei der Erzeugung angegeben hast (Konstruktor), dann ist das normalerweise ein Wert den das Objekt unbedingt braucht um zu funktionieren.
        Eventuell lässt sich das im Nachhinein noch über Setter steuern, wobei eher der Fall ist, dass du mit dem falschen Objekt dann arbeitest.

        EDIT:
        MenschZusammenHalter
        Das ganze wäre ja ein Service
        "Software is like Sex, it's best if it's free." - Linus Torvalds

        Kommentar


        • #64
          knotenpunkt Da du gerade eindrucksvoll gezeigt hast, dass deine OOP-Kenntnisse praktisch bei Null liegen, ist für meinen Teil hier Ende.
          Das, was du da beschreibst, wirkt auf mich wie eine realitätsaverse Form von sklavischem Glauben an die Überlegenheit von prozeduraler Programmierung gegenüber allem anderen. Oder irgendeine Form von Lernschwäche.
          Sorry, aber das ist extrem niedriges Niveau...
          Standards - Best Practices - AwesomePHP - Guideline für WebApps

          Kommentar


          • #65
            Hey,

            rkr

            Hier habe etwas für dich: https://www.gutefrage.net/frage/sind...eleidigen-dumm

            Nichts desto Trotz: Du programmierst selbst offensichtlich PP, da du Services verwendest: pseudo-OO. Du programmierst definitiv kein richtiges OO.

            Aber um deine Ehre zu retten, kannst du uns ja aufzeigen, was konkret bei deinem Programmierstil das OO auf Geschäftsebene ausmacht.

            Damit meine ich nicht die Fernsteuerung (Service), die weitestgehend den Menschen (Domaine) bedient, sondern viel mehr ob Mensch (Domaine) für sich alleine stehen könnte.


            JaMa

            Wenn der Wert direkt bei der Erzeugung angegeben hast (Konstruktor), dann ist das normalerweise ein Wert den das Objekt unbedingt braucht um zu funktionieren.
            Eventuell lässt sich das im Nachhinein noch über Setter steuern, wobei eher der Fall ist, dass du mit dem falschen Objekt dann arbeitest.
            Ja du bindest dich an einen festen State, damit gibts du Flexibilität zu Gunsten von Testbarkeit auf.


            Das ganze wäre ja ein Service
            Selbst wenn hier die gesamte Logik implementiert wäre, würde dies kein Service im allgemeinen Sinne darstellen.
            Der MenschZusammenhalter ist ein Objekt das fest definiert einem Menschen zugeordnet ist.

            Die Services von rkr arbeiten dagegen mit verschiedenen Domainenobjekten, die der Service eben bekommt. Genauso arbeiten ja auch Prozeduren, nur dass sie nicht via THIS-Zeiger konfiguiert sind^^


            lg knotenpunkt

            Kommentar


            • #66
              Kannst du mal ein Codebeispiel für dein richtiges OO liefern? Also ein echtes, bei dem man auch etwas sieht und nicht nur 7 Zeilen Pseudocode.
              Relax, you're doing fine.
              RTFM | php.de Wissenssammlung | Datenbankindizes | Stay fit

              Kommentar


              • #67
                knotenpunkt Ich habe sogar versucht, objektiv zu sein.
                Du bist kein geeigneter Gesprächspartner, weil du von dem Thema einfach keine Ahnung hast. Kauf dir ein anständiges Buch und schreibe eigene Applikationen um deinen Horizont zu erweitern.
                Standards - Best Practices - AwesomePHP - Guideline für WebApps

                Kommentar


                • #68
                  Zitat von VPh Beitrag anzeigen
                  Kannst du mal ein Codebeispiel für dein richtiges OO liefern? Also ein echtes, bei dem man auch etwas sieht und nicht nur 7 Zeilen Pseudocode.
                  Ist das immer noch nicht angekommen? Sein Definition von OOP ist, Daten und Funktionalität sind gekappselt. Bei "Pseudo OOP" sind Daten und Funktionaltät getrennt. Alles andere spielt keine Rolle.

                  Kommentar


                  • #69
                    Ja du bindest dich an einen festen State, damit gibts du Flexibilität zu Gunsten von Testbarkeit auf.
                    Hey! Du erkennst langsam den Nutzen von DI.

                    Selbst wenn hier die gesamte Logik implementiert wäre, würde dies kein Service im allgemeinen Sinne darstellen.
                    Der MenschZusammenhalter ist ein Objekt das fest definiert einem Menschen zugeordnet ist.
                    Ja und wenn ich jetzt einen PaymentService habe, dann ist der fest den Payments zugeordnet. Merkste was?

                    Zitat von knotenpunkt Beitrag anzeigen
                    Genauso arbeiten ja auch Prozeduren, nur dass sie nicht via THIS-Zeiger konfiguiert sind^^
                    Jesses. Die Aussage ist nicht dein Ernst?

                    Aber um deine Ehre zu retten, kannst du uns ja aufzeigen, was konkret bei deinem Programmierstil das OO auf Geschäftsebene ausmacht.
                    Für Ru(h)m und Ehre!
                    "Software is like Sex, it's best if it's free." - Linus Torvalds

                    Kommentar


                    • #70
                      Zitat von erc Beitrag anzeigen

                      Ist das immer noch nicht angekommen? Sein Definition von OOP ist, Daten und Funktionalität sind gekappselt. Bei "Pseudo OOP" sind Daten und Funktionaltät getrennt. Alles andere spielt keine Rolle.
                      Ich würde es gerne sehen.
                      Relax, you're doing fine.
                      RTFM | php.de Wissenssammlung | Datenbankindizes | Stay fit

                      Kommentar


                      • #71
                        Hey

                        erc


                        Ist das immer noch nicht angekommen? Sein Definition von OOP ist, Daten und Funktionalität sind gekappselt. Bei "Pseudo OOP" sind Daten und Funktionaltät getrennt. Alles andere spielt keine Rolle.
                        OO ist erst dann OO wenn alle Kriterien eingehalten sind!

                        Würdest du selbst sagen eine Anwendung ist objektorientiert, wenn Sie polymorphie, anderes Zeugs etc pp enthält,........... ABER Behaviour und Daten getrennt sind?

                        JaMa

                        Ja und wenn ich jetzt einen PaymentService habe, dann ist der fest den Payments zugeordnet. Merkste was?
                        Sind Sie das?
                        Also ich meine: verkabelst du du den PaymentService mit den Payments irgendwo fest im Code, bzw. lässt sie verkabeln durch DI?

                        oder machst du es doch eher so: PaymentService->getPaymentInfo(PAYMENT_ID);




                        lg knotenpunkt




                        Kommentar


                        • #72
                          https://martinfowler.com/articles/injection.html
                          Standards - Best Practices - AwesomePHP - Guideline für WebApps

                          Kommentar


                          • #73
                            Das wird ja immer wirrer...

                            Wieso darf man nicht von OO sprechen, sondern von "Pseudo-OO", wenn statt Deiner Entities auch Logik gekapselt wird?

                            Dann kommst Du mit fadenscheinigen Gründen wie der Belegung von Heap-Speicher, wobei das Beispiel noch nicht mal durchdacht ist. Du hast offensichtlich auch den Sinn von DI nicht verstanden. Und auch nicht, warum Du damit sehr flexibel sein kannst.

                            Also ich meine: verkabelst du du den PaymentService mit den Payments irgendwo fest im Code, bzw. lässt sie verkabeln durch DI?
                            Was ist denn das für ein Käse?

                            PaymentService->getPaymentInfo(PAYMENT_ID);
                            Ja, so macht man das in der Regel.

                            Kommentar


                            • #74
                              hey,

                              xm22

                              Wieso darf man nicht von OO sprechen, sondern von "Pseudo-OO", wenn statt Deiner Entities auch Logik gekapselt wird?
                              Dieser Satz enthält zu wenige Informationen. So würde ich nichtmal von pseudo-oo sprechen, sondern von fast reiner PP



                              Was ist denn das für ein Käse?
                              Die Frage darfst du an JaMa weiterleiten. Ich habe seinen Gedanken nur in eigenen und anschaulichen Worten umschrieben.

                              Ja, so macht man das in der Regel.
                              ja das ist PP bzw. pseudo-OO, falls der Paymentservice noch in irgendeiner Hinsicht etwas konfiguiert sein sollte


                              lg knotenpunkt



                              Kommentar


                              • #75
                                Zitat von knotenpunkt Beitrag anzeigen
                                ja das ist PP bzw. pseudo-OO, falls der Paymentservice noch in irgendeiner Hinsicht etwas konfiguiert sein sollte
                                Dann zeig doch mal richtiges OO. Du schwafelst ständig nur rum, aber Taten gibt es keine von dir. Als Entwickler liest man lieber Code statt seitenlanges esoterisches Rumgeschwafel. Lass doch Code für dich sprechen.

                                Kommentar

                                Lädt...
                                X