Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Marker-Interfaces

Einklappen

Neue Werbung 2019

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

  • [Erledigt] Marker-Interfaces

    Zitat von tr0y
    Es gibt außerdem noch eine (un-)art von Interfaces ( was aber nicht bedeutet das sie worst practice sind ): Marker-Interfaces; die definieren genau 0 Methoden und 0 Konstanten.
    Hallo, beim lesen der beiträge bin ich über das oben gepostete Zitat gestolpert.
    Hab mal gegooglet, was es ist, aber werd nicht ganz schlau daraus.

    Hat jemand eine Erklärung was das ist oder ein sinnvolles Anwendungsbeispiel?
    Wozu Interfaces dienen, weiß ich, aber Marker-Interfaces... sehen mir grad irgendwie wastet aus... O.o

    LG
    Kagu


  • #2
    Zugegeben blödes Beispiel:

    WriteStream und ReadStream können beide vom Stream ableiten, wobei ein Stream dann keine eignenen Methoden haben muss. Das kann dann sinnvoll sein, wenn man in der konsumierenden Klasse mit "instanceof" unterscheiden will, was es ist, als Typehint dann aber beides erlauben will.

    Ich bin mir sicher, dass es auch gute Beispiele gibt
    Standards - Best Practices - AwesomePHP - Guideline für WebApps

    Kommentar


    • #3
      Serializable bei Java ist wohl das bekannteste Beispiel.

      The serialization interface has no methods or fields and serves only to identify the semantics of being serializable.
      Das Interface hat keine Methoden, muss aber zwingend benutzt werden, wenn man Klassen als serialisierbar markieren will. Intern erledigt das dann die JVM unter der Haube. Alles was sie braucht, ist die Markierung.
      Lerne Grundlagen | Schreibe gute Beispiele | PDO > mysqli > mysql | Versuch nicht, das Rad neu zu erfinden | Warum $foo[bar] böse ist | SQL Injections | Hashes sind keine Verschlüsselungen! | Dein E-Mail Regex ist falsch

      Kommentar


      • #4
        Marker-Interfaces:

        Du "markierst" z.B. eine Klasse mit dem Interface Cachable. Dein Cache-Service cached somit alle Objekte, die dieses Interface implementieren. Das Interface schreibt aber ansonsten nix vor, weil das Objekt per se z.B. mit serialize schon gecached werden kann.

        Somit wurde es bloss markiert.

        Kommentar


        • #5
          Ich sage dem programm also nur "theoretisch ist xy möglich" - oder verstehe ich da immer nochwas falsch?

          Kommentar


          • #6
            Ja. Klasse ist vom Typ XY - manche Interfaces haben dann noch magische Fähigkeiten. Du kannst das Prinzip auch benutzen, um Klassen für bestimmte Umgebungen zuzulassen. Das "Controller"-Interface kannst du Klassen geben, die in deiner App als "Controller" auftreten sollen. So kann man in einer Classregistry sagen "hier sollen nur Controller rein" - ohne dabei fest vorzuschreiben, wie Controller genau aussehen müssen.

            Keine Ahnung, ob das eine "Unart" ist...
            Standards - Best Practices - AwesomePHP - Guideline für WebApps

            Kommentar


            • #7
              Nein. Theoretisch ist gar nix möglich. Weil die Klasse nichts kann. Aber du kannst trotzdem anderen Komponenten etwas mitteilen. "Ich würde gerne gecached werden", "Ich würde gerne per ACL geschützt werden" usw.

              Kommentar


              • #8
                Mhm... ich lass mir das ganze nochmal durch den Kopf gehen und melde mich einfach bei weiteren Fragen.

                Danke (:

                Kommentar


                • #9
                  "Ich würde gerne gecached werden", "Ich würde gerne per ACL geschützt werden" usw.
                  Auf den ersten Blick scheint mir diese Aussage falsch zu sein. Ein Objekt sollte nichts wissen dürfen, wozu/wie es genutzt wird, deshalb sollte das Interface etwas über das Objekt aussagen (was es kann), nicht über den Nutzungskontext (wozu es genutzt wird).
                  --

                  „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                  Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                  --

                  Kommentar


                  • #10
                    Das ist natürlich ein Argument... aber ich denke ich hab es soweit verstanden, das ich was mit anfangen kann ^⁻^

                    Kommentar


                    • #11
                      Ein Objekt sollte nichts wissen dürfen, wozu/wie es genutzt wird, deshalb sollte das Interface etwas über das Objekt aussagen (was es kann), nicht über den Nutzungskontext (wozu es genutzt wird).
                      Das wäre in meinen Augen der normale Ansatz eines Interfaces ja. Bei einem MarkerInterface kann das Objekt per se aber nichts. Deshalb ist es nur für den Nutzungskontext interessant.

                      Kommentar


                      • #12
                        Zitat von nikosch Beitrag anzeigen
                        Auf den ersten Blick scheint mir diese Aussage falsch zu sein. Ein Objekt sollte nichts wissen dürfen, wozu/wie es genutzt wird, deshalb sollte das Interface etwas über das Objekt aussagen (was es kann), nicht über den Nutzungskontext (wozu es genutzt wird).
                        Primär eigentlich "was es ist".[/klugshice]
                        Standards - Best Practices - AwesomePHP - Guideline für WebApps

                        Kommentar


                        • #13
                          Ein Beispiel noch: Ein "ProtectedByAclInterface" extended ein "EntityInterface" z.B. (getId() vorgeschrieben)

                          ProtectedByAclInterface = MarkerInterface für Security Komponente: Aha da kommt was, was ich schützen sollte. Rest wird ignoriert.

                          Mein Satz dazu: "Ich würde gerne per ACL geschützt werden".

                          Kommentar


                          • #14
                            Die simpelste aber einleuchtenste Version des Marker Interface ist die Verhaltensbeschreibung.

                            Stell dir Folgendes Szenario vor:

                            PHP-Code:
                            interface Container
                            {
                               public function 
                            __construct(array $items = []);
                               public function 
                            has($item);
                               public function 
                            get($item);
                               public function 
                            set($item$content);
                               public function 
                            remove($item);

                            Ein simples Container Interface das vorgibt das der Container 4 Methoden und einen Constructor haben soll.

                            Nun möchtest du spezifizieren das es Mutable und Immutable Container gibt ( veränderbare und unveränderbare ):
                            PHP-Code:
                            interface ImmutableContainer extends Container {}
                            interface 
                            MutableContainer extends Container {} 
                            Diese Beiden Interfaces fungieren als Marker-Interfaces, da sie das Verhalten des Containers als veränderbar oder unveränderbar beschreiben. Du markierst hier nur den Container statt 2 separate Container-Interfaces aufzubauen bei dem der ImmutableContainer bspw. kein Remove() kennt und kein set(). Beide Container können jederzeit als "Container" identifiziert werden und das sie entsprechende Container-Methoden besitzen. Es ist aber auch möglich festzustellen ob der Container veränderbar oder unveränderbar ist.

                            Auch der PHP-Core nutzt Marker-Interfaces ( sie werden zwar als Interne Interfaces definiert und nicht explizit als solche beschrieben aber es sind reguläre Marker-Interfaces ). Bspw.: [man]Traversable[/man] auch hier wird eine Verhaltensbeschreibung gegeben ohne Methoden zu definieren.
                            [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


                            • #15
                              Wobei ich noch anmerken möchte, dass ein __construct in einem Interface nur gaaaaanz selten was verloren hat, oder?

                              Kommentar

                              Lädt...
                              X