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

    +160.4

    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
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    <?php
     $form = new Validator;
     $form
         ->newString(Request::get('nickname'));
         ->addRules(
             new FW\Rules\NotEmpty(),
             new FW\Rules\Length(4, 16),
             new FW\Rules\RegExp('/^[a-z]+$/i')
         );
         ->newString(Request::get('password'))
         ->addRules(
             new FW\Rules\NotEmpty(),
             new FW\Rules\MinLength(3),
             new App\Rules\PasswordStrength(40)
         );
         ->newString(Request::get('confirm'))
         ->addRules(
             new FW\Rules\NotEmpty(),
             new FW\Rules\Equals(Request::get('password'))
         )
         ->newString(Request::get('email'))
         ->addRules(
             new FW\Rules\NotEmpty(),
             new FW\Rules\ValidEmail(Request::get('email'))
         );
     if ($form->isValid()) {
         reg_user(Request::get('nickname'), Request::get('password'), Request::get('email'));
     } else {
         print_r($form->getErrors());
     }

    Народ ёбнулся на ООП

    Запостил: Mitusbka, 04 Ноября 2009

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

    • я всё думаю кодга if...else в нечто такое перепишут
      Ответить
      • уже скоро, работу со строками переписали, array на итераторы переписали...
        Ответить
    • Симпеатичненько
      Ответить
      • жаль только что можно переписать в 4 строчки
        Ответить
        • можно совсем весь код в одну строчку написать. но от этого то не легче
          Ответить
        • если Вы что-то не понимаете,это не значит, что это плохо.
          Ответить
          • если вы что-то не понимаете, не нужно умничать
            Ответить
    • нормальный код. в менее убогих языках это можно даже симпотично записать. Главное - понятно. Теоретически это даже можно обобщить и автоматом получать и валидацию на сервере, и js проверяющий на клиентской стороне.
      Ответить
      • симпАтично, чёрт побери!!! Сколько можно слово извращать?
        Ответить
        • симпатёво, но не стоит по 7 раз объявлять экземпля одних и тех же классов, с одними и теми же параметрами
          Ответить
        • проверочное слово симпОтный ;)
          Ответить
      • что значит симпатично, разве это цель?
        Ответить
    • Недоделка какая-то...
      Надо было от класса Validator унаследовать userRegisterValidator, который бы всё это в конструкторе создавал... А потом ему в некий метод кидались бы поля, а он возвращал результат проверки и ошибки... А так смысл то? Заменить три строчки проверки if preg_match else на кучу всяких new и -> прочей фигни...
      Вот не удивлюсь, если на сайте существуют две одинаковые формы, для каждой из который написан такой вот повторно используемый код =]
      (j/k)
      Ответить
      • а меня ещё убивает вынос правил в отдельные объекты (которые надо грузить и тд и тп.)
        и плюс прописывание правил для ключей а не ключей для правил
        в результате куча копипаста
        Ответить
        • Ага =]
          Это называется ООВ -- объектно ориентированный выпендрёж.
          Мол, я знаю new class public и много других страшных слов.

          Уж если не умеют так, делали бы по-другому... Но они будут упорствовать до хрипоты, что они делают ООП, и это круто.
          Ответить
          • Вы такую херню сказали, что с Вами даже дискутировать не хочется.. но все же - объясните, что в этом коде не так?
            Ответить
            • Я вам предлагаю спуститься ниже по комментариям и увидеть пример, пусть и грубый, но вполне удовлетворительный, который демонстрирует аналогичный код, переписанный без объектов.
              Хочу узнать, какие же преимущества есть у объектного кода перед моим?

              Если выигрыша нет, то данный говнокод есть ни что иное, как ООП ради ООП`а, который в случае Java ещё был бы оправдан, но в случае php является просто увеличением энтропии Вселенной и приближает нас к неминуемой тепловой смерти... ( про энтропию j/k)
              Ответить
            • а я вам предлогаю включить голову, если есть
              Ответить
              • ололо ! говнокод ваще не рабочий, так что включай свой анус!
                таке злоебуча хуйня не разу не прокатит, и пых пошлет вас нахуй с вашей подобией головы.
                ;
                ->ololo()
                Ответить
        • это это же логично!111 ОППаОППа-ОпаПА
          Ответить
      • это называется "плодить сущности". userRegisterValidator будет использоваться только в одном классе (по контексту он врядли еще куда-то подойдет) и нахрен такое счастье?
        Ответить
        • Главный принцип -- это определить именно те сущности, которые вы используете.
          Действительно userRegisterValidator, вероятно, ни где больше использоваться не будет (хотя и это совершенно не обязательно). И это был пример того, что стоило бы сделать. Сделать полиморфный валидатор, наследный валидатор. Потому что многие формы похожи. Нужно из таких форм конструктивные куски выделять. А прямое использование приведённого метода, приведёт к страшной копипасте... Две совершенно одинаковые формы будут просто скопированы, вместо того, чтобы использовать уже созданный объект, или хотя бы создать в одну строчку тот же самый, использовать прописанное повторно.
          Ответить
          • откуда в проекте может взяться две идентичные формы?
            разве не логично, что две одинаковые формы должны обрабатываться одним контроллером?
            Ответить
            • Например форма комментария может быть совершенно одинаковой, но встречаться в проекте в разных местах: отзыв в гостевой, комментарий на доске, отзыв у фотографии, отзыв у программы в магазине софта. Конечно, всё может зависеть от "хитрости" проекта. Например, все эти формы сначала уйдут на валидацию, а потом прицепятся данные в нужное место. Это уже вопрос того, как создана система, какие у неё конструктивные выделены куски.
              Может быть и другое. Например, многие формы имеют три одинаковых поля с одинаковой проверкой, хотя формы разные: регистрация пользователя, комментарий, загрузка нового стиха пользователем. Не выгоднее ли создать один общий контроллер для одинаковых полей, а затем конкретизировать его для каждой формы доопределив те поля, которые в них уникальны?
              Если таких пересечений мало или их нет вообще, значит сущность "формы" не нужна. Её вообще не должно быть в проекте. Должна быть сущность валидатора поля и именно к ней должны цепляться данные, потому что уж одинаковые поля с одинаковой проверкой точно встречаются.

              Либо на не нужна сущность формы -- она уже превысила необходимое, либо она слишком абстрактна и от неё есть полиморфные производные, которые действительно используются.

              Лев состоит из лап, головы, хвоста и туловища. Мы будем создавать сущность льва или будем конструировать его из лап и хвостов? Ответ на вопрос должна дать задача. Используем ли мы льва? Есть ли в этом смысл? Если мы сначала создаём льва, а потом отдельно используем от него лапы, то зачем лев? Но если у нас есть львы и львицы, например, то странно не ввести льва и не унаследовать от него самца и самку.
              Ответить
              • На java validation-фреймворки в основном так и работают: есть несколько контроллеров с формой и к ним цепляется класс-валидатор. Вынесены они отдельными классами как раз для того, чтобы обеспечивать вторичную используемость кода, но вот на практике мне не пришлось воспользоваться одним и тем же валидатором в разных контроллерах. Видимо, не свезло.

                Про "хитрость" проекта с Вами абсолютно согласен! Можно проектировать так, что классы-валидаторы будут использоваться в разных местах.
                Ответить
                • java это убогое говно, которому не место в пхп
                  Ответить
              • вообще-то комментарий - полиморфная модель данных. Поэтому она должна описываться одим объектом, хотя и может иметь различные представления.
                Ответить
        • По сути в данном месте вы уже не используете отдельную проверку поля. Вот если бы принцип был такой, тогда да, объекты проверки поля (но и в этом случае здесь фигня, потому что часто будут поля возникать одинаковые, и для каждого из них будет создано по три объекта проверки NotEmpty Length RegExp). Но здесь используется целая форма сразу, как монолит.

          Плодит сущности это MinLength и Length.
          Ответить
    • Что-то я не понял, если это взято с рабочего проекта, то это вообще работать не должно.
      ->newString(Request::get('nickname'));->addRules( - что это за синтаксис (; не должно тут быть)?
      А вот это new FW\Rules\NotEmpty()

      Если уж придумываете коды, так хоть пишите синтаксически правильно
      Ответить
      • >(; не должно тут быть)
        Похоже на то.
        Там одну точку с запятой нужно из верхнего выражения опустить за пассворд.
        Наверное это и стало причиной того, что автор обнаружил этот код. При парсинге произошла ошибка, Mitusbka полез поглядеть и ... Возможно это просто сохранена оригинальная пунктуация.
        Ответить
      • > А вот это new FW\Rules\NotEmpty()
        Это часо не неймспейсы юзаются?
        Ответить
      • это не из рабочего проекта, это мне пытались втирать как надо код писать
        ; это опечатка скорее
        а уж о неймспейсах стыдно не знать =)
        Ответить
        • а может и не опечатка, я в 5.3 сильно не копался пока
          Ответить
        • я вообще это всё к тому, что ООП раждает вот такие вот извраты, идеологически они может и правильны, но стоить помнить что логика приложения далеко не всегда совпадает с логикой человекомозга
          Ответить
        • Нет ничего стыдного, что не знаю про неймспейс, так как введено только в 5.3.0
          Ответить
          • да я и не стыдил
            Ps. Введено то в 5.3 а планировалось давненько уже
            Ответить
    • Они самые)))
      Ответить
    • Неугомонные адепты JQuery создали код сей
      Ответить
    • Это всякие ЗендФреймвоки порождают такой говностиль
      люди на них смотрят и свято верят что это эталон и надо его придерживаться =\
      Ответить
      • если это не эталон, то что эталон? куча ветвлений if-ele?
        Ответить
        • О.
          То есть вы видеть здесь что-то иное, чем
          $form = true;
          
          if( !(
              FVF\notEmpty(Request::get('nickname')) &&
              FVF\length(4, 16,Request::get('nickname')) &&
              FVF\regExp('/^[a-z]+$/i',Request::get('nickname')) )
          ) { $form = false; }

          ?
          Так расскажите нам, в чём преимущество кода.
          Вот мой код тоже читаемый, очень хорошо читаемый, и более эффективный.
          Так где подвох-то?
          Ответить
        • * то есть, вы видите здесь

          Тут сообщения нельзя править.
          Ответить
        • эталон это мозг понимающий внутренние процессы пхп и генерящий исходя из этого наилучший код, под поставленную задачу
          Ответить
      • Я не сторонник Zend Framework, но имел с ним дело. Пример не удачный.
        Ответить
    • АБСОЛЮТНО. НОРМАЛЬНЫЙ. и. КРАСИВЫЙ. КОД.
      Ответить
    • Почему нельзя проверить одним регекспом?
      /^[a-z]{4,16}$/i
      Ответить
    • Мля меня реально такие ооп-шники убивают, которые из кода на 2 строки, пишут на пол страницы.
      Ответить
      • всё из-за немонимания того что они делают.
        тупой кодинг по шаблону Java'ы
        Ответить
    • Есть готовые структуры, позволяющие делать это и гораздо более подходящие под эти задачи. Например, DOM. Тогда приходим и к унификации, и к автоматической генерации форм через тот же XSLT, и универсальному валидатору данных формы.
      А в примере — ООП ради ООП. Как эксперимент или пример — забавно, как часть проекта — перебор.
      Ответить
      • xslt вообще в php не место
        DOM не для валидации ни разу
        Ответить

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