Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Workaround für abstract static gesucht

Einklappen

Neue Werbung 2019

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

  • [Erledigt] Workaround für abstract static gesucht

    Hallo zusammen,
    ich bin PHP-Neuling und habe mich mal an ein Projekt gewagt, für das man sich einloggen muss. Dafür möchte ich die Facebook/Google/etc. APIs nutzen. Dazu habe ich eine abstrakte Klasse "User" angelegt:

    PHP-Code:
    abstract class User{
        
        
    /**
         * wird immer augerufen, wenn der Benutzer eingeloggt sein muss und
         * gibt entweder ein User-Objekt oder false zurück
         */
        
    public static function requireLogin(){
            
    /*die $_SESSION['service'] Variable wird beim login angelegt
             * und enthät bsp.: 'google' oder 'facebook'
             */
            
    if(isset($_SESSION['service']) && $_SESSION['service'] != '' ){
                
                
    $classname ucfirst($_SESSION['service']) . 'User';
                
                if(
    method_exists($classname'getUser')){
                    return 
    $classname::getUser();
                }
                return 
    false;
            }
            return 
    false;
        }
        
        abstract public static function 
    login(); //loggt den Benutzer ein, gibt ein boolean zurück
        
    abstract public static function getUser(); //gibt ein User-Object oder false zurück
        
        //unwichtig für das Problem
        
    abstract public function getFirstName();
        abstract public function 
    getLastName();
        abstract public function 
    getPictureUrl();    
        abstract public function 
    getName();
        abstract public function 
    getLogoutUrl();

    Dann gibt es noch für jeden Dienst eine Klasse. Bsp: 'FacebookUser'
    Da das Einloggen und das Überprüfen ob eine gültige Session besteht bei jeder API anders ist, soll jede Kind-Klasse die Funktionen:
    -login() haben, die aufgerufen wird, sobald der Benutzer von der Google- bzw. Facebook-Login-Seite zurückgeleitet wird und das Feedback verarbeitet (schreibt beispielsweise das facebookSessionToken in das $_SESSION Array).
    -getUser() habe, die überprüft ob eine gültige Session durch jeweilige API besteht und dann ggf. ein User-Objekt zurückgibt.

    Frage:
    Warum ist es in php nicht möglich eine statische Methode/Funktion abstract zu machen?
    Gibt es hier einen anderen Lösungsweg, der ohne diese Methoden auskommt oder diese an anderer Stelle hat ?

    danke

  • #2
    Workaround für abstract static gesucht

    In welcher Sprache kann man statische Methoden abstrakt machen? Das ist mir ganz neu. Überleg einmal, was das bedeutet und dann wird dir auch klar, wieso es das nicht gibt .
    [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
      Okay, nochmal drüber nachgedacht:
      abstract = keine Funktion
      static = Funktion, sogar ohne Objekt

      peinlich , aber danke für die schnelle Antwort.

      Gibt es denn einen Weg irgendwie festzulegen, dass alle Kind-Klassen von User diese beiden statischen Methoden haben müssen?

      Kommentar


      • #4
        Zitat von cobali Beitrag anzeigen
        Gibt es denn einen Weg irgendwie festzulegen, dass alle Kind-Klassen von User diese beiden statischen Methoden haben müssen?
        Nein! Statisch gehört nicht zur Vererbung. Nimm normale Methoden.
        [QUOTE=nikosch]Macht doch alle was Ihr wollt mit Eurem Billigscheiß. Von mir aus sollen alle Eure Server abrauchen.[/QUOTE]

        Kommentar


        • #5
          Nach dieser Frage weiss ich, dass der TE das OOP-Design zerbrechen will und etwas unsauber lösen will.
          [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


          • #6
            Komm von diesem mülligen static weg. Darauf Code aufzubauen hat mit Objektorientierung nix zu tun.
            [COLOR="#F5F5FF"]--[/COLOR]
            [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
            „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
            [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
            [COLOR="#F5F5FF"]
            --[/COLOR]

            Kommentar


            • #7
              schau mal http://hybridauth.sourceforge.net/ an, dort ist es so dass du ein Interface definierst mit getUser usw, dann kommt eine oAuth klasse(zb Facebook) und MUSS alle methoden des interface umsetzen, jedes auf seine eigene art und weise
              apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

              Kommentar


              • #8
                Zitat von cobali Beitrag anzeigen
                Gibt es denn einen Weg irgendwie festzulegen, dass alle Kind-Klassen von User diese beiden statischen Methoden haben müssen?
                Die Frage war vllt. etwas dämlich formuliert und das OOP-Design will ich auch nicht zerbrechen, es aber verstehen .

                Aber angenommen, ich wäre jetzt jemand anders, der professioneller vorgeht. Wie würde dieser jemand das es deutlich machen, dass diese Klassen da rein gehören. Im Falle, dass er sein Projekt mit anderen Entwicklern macht oder es veröffentlichen will. (übrigens habe ich das nicht vor)
                Würde diese Person einfach nur ein Kommentar da hinschreiben?
                Oder es von Anfang an garnicht erst so machen?

                Kommentar


                • #9
                  Er würde es nicht Static machen. Normale Methoden können vererbt/überschrieben werden und bei abstracten Methoden MUSS überschrieben (implementiert) werden, so wie du es bei den anderen schon gemacht hast.
                  [QUOTE=nikosch]Macht doch alle was Ihr wollt mit Eurem Billigscheiß. Von mir aus sollen alle Eure Server abrauchen.[/QUOTE]

                  Kommentar


                  • #10
                    Am besten "static" aus dem Sprachgebrauch entfernen. Du wirst prima ohne auskommen und dann Techniken kennenlernen, die dir weit mehr helfen als statische Methoden es je könnten.

                    Kommentar


                    • #11
                      Okay, nochmal drüber nachgedacht:
                      abstract = keine Funktion
                      static = Funktion, sogar ohne Objekt

                      peinlich , aber danke für die schnelle Antwort.
                      Ich denke ganz so einfach ist das nicht. Ich halte Deine Frage nach abstract static spätestens seit späte statische Bindung von PHP unterstützt wird für durchaus berechtigt.

                      Zuerst sollte man vielleicht etwas mehr zwischen abstrakten Klasse und abstrakten Methoden unterscheiden.

                      Eine abstrakte Klasse ist per Definition eine Klasse die mindestens eine abstrakte Methode enthält. Eine Abstrakte Klasse kann nicht instanziiert werden.

                      Eine abstrakte Methode ist nur eine Definition der Methodensignatur, ähnlich einem Interface.

                      Eine abstrakte Klasse signalisiert dem Entwickler somit, daß Sie nicht vollständig implementiert ist und verhindert zugleich jede Benutzung solange die fehlenden Teile nicht implementiert sind.

                      Etwas unlogisch in diesem Zusammenhang ist, daß diese „Info-und-Schutzfunktion“ nur für nicht-statische Methoden gilt. Statische Methoden lassen sich problemlos auch mit einer „unfertigen“/abstrakten Klasse aufrufen:

                      PHP-Code:
                      abstract class TestAbstract {
                          public static function 
                      a() {
                              echo 
                      "A";
                          }

                          abstract public function 
                      b();
                      }

                      TestAbstract::a(); 

                      Macht diese Ausnahme Sinn? Ich denke nicht wirklich, zumindest kann es in einigen Fällen zu Problemen führen:

                      PHP-Code:
                      abstract class TestAbstract {
                          public static function 
                      create() {
                              return new static();
                          }

                          abstract public function 
                      b();
                      }

                      $obj TestAbstract::create();

                      Fatal errorCannot instantiate abstract class TestAbstract in… 
                      Deshalb denke ich, daß man grundsätzlich besser beraten ist, wenn man mit abstrakten Klassen niemals direkt arbeitet, auch wenn es bei statischen Methoden durchaus erlaubt ist.

                      Wenn wir eine abstrakte Klasse als das betrachten was sie ist – eine Klasse die nicht vollständig implementiert ist und deshalb vor jeder Art der Benutzung zuerst noch fertig implementiert werden muss. Was spricht dann letztendlich gegen abstract static Methoden, wenn wir die Implementierung einer statischen Methode erst in einer abgeleiteten Klasse erzwingen wollen?

                      Die einhellige Meinung hier im Forum scheint zu sein „static is evil“. Ist das aber wirklich so? Haben statische Methode tatsächlich so gut wie keine Daseinsberechtigung? Macht eine Klasse nur dann Sinn wenn man davon Instanzen erstellen kann?

                      Bei Symfony findet man z.B. Klassen die nicht mal eine einzige Methode enthalten und nicht dafür gedacht sind instaziiert zu werden, reine static Klassen sozusagen:

                      (s. class StoreEvents)
                      http://symfony.com/doc/current/compo...roduction.html

                      Was ist schlecht daran? Sollte man hier etwa auch Objekte erzeugen, die nichts anderes machen als Konstanten zurückzugeben. Wozu?

                      Jedes Objekt, welches keinen Zustand hat ist strenggenommen überflüssig.

                      Ein anderes Beispiel:

                      PHP-Code:
                      abstract class AbstractRule {
                          public static function 
                      getRules(array $fields = array()) {
                              if(
                      true === empty($fields)) {
                                  return static::
                      rules();
                              }
                              return 
                      array_intersect_key(static::rules(), array_flip($fields));
                          }

                          protected static function 
                      rules() {return null;}


                      Diese einfache Klasse wird als abstrakte Klasse für konkrete Validator-Regeln-Klassen benutzt. Validator-Regeln haben keinen Zustand, es sind lediglich Definitionen. Ein Objekt wird hier nicht benötigt. Von der Basisklasse erbe ich jedoch die Methode getRules() und muss diese somit in den konkreten Rules-Klassen nicht mehr implementieren. Ich profitiere hier also dank LSB durchaus von den Vorteilen der Vererbung:


                      PHP-Code:
                      class UserRules extends AbstractRule {
                          protected static function 
                      rules() {
                              return array(
                      /*User-Validator-Rules*/);
                          }
                      }

                      class 
                      AddressRules extends AbstractRule {
                          protected static function 
                      rules() {
                              return array(
                      /*Address-Validator-Rules*/);
                          }
                      }

                      $validator = new Validator($dataUserRules::getRules()); 
                      Dummerweise kann ich die Methode protected static function rules() {return null;} nicht als abstrakt deklarieren obwohl genau das gewünscht wäre.

                      Also anstatt

                      PHP-Code:
                      protected static function rules() {return null;} 
                      besser

                      PHP-Code:
                      abstract protected static function rules(); 
                      Also stelle ich die Frage von cobali nochmals in den Raum

                      angenommen, ich wäre jetzt jemand anders, der professioneller vorgeht.
                      Vielleicht kann ja jemand am Beispiel der Rule-Klasse verdeutlichen wieso man hierbei auf die Verwendung der statischen Methoden verzichten und stattdessen besser mit zustandslosen Objekten arbeiten sollte?

                      vg
                      jack
                      -

                      Kommentar

                      Lädt...
                      X