Ankündigung

Einklappen
Keine Ankündigung bisher.

Goto in PHP6

Einklappen

Neue Werbung 2019

Einklappen
Dieses Thema ist geschlossen.
X
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #46
    Zitat von Manko10 Beitrag anzeigen
    ...würde eher Property-Deklarationen wie in C# begrüßen. Neben der einfachen Deklaration, wie man es sonst auch gewohnt ist, gibt es noch dieses:
    Code:
    private double _myProperty;
    public double myProperty {
        get {
            return _myProperty;
        } set {
            _myProperty = value;
        }
    }
    Ich sehe hierbei keinen Vorteil gegenüber folgendem:
    PHP-Code:
    private _myProperty;

    public function 
    setProperty($value)
    {
        
    $this->_myProperty $value;
    }

    public function 
    getProperty()
    {
        return 
    $this->_myProperty;

    Zitat von Manko10 Beitrag anzeigen
    So besitzt man Getter und Setter, muss sich aber nicht mit der Verwirrung von Lazy-Initialisation abgeben.
    Welche Verwirrung? Jetzt bin eher ich verwirrt.

    Die C#-Methode finde ich recht hässlich, weil sie nicht API-sicher. Meiner Ansicht nach, dienen Eigenschaften ausschließlich zur internen Datenspeicherung, während Methoden den Zustand der Klasse manipulieren. Deshalb sind meine Methoden öffentlich, Interfaces eben, während die Eigenschaften meiner Klasse entweder private oder höchstens protected sind.

    EDIT: Klassen kappseln Eigenschaften. Nach außen sollen diese Eigenschaften geheim bleiben, weil diese sich schnell mal ändern können. Schnittstellen ändern sich weniger häufig bzw. sollten sich nicht ändern, von daher sind keine Eigenschaften öffentlich, da ich so beliebig intern refactoren kann und mich einfach nur an die Schnittstelle halten muss.

    Kommentar


    • #47
      Zitat von Quadaptor-new Beitrag anzeigen
      Ich sehe hierbei keinen Vorteil gegenüber folgendem:
      PHP-Code:
      private _myProperty;

      public function 
      setProperty($value)
      {
          
      $this->_myProperty $value;
      }

      public function 
      getProperty()
      {
          return 
      $this->_myProperty;

      Intern bietet es keinen Vorteil. Von außen aber kann man direkt auf Eigenschaften zugreifen, ohne auf die Vorteile eines Getters oder Setters verzichten zu müssen. Es ist auch möglich, durch Weglassen eines Zweiges ReadOnly- oder WriteOnly-Attribute zu erstellen.
      Ob man es für sauber hält und gern einsetzt oder nicht, muss dann jeder für sich entscheiden.
      Ich denke, für einige generelle Konfigurationen wäre es durchaus sinnvoll.
      Ich meinte das jetzt nicht so, dass man allgemein alle Attribute public macht, was ja wirklich etwas ...ähh... seltsam wäre. Eher so, dass man wichtige Eigenschaften, für die man bisher gezielt Getter- und Setter-Methoden eingesetzt hat, so verpacken könnte. So z.B. Konfigurationsvariablen für Datenbank-Klassen.
      Alles andere, von dem der Client eh nichts Direktes mitbekommt, sollte weiterhin private sein.
      Das Argument mit Interfaces ist aber natürlich schlagkräftig.

      Zitat von Quadaptor-new Beitrag anzeigen
      Welche Verwirrung? Jetzt bin eher ich verwirrt.
      Mit Verwirrung meine ich die Unübersichtlichkeit, die durch die alleinige Verwendung dieser Inzeptor-Methoden entsteht. Immerhin ist es schlecht zu dokumentieren, was alles durch __get(), __set() und __call() implementiert wird und was nicht implementiert sein soll (wurde bereits in diesem Thread diskutiert).
      Refining Linux: “[url=http://www.refining-linux.org/archives/65/Performing-push-backups-Part-1-rdiff-backup/]Performing Push Backups – Part 1: rdiff-backup[/url]”

      Kommentar


      • #48
        Zitat von Manko10 Beitrag anzeigen
        Natürlich, der Hauptnutzen besteht darin, dass man einfach faul ist, klar.
        Ja, aber verwechsel doch Faulheit nicht mit Komfort. Warum soll ich fuer eine Eigenschaft jeweils zwingend eine Setter- und eine Getter-Methode schreiben (oder eine dritte um __isset zu ersetzen), um die gleiche Flexibilitaet wie mit __set/__get zu erreichen? Vielleicht weiss ich noch garnicht, ob ich beim Setzen oder Laden der Eigenschaft mehr Logik benoetige.

        Beispielsweise mussten die Kreditkartendaten in der Datenbank verschluesselt werden. Ich habe dazu einfach die setter/getter Methode der Billing-Klasse erweitert, so dass Werte beim Setzen automatisch mit Mcrypt verschluesselt werden und beim Lesen automatisch wieder entschluesselt. Das Programm musste sonst nirgends geaendert werden. Das war ein Ding von 15 Minuten.

        Natuerlich waere das gleiche auch mit expliziten Setter/Getter Methoden moeglich gewesen, aber wie gesagt, dann muessen sie auch fuer jede Eigenschaft angelegt werden um gleichaufzuziehen.
        "[URL="http://www.youtube.com/watch?v=yMAa_t9k2VA&feature=youtu.be&t=25s"]Mein Name ist Lohse, ich kaufe hier ein.[/URL]"

        Kommentar


        • #49
          Zitat von Chriz Beitrag anzeigen
          Ja, aber verwechsel doch Faulheit nicht mit Komfort.
          Welchen Komfort bietet denn __*? Schreibst du getter-/setter-Mehoden etwa selbst? Dann mein Beileid... Außerdem: Wie geht deine IDE damit um? Autovervollständigung? Pustekuchen... Wo ist nun der Komfort?

          Zitat von Chriz Beitrag anzeigen
          Warum soll ich fuer eine Eigenschaft jeweils zwingend eine Setter- und eine Getter-Methode schreiben (oder eine dritte um __isset zu ersetzen), um die gleiche Flexibilitaet wie mit __set/__get zu erreichen?
          Wofür isset? Du hast Schnittstellen...

          Zitat von Chriz Beitrag anzeigen
          Vielleicht weiss ich noch garnicht, ob ich beim Setzen oder Laden der Eigenschaft mehr Logik benoetige.

          Beispielsweise mussten die Kreditkartendaten in der Datenbank verschluesselt werden. Ich habe dazu einfach die setter/getter Methode der Billing-Klasse erweitert, so dass Werte beim Setzen automatisch mit Mcrypt verschluesselt werden und beim Lesen automatisch wieder entschluesselt. Das Programm musste sonst nirgends geaendert werden. Das war ein Ding von 15 Minuten.
          Geil, wenn du 20 Eigenschaften hast, die neue Logiken bekommen sollen, dann machst du einen Switch auf 20 Eigenschaften? Oder leitest du einfach mal alle Eigenschaften auf __call-Methoden um? Gibts Whitelisten? Über testbare Software musst du noch viel lernen.

          Zitat von Chriz Beitrag anzeigen
          Natuerlich waere das gleiche auch mit expliziten Setter/Getter Methoden moeglich gewesen, aber wie gesagt, dann muessen sie auch fuer jede Eigenschaft angelegt werden um gleichaufzuziehen.
          Stimmt, aber ohne die ganzen Nachteile von __*.

          Verwendest du eigentlich jemals Interfaces?

          Kommentar


          • #50
            Wenn du andere beleidigst, wird deine Argumentation auch nicht besser.

            Nein ich schreibe setter/getter nicht selbst, da ich wie gesagt keine setter/getter verwende. Das laesst sich in den Templates des Code-Generators allerdings umstellen, um auch deine naechste Frage zu beantworten.

            Die Auto-Vervollstaendigung fehlt natuerlich in der IDE, was ein klarer Nachteil ist. Deshalb koennte man ja daruber nachdenken, Documentator-Auszeichnungen oder virtuelle Deklarationen einzufuehren.

            Wofür isset? Du hast Schnittstellen...
            Was meinst du? (wenn du wieder persoenlich wirst, mach ich den Thread zu, keinen Bock auf sowas)


            Geil, wenn du 20 Eigenschaften hast, die neue Logiken bekommen sollen, dann machst du einen Switch auf 20 Eigenschaften? Oder leitest du einfach mal alle Eigenschaften auf __call-Methoden um? Gibts Whitelisten? Über testbare Software musst du noch viel lernen.
            Soll ich mir stattdessen 40 Setter/Getter generieren lassen, obwohl nur 2-4 mehr als Lese/Schreib-Logik benoetigen? Ich teste bei __set/__get ob es eine protected Set#Property#/Get#Property# Methoden gibt und rufe diese dann auf. Interfaces benutze ich auch wenn sie Sinn machen.


            So und jetzt kannst du das letzte Wort haben.
            "[URL="http://www.youtube.com/watch?v=yMAa_t9k2VA&feature=youtu.be&t=25s"]Mein Name ist Lohse, ich kaufe hier ein.[/URL]"

            Kommentar


            • #51
              Wie würdest du dir diese virtuellen Doc-Tags vorstellen? Denn immerhin gibt es schon ein Haufen von Tags und diese müssten dann allesamt auf die gemeinte Eigenschaft assoziert werden. Das würde auch einen zieemlich langen Doc-Comment geben. Trägt dann auch nicht so zur Übersichtlichkeit bei.

              Einen langen Doc-Block bei Änderungen zu aktualisieren ist wahrscheinlich auch kein Vergnügen und ist dann für falsche Vervollständigungen verantwortlich.

              isset() benötigst du eigentlich niemals, sofern du eine festdefinierte Schnittstelle hast. Dann weißt du nämlich, dass es die Eigenschaft bzw. die Methode gibt.

              Ja genau, dann hätte man in dem genannten Falle wirklich 40 Methoden. Sinnvollerweise (je nach Kontext) per Interface definiert - inkl. der jeweiligen Rückgabewerte und möglichen Ausnahmen, was wiederrum per Unittest dauerhaft sichergestellt werden kann.

              Verwendest du Eigenschaften anstatt Methoden läufst du außerdem noch Gefahr, dass ein internes Refactoring deutlich schwerer durchführbar ist, denn a) kannst du nicht weiterhin auf deine Unittests setzen und b) dürften sich die Namen der Eigenschaften nicht ändern, was aber durchaus mal notwendig sein kann - man weiß nie, was für neue Strukturen notwendig sind. Verwendest du Methoden hast du zwei Sicherheiten: Interfaces und Unittests, die beide bei einem Refactoring unverändert bleiben (müssen), um auch wirklich sicherzustellen, dass hinterher alles genaus funktioniert, wie vorher.

              Kommentar


              • #52
                Ich glaube, das Thema hat nur noch bedingt etwas mit Goto in PHP 6 zu tun (beides gehört in den Bereich Programmierung. ).
                Vielleicht sollte man dazu einen neuen Thread aufmachen.
                Wenn man versucht, den Thread objektiv zu betrachten, so stellt man fest, dass sich jetzt alle Beteiligten (mich eingeschlossen) gegenseitig nur noch an der Frage aufhetzen, was einer objektorientierten, wartbaren, wiederverwendbaren und erweiterbaren Systemarchitektur am ehesten nahe kommt.
                Aber mal ehrlich: gibt es für solche Sachen nicht UML? Wenn man vor dem Losprogrammieren das gesamte System durchmodelliert (einschließlich Klassen und Interfaces), so wird man doch wohl in den allermeisten Fällen merken, welche Methodik nun am besten zum Einsatz kommt und welche gleich ausscheidet.

                Ich würde mal sagen, das Thema gleitet langsam in die Bereiche ab, in denen man sich eh nie einigen wird. Programmierer sind nunmal ein zerstrittenes Volk, das erst in einem gemeinsamen Projekt (zumindest zeitweilig) geeint werden kann.
                Refining Linux: “[url=http://www.refining-linux.org/archives/65/Performing-push-backups-Part-1-rdiff-backup/]Performing Push Backups – Part 1: rdiff-backup[/url]”

                Kommentar


                • #53
                  Stimmt, UML und Magic Methods ist kaum zu vereinbaren. Ich kenn zumindest kein UML-Tool das irgendwelche Magic-Sachen unterstüzt, geschweige denn auch Magic-Code erzeugt.

                  Kommentar


                  • #54
                    Ob ein UML-Tool das unterstützt, ist weniger relevant.
                    Wichtiger ist, dass die UML-Spezifikation das Magic-Gedöns unterstützen muss.
                    Ich denke, dass eine Magic Method letztendlich als ganz normale Methode modelliert würde (evtl. mit Kommentaren versehen). Ob sie ihren Zweck erfüllt oder ob es nicht vielleicht auch auf andere Weise ginge, wird man dann sehen.
                    Refining Linux: “[url=http://www.refining-linux.org/archives/65/Performing-push-backups-Part-1-rdiff-backup/]Performing Push Backups – Part 1: rdiff-backup[/url]”

                    Kommentar


                    • #55
                      Zitat von Manko10 Beitrag anzeigen
                      Ob ein UML-Tool das unterstützt, ist weniger relevant.
                      Wichtiger ist, dass die UML-Spezifikation das Magic-Gedöns unterstützen muss.
                      Ich denke, dass eine Magic Method letztendlich als ganz normale Methode modelliert würde (evtl. mit Kommentaren versehen). Ob sie ihren Zweck erfüllt oder ob es nicht vielleicht auch auf andere Weise ginge, wird man dann sehen.
                      Ich denke und hoffe, dass es niemals so weit kommen wird, da aus genannten Gründen, Magic Methods die API verhunzen.

                      Mit einem ordentlichen Schnittstellendesign steht und fällt eine Applikation, das *sollte eigentlich* jedem bewusst sein.

                      Kommentar


                      • #56
                        Super, dann bist du ja zu einem Punkt gekommen, ich gebe dir einen Keks und wir alle wissen, dass wir __get(), __set() und __call() weiterhin nicht verwenden sollten.
                        Nee, im Ernst: modellierbar wäre es, aber sinnvoll wohl nicht.
                        Refining Linux: “[url=http://www.refining-linux.org/archives/65/Performing-push-backups-Part-1-rdiff-backup/]Performing Push Backups – Part 1: rdiff-backup[/url]”

                        Kommentar


                        • #57
                          Amen.
                          "[URL="http://www.youtube.com/watch?v=yMAa_t9k2VA&feature=youtu.be&t=25s"]Mein Name ist Lohse, ich kaufe hier ein.[/URL]"

                          Kommentar

                          Lädt...
                          X