Ankündigung

Einklappen
Keine Ankündigung bisher.

public, protected, private Funktionen

Einklappen

Neue Werbung 2019

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

  • public, protected, private Funktionen

    Vielleicht kann mir jemand von euch weiter helfen.

    Ich schaue mir derzeit viel anderen Code an und versuche stilistisch und technisch die Idee hinter den jeweiligen Skripten zu durchschauen. Nun ist mir aufgefallen, dass oft
    @access {public|protected|private}
    vor den Funktionen notiert wird. Dabei werden oft (nicht immer!) die Funktionen mit einem Prefix eingeleitet. Ohne für "public", _ für "protected" und __ für "private".

    Also also Beispiel
    Code:
    /** 
     * [...]
     *@access private
     */
    function __doSomething() {}
    In PHP5 könnte man ja gleich schreiben
    Code:
    private function __doSomething() {}
    Ich nehme an, dass man das aufgrund der Abwärtskompatibilität zu PHP4 das nicht macht. Was ich allerdings nicht verstehe, wie man darauf kommt die Funktion als private zu deklarieren. Sollte ein __ mich daran hindern von "außen" zuzugreifen? Wird dieses _, __ also an igendeiner Stelle geprüft oder ist das lediglich ein Hinweis? Also konkret: Warum wird die Funktion als private deklariert, wenn man theoretisch doch darauf zugreifen kann? Oder soll das zunächst nur ein Hinweis sein, dass man es nicht macht, wenn man ggf. als Team entwickelt?

  • #2
    Ich nehme an, dass man das aufgrund der Abwärtskompatibilität zu PHP4 das nicht macht.
    genau. is nur ne notiz für später...
    [B]PHP4?!?[/B]>>>[B]Aktuelle[/B] PHP Version: [B]5.2.11 || 5.3.0
    [URL="http://en.opensuse.org/Factory/News"]Suse 11.2 *vorfreude*[/URL]
    [/B]

    Kommentar


    • #3
      Ähm ... Nene, so is das nicht ganz korrekt. Die @-Notation ist für PHPDoc, wird zum Beispiel von PHPDocumentor ausgewertet. Das sieht man auch schon daran, dass hinter dem einleitenden Multi-Comment-Tag /* gleich noch ein Stern folgt und sowieso jede Zeile mit einem Stern beginnt. Einmal wird es wie gesagt von PHPDocumentor ausgewertet, Zweitens ist es für geübte Leser einfacher da durchzuschauen (da kann noch wesentlich mehr stehen) und Drittens können diverse Editoren dies auch auswerten, um Hilfestellungen zu Funktionen und Methoden zu geben (PDT auf Eclipse zB).

      Wenn man ernsthaft in PHP5 programmieren will, dann kann man es nicht nur so, wie erwähnt, schreiben, sondern man sollte es auch auf jeden Fall. Auch wenn man davor den DocBlock noch setzt ist es einfach stilistischer besser, weil damit jedem (vorallem dem PHP-Parser) klar ist, was gemeint ist.

      Woran du nu hängen geblieben bist, sind einfach die DocBlocks. Dienen in erster Linie zur Dokumentation, aber können (wie gesagt zB Editoren) auch anderweitig ausgewertet werden. Für den Programmablauf sind sie völlig unerheblich und können (mehr oder weniger) vom Entwickler frei gesetzt werden. Genauso gut könnte er auch @access public setzen und trotzdem vor function ein private. Wär nur nich besonders sinnvoll.

      Übrigens:
      Doppelter Unterstrich bei Funktionsnamen tunlichst vermeiden. Die sind PHP selbst für besondere Funktionen (Siehe Handbuch: Magic Methods) vorbehalten. Üblich ist kein Unterstrich für public, ein Unterstrich für private und protected und zwei Unterstriche für (vordefinierte) Magic-Methods.
      Nicht jeder Fehler ist ein Bug.

      Kommentar


      • #4
        Ja, das mit den magischen Methoden muss man dann wissen, andererseits finde ich das Konzept der Benennung, zumindest wenn PHP 4 noch im Spiel ist, nicht unbedingt schlecht.

        http://de3.php.net/oop5.magic
        The function names __construct, __destruct (see Constructors and Destructors), __call, __get, __set, __isset, __unset (see Overloading), __sleep, __wakeup, __toString, __set_state, __clone and __autoload are magical in PHP classes. You cannot have functions with these names in any of your classes unless you want the magic functionality associated with them.

        Kommentar


        • #5
          Benutze die Bennenung auch für PHP5 weiter, allerdings reicht meines Erachtens ein einfacher Unterstrich für protected und private aus. Oder anders gesagt: Also ohne Unterstrich is offen zugänglich, als mit einfach für "intern".
          Nicht jeder Fehler ist ein Bug.

          Kommentar


          • #6
            Vielen Dank für die ausführliche Darstellung,

            bezüglich der Doku war mir das schon klar. Was mich nur irritiert hat ist, das man es im Kommentar als "private" deklariert und dann die Funktion selbst nicht als solche "aufschreibt". Im gewissen Sinne hat das natürlich mit Konvention zu tun, allerdings hindert mich so niemand daran die Funktion außerhalb der Klasse aufzurufen. Gerde vor dem Hintergrund, dass nicht alle Funktionen die als protected genkennzeichnet sind mit einem Unterstrich gekennzeichnet sind. Da stellt sich dann die Frage wo der "Fehler" ist. Kommentar per Copy und Paste versemmelt, Unterstrich vergessen, oder soll das so. Das ist natürlich inkonsequent und nicht immer klar ersichtlich.

            Mein angesproche "Prüfung" solche Funktionen aufzurufen geht in die Richtung, dass es vielleicht ein Pattern gibt, dass den Aufruf von Funktionen steuern könnte und somit den direkten Aufruf unterbindet. Aber ich denke das wäre sicherlich nicht sonderlich sinnvoll, wenn es überhaupt möglich ist.

            Kommentar


            • #7
              Es ist nicht ganz einfach, denn beim Entwickeln wechselt man teilweise zwischen public, protected und private Deklarationen.

              Kommentar


              • #8
                Ich kann mir das schon vorstellen, dass das nicht ganz einfach ist. Gibt es denn so komplexe Editoren, die das gesamte Konstrukt "im Blick" haben. Wäre doch gut, wenn man merkt, dass eine als public gekennzeichnet Funktion "plötzlich" private ist. Gibt es also Hilfen, die mir helfen Veränderungen und ggf. Konflikte ggf. auch über die DocBlocks als sturktuelles Mittel darstellen oder ist das mehr Wunschdenken?

                Kommentar


                • #9
                  Zitat von KingCrunch
                  Benutze die Bennenung auch für PHP5 weiter, allerdings reicht meines Erachtens ein einfacher Unterstrich für protected und private aus. Oder anders gesagt: Also ohne Unterstrich is offen zugänglich, als mit einfach für "intern".
                  ist für php5 allerdings ein bisschen idiotisch. was ich besser fand, war, wie ich zuletzt in nem kunden script gesehen hab, wenn man einfache unterstriche für funktionen benutzt die durch interfaces definiert wurden. auch wenn die nich so häufig sind...
                  [B]PHP4?!?[/B]>>>[B]Aktuelle[/B] PHP Version: [B]5.2.11 || 5.3.0
                  [URL="http://en.opensuse.org/Factory/News"]Suse 11.2 *vorfreude*[/URL]
                  [/B]

                  Kommentar


                  • #10
                    Zitat von brian johnson
                    wenn man einfache unterstriche für funktionen benutzt die durch interfaces definiert wurden
                    Du meinst Klassen? Hm?!

                    Kommentar


                    • #11
                      Zitat von Zergling
                      Zitat von brian johnson
                      wenn man einfache unterstriche für funktionen benutzt die durch interfaces definiert wurden
                      Du meinst Klassen? Hm?!
                      nein aber an der formulierung haperts... ich meine, dass wenn ich durch ein interface spezifiziere welche methoden eine klasse definieren muss, benutze ich ab jetzt einen einfachen unterstrich vor den methodennamen die durch das interface spezifiziert wurden.
                      [B]PHP4?!?[/B]>>>[B]Aktuelle[/B] PHP Version: [B]5.2.11 || 5.3.0
                      [URL="http://en.opensuse.org/Factory/News"]Suse 11.2 *vorfreude*[/URL]
                      [/B]

                      Kommentar

                      Lädt...
                      X