Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] 5

Einklappen

Neue Werbung 2019

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

  • [Erledigt] 5

    Hallo, ich habe eine Frage, die Hints betreffen. Soll ich alle Hints in Methoden, die Klassen erwarten, mit Interfaces austauschen. Ich habe gelesen man soll gegen Interfaces programmieren, aber gilt dies für jede wirkliche Abhängigkeit? Wie macht ihr das?

  • #2
    Grundsätzlich ja.
    [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

    Kommentar


    • #3
      Was ist denn mit dem Thread-Titel passiert?
      [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

      Kommentar


      • #4
        Ich glaub n Exploit, ich hab nix gemacht.

        Kommentar


        • #5
          Type hints in Klassen auf Klassen oder Interfaces sind eine Bindungsentscheidung. Willst du grundsätzlich alles voneinander entkoppeln solltest du Interfaces verwenden, willst du explizit eine Bindung zwischen zwei Klassen schaffen ( und somit bspw. Inheritance erzwingen ) nutze Klassen statt Interfaces als type hint.
          [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

          Kommentar


          • #6
            Bei einem Type-Hint auf eine Klasse bist Du auf eine konkrete Implementierung beschränkt.

            Wenn Du diese Implementierung z.B. ändern/austauschen möchtest, dann bleibt Dir nichts anderes übrig als die Klasse umzuschreiben oder mit einer abgeleiteten Klasse zu arbeiten. Ersteres ist unschön, vielleicht auch nicht erwünscht oder gar nicht erst möglich, Letzteres ist nicht empfehlenswert, weil Vererbung schlicht nicht der richtige Mechanismus dafür ist (Stichwort: Spezialisierung).

            Bei einem Interface legst Du Dich nur auf eine Vereinbarung (Contract) fest. Die Komponente kann problemlos jede Klasse verwenden die diese Vereinbarung erfüllt. Die Vorteile liegen auf der Hand: eine geringere Kopplung (die Kopplung an eine Klasse ist stärker als an ein Interface) und eine problemlose Austauschbarkeit von Modulen/Komponenten (auch zur Laufzeit).

            Die Nutzung von Klassen als Type-Hints gegenüber Interfaces hat somit einige Nachteile und offensichtlich keinerlei Vorteile. Deshalb sind Interfaces als Type-Hint Klassen grundsätzlich vorzuziehen.

            vg
            jack
            -

            Kommentar


            • #7
              Grundsätzlich schon mal nicht, es kommt auf den konkreten Fall an ob und wann class hints möglich sind und wann interfaces vorzuziehen sind. Andernfalls wären so ziemlich alle Prozeduralen Methoden von MySQLi "grundsätzlich" falsch implementiert.

              Pauschalisieren kannst du da nicht, jack88.

              Ich sehe das so wie oben beschrieben. Treffe eine Entscheidung wann du enge oder lose Kopplung willst. Wann eine lose Kopplung bei deiner Implementierung nachteile mitbringen würde, hängt von deiner spezifischen Implementierung ab.
              [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

              Kommentar


              • #8
                Hallöchen,

                in der Theorie mag das mit den Interfaces ja ziemlich rosig klingen, in der Praxis ist es ja auch sehr sinnvoll - da bin ich voll und ganz bei jack88. Aber es erhöht einfach die Komplexität und die Schreibarbeit, wenn man für alles und jeden ein Interface braucht. Ich habe Projekte gesehen, da gibt es bspw. für Entities eigene Interfaces, also quasi ein UserInterface, welches in der Klasse User konkret implementiert wurde - doppelte Arbeit, wenn mal eine neue Eigenschaft hinzukommt. Ist zwar schön sauber, nur ist der Fall, dass es jemals eine andere User-Implementierung geben wird, sehr sehr unwahrscheinlich. Das ist natürlich nur ein Beispiel und auch nicht allgemein gültig.

                Ich persönlich wäge daher von Fall zu Fall ab. In kleinen Kundenprojekten verzichte ich an manchen Stellen darauf und nutze Interfaces nur für Services und ähnliche Dinge die Prozesse abbilden. Entities hingegen verwende ich ganz unkompliziert direkt über die jeweiligen Klassen.

                Ich würde mir also nicht einfach pauschal alles mit Interfaces zuballern, sondern mir genaue Gedanken darüber machen, welche Komponenten denn tatsächlich Potential für Austauschbarkeit haben (sollten).

                Viele Grüße,
                lotti
                [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                Kommentar


                • #9
                  Als Anhang zu lottikarotti:

                  Und wenn dann eine eigene Implementierung von User kommt so kann man die Basisklasse erweitern und bekommt trotzdem keinen TypeError .
                  [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

                  Kommentar


                  • #10
                    Grundsätzlich schon mal nicht, es kommt auf den konkreten Fall an ob und wann class hints möglich sind und wann interfaces vorzuziehen sind. Andernfalls wären so ziemlich alle Prozeduralen Methoden von MySQLi "grundsätzlich" falsch implementiert.
                    Es sagte niemand etwas von richtig oder falsch. Es geht vielmehr um eine Empfehlung welche Arbeitsweise sinnvoller ist und warum.

                    Prozeduralen code wie die mysqli-funktionen halte ich in diesem Zusammenhang ehrlich gesagt für kein gutes Beispiel.

                    Man könnte sich aber auch hier die Frage stellen: Welchen Vorteil hat es, wenn die mysql-Funktionen in Ihrer Signatur mysqli anstatt mysqliInterface verwenden? Ist die explizite Bindung an eine konkrete Klasse ein Vorteil gegenüber einer Bindung an ein Interface? Allerdings würde man in diesem sehr speziellen Fall, also bei prozeduralen Funktionen die alle auch noch mit dem Präfix mysqli_ beginnen, ohnehin nichts anderes erwarten.

                    Es mag genug Beispiele geben wo sich das Type-Hinting gegen eine Klasse noch nie negativ bemerkbar gemacht hat, aber das ändert nichts an der Tatsache, daß das Type-Hinting gegen ein Interface die Komponenten von der konkreten Implementierung entkoppelt und das ist nun mal eine gute Sache. Vielleicht sollte man das zumindest im Hinterkopf behalten.

                    Aber es erhöht einfach die Komplexität und die Schreibarbeit, wenn man für alles und jeden ein Interface braucht.
                    Das Argument könnte sich auch schnell ins Gegenteil umkehren, wenn man z.B. in einem größeren Projekt bestimmte Klassen – vielleicht nur probeweise – austauschen will/muss.

                    Mal angenommen, jede Klasse hätte per default auch ein entsprechendes Interface (vielleicht grundsätzlich keine so schlechte Idee ). Würde dann noch jemand in Methodensignaturen die Klasse verwenden?

                    vg
                    jack
                    -

                    Kommentar


                    • #11
                      Dei Frage ist doch, ob es potentiell mehrere Implementierungen gibt oder nicht. Und solange dies nicht der Fall ist, ist ein Interface nicht wirklich gerechtfertigt. Wieso sollte ich jede Klasse auch als Interface haben, wenn ich mir (ziemlich) sicher bin, dass es die einzige Implementierung bleibt? Ich kann mir da viele Anwendungen vorstellen, wo dies nur zusätzliche Arbeit für nix bedeutet.

                      Klar, mit den heutigen IDE lässt sich ein Interface aus einer Klasse generieren (meinte in IntelliJ geht das sicher, ob's in phpStorm auch geht wüsste ich gerade nicht). Und auch neue Methoden lassen sich leicht ins Interface übertragen. Das ist aber gerade bei simplen "Datenhaltungsklassen" wie Entitäten absolut over-engineered.

                      Und wenn es dann wirklich einmal sein muss - extends löst das Problem für einen Test (!) auch.
                      [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

                      Kommentar


                      • #12
                        wenn ich mir (ziemlich) sicher bin, dass es die einzige Implementierung bleibt?
                        Ziemlich sicher bedeutet für mich, daß Du dir nicht ganz sicher bist. Wenn Du dir allerdings ABSOLUT sicher bist, dann brauchst Du tatsächlich kein Interface.

                        Ich stelle die Frage nochmal:

                        Wenn jede Klasse "per default" ein entsprechendes Interface hätte, würdest Du die Klasse oder das Interface als Type-Hint verwenden?

                        vg
                        jack
                        -

                        Kommentar


                        • #13
                          Lol, nicht vergessern, wir sind hier bei Einsteiger .

                          Kommentar


                          • #14
                            Deine Threads fallen ohnehin eigentlich hierunter:

                            - http://www.php.de/php-einsteiger/675...sumfragen.html

                            Du forderst einerseits Pauschalantworten, die es einfach nicht gibt (sonst hätte es keinen Sinn, überhaupt die beiden Alternativen zuzulassen), fragst aber dann nach der subjektiven Vorgehensweise, was natürlich zu einer Diskussion führt. Da du überhaupt keinen Kontext lieferst, wird die Diskussion eben entsprechend abstrakt oder schafft sich ihre eigenen Bezüge.

                            Kommentar


                            • #15
                              Danke für den Tipp, werd ich nächstes mal machen.

                              Kommentar

                              Lädt...
                              X