1. PHP / Говнокод #12720

    +146

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    class User {
    
      protected $login;
      protected $password;
      protected $email;
    
      public function __construct($login, $password, $email) {
        $this->login = $login;
        $this->password = $password;
        $this->email = $email;
      }
    
      public function __get($name) {
        $reflector = new ReflectionClass($this);
        return $reflector->hasProperty($name) ? $this->{$name} : null;
      }
    
    }

    Запостил: __proto__, 10 Марта 2013

    Комментарии (24) RSS

    • Нормальный магический геттер. Я бы только бросал RuntimeException, если свойство не существует.
      Ответить
      • нормальный?
        1. да он вообще не нужен
        2. ну если очень уж хочется, то зачем прикручивать рефлексию, когда можно записать так:
        return isset($this->$name)?$this->$name:null;
        Ответить
        • 1. Нужен, если хочется защищенные от записи поля.
          2. В данном коде - да, согласен (но все равно не говнокод, просто автор немного перемудрил). Но если учесть мое замечание об исключении то с рефлексией есть возможность отличать несуществующие поля от тех, в которых NULL.
          Ответить
          • > если хочется защищенные от записи поля...
            ... то писать надо на C++/Java. Имхо для языков с динамической типизацией такого хотеться не должно.
            Ответить
            • Почему не должно? На PHP пишутся и довольно большие проекты, в которых удобно иметь подобные возможности. И я не вижу связи между этим и типизацией.
              Ответить
    • Почему никто не хочет писать так?
      protected	$login,
      	$password,
      	$email;
      Ответить
    • protected $login;
      protected $password;
      protected $email;


      пользователи будут чувствовать себя в безопасности
      Ответить
    • И вообще, protected-поля - моветон. Тогда уж private.
      Ответить
      • private же и потомкам доступ закрывает? Имхо это перебор. protected снаружи не видно, а вот если класс-потомок решил залезть под капот, так пусть копается на свою голову.
        Ответить
        • В ООП не принято открывать поля даже классам-потомкам. Вообще. Ибо инкапсуляция. Если хочется - делайте protected-геттеры.
          Ответить
    • Почему каждый __get вызывает new?
      Ответить
      • Это же PHP - 30 секунд позора и память сама очистится.

        А вообще конечно нужно в конструктор вынести.
        Ответить
        • Можно было бы и наподобие предложенного Луром:
          class User {
          
            protected $user = array();
          
            public function __construct($login, $password, $email) {
              $this->user['login'] = $login;
              $this->user['password'] = $password;
              $this->user['email'] = $email;
            }
            public function __get($name) {
              return isset($this->user[$name])? $this->user[$name] : null;
            }
          }

          Или не?
          Ответить
          • undefined offset, Или не?
            Ответить
            • Насколько помню isset это специальная конструкция, не функция. Так что не должно нотисов про undefined offset выдавать.
              Ответить
          • Не, вотак:
            class User {
            
              protected $user = array(
                "login"=>null,
                "pasword"=>null,
                "email"=>null
              );
            
              public function __construct($login, $password, $email) {
                $this->user['login'] = $login;
                $this->user['password'] = $password;
                $this->user['email'] = $email;
              }
              public function __get($name) {
                return $this->user[$name];
              }
            }
            Проверка в геттере нах не нужна если задать нуллы ранее, еще до конструктора. А-ля константы.
            Ответить
            • Что-то мне подсказывает, что вы не правы...
              Ответить
              • Нет ты!
                Ответить
              • Так оставайтесь при своем (уме)..

                Я прав к тому, что магический __get() вообще тут не нужен. И проверка на наличие св-ва тоже не нужна. Если уж известно, что в любом случае надо вернуть хотя-бы null - присваиваем сразу нуллы всем (по умолчанию), а в конструктор приедет то, что приедет.
                Ответить
                • > Я прав к тому, что магический __get() вообще тут не нужен
                  Но тем не менее вы его реализовали.
                  > И проверка на наличие св-ва тоже не нужна.
                  Тогда я делаю $user->foobar и ваш код вылетает с undefined offset. Я лично считаю правильнее давать null, еще правильнее - бросать пользовательское исключение.
                  Ответить
                  • тогда в магическом методе можно просто возвращать нулл\бросать исключение, т.к. он вызовется только если поле не было найдено.
                    и код не вылетит - будет нотис, который максимум покажется на экране, минимум - прожуется.
                    Ответить
    • Вообще, если уж на то пошло, то есть и array_contains_key и property_exists, но тогда вся затея с __get теряет смысл. Вообще код изначально бессмысленный: в какой ситуации код этой же программы "вдруг" забудет какие поля есть у объекта типа User? Ну вот, писал человек программу, писал, и тут забыл, что у объекта есть такое свойство, и так ее заказчику и отдал? Херня какая-то вобщем.
      Ответить
      • магия это вообще плохо в подавляющем большинстве случаев
        Ответить
        • в подавляющем большинстве случаев ООП это Общество Ортодоксальных Педерастов
          Ответить

    Добавить комментарий