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

    +165

    1. 1
    ORM::factory('comment')->values($_POST,array('folder_id','code','comment','post_id'))->set('post_id',$post_id)->set('user_id',Auth::instance()->get_user()->id)->set('ip',$_SERVER['REMOTE_ADDR'])->create();

    Запостил: kyzi007, 23 Ноября 2011

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

    • Govnokod::PHP->make(just, lulz, me);
      Ответить
    • ну спасибо! )))))
      (ц)
      Ответить
      • Не за что:)
        Ответить
      • Программирование на стрелочках), это же круче, чем монады.
        Ответить
        • и гораздо понятнее ))
          Ответить
          • Да ладно, можно попробовать написать "виселицу": http://en.wikibooks.org/wiki/Haskell/StephensArrowTutorial, отталкиваясь от типов. И статью Патерсона посмотреть.

            Другое дело практическое применение). Ни htx (да там они скорее внутри), ни yampa лично не применял. И haskell-on-horse сд^Wостался без головы.
            (Короче не шибко сложнее монад, но профит/сложность ниже).
            Ответить
        • Кстати, программирование на Haskell - ваша работа или увлечение?
          Ответить
          • Скорее увлечение, но иногда с пользой (те же парсеры). На него так просто не дадут завязаться... (Хотя есть, скажем galois.com или хм... банки)
            Ответить
        • *cough* *cough*
          http://www.haskell.org/arrows/
          Ответить
    • Вот всегда так с похапе - вроде и ООП, и паттерны головного мозга присутствуют, а все равно говно говном.
      Ответить
    • ява стайл какой то ...
      Ответить
    • Было тут когда-то, кажется, так там джойны для запроса делались дикой цепочкой ->join()->join()->join()->join()... Правда, сейчас не вспомню, в каком языке дело было.
      Это неизлечимо.
      Ответить
      • Хы, вообще это говнокод на php, а вполне реальный шаблон проектирования используемый повсеместно (не только в PHP). Название правда подзабыл, вроде как плавающие строки (точно не помню). Суть его заключается в том, чтобы сформировать некую сущность (строку, массив, итд) с помощью вызова поочередно методов объекта (все методы объекта совершают некие действия и возвращают ссылку на себя). К примеру этот паттерн распростронен в zend фреймворке. Для того чтобы собрать запрос в кучу. Типа того:
        $select = $this->_adapter->select()
        ->from('artists_indexing')
        ->where('is_indexed=?', ARTIST_STATE_NOT_INDEXED)
        ->orWhere('is_indexed=?', ARTIST_STATE_FAILED)
        ->orWhere('is_indexed=?', ARTIST_STATE_PROCESSING)
        ->limit(1);

        Вы конечно можете вызвать все эти методы отдельно и все такое. Но в таком виде это смотриться очень наглядно без мешанины ИМХО
        Ответить
        • fluent interface
          Ответить
        • смотриться-смотриться

          это даже не сахар, а ацетат свинца
          для тех, кто в школе ниасилил переменные в трубо паскакале
          Ответить
        • Я понимаю, если бы было нужно собирать запросы в зависимости от каких-то условий. А так - спасибо, мне не лень написать
          select abc from sch.tbl where id
          Не вижу вообще никаких бенефитов у такой схемы.
          Ответить
          • Ну как, можно нагадить товарищам которые придут за тобой и в некоторых местах сделать последовательную трансформацию...
            Огромный плюс:)
            Ответить
          • Меньше шансов ошибиться. Удобно собирать on-the-fly, опять же.
            Ответить
          • бенефит тот же, что и у ORMов - не заморачиваемся с SQL и разницей в диалектах
            Ответить
            • Отвечаю всемъ.
              > можно нагадить товарищам
              Ну, тогда сам чорт велел.
              > Меньше шансов ошибиться.
              Три года писал запросы. Ошибки были, из-за любви к копипасте. Но даже в запросах с двумя десятками джойнов всё было вполне очевидно.
              > Удобно собирать on-the-fly, опять же.
              Как я и писал выше, для рантайм сборки потянет, но тоже не панацея.
              > не заморачиваемся с SQL и разницей в диалектах
              Если мне не отшибает память, всё равно при смене СУБД придётся переписывать запросы. Плюс, SQL-то всё равно знать нужно.
              Ответить
          • Вам тогда лучше вообще не юзать фреймворки и забыть про паттерны, лучше все делать в ручную по старинке.... Данный паттерн юзается не только в sql, он развит повсеместно. Вот пример форм, надеюсь до вас дойдет для чего он нужен:

            $realName = new Zend_Form_Element_Text('artist_real_name ');
            $realName->setLabel('Реальное имя')
            ->setValue($data['artist_real_name'])
            ->setDescription('Если это группа или дуэт не нужно заполнять это поле!')
            ->addFilter('StripTags')
            ->addFilter('StringTrim');
            Ответить
            • Спасибо, я уже всё понял, что это для тех, кто ебанулся на отличненько.
              Ответить
        • в общем jQuery так делает.
          Ответить
        • на паттерн эта не тянет просто использавние зомыкания
          Ответить
          • Нет в этом коде замыканий. Хоте в языке с PHP 5.3 они наконец появились. :)
            Ответить
            • замыканий нет, есть ЗОМЫКАНИЯ.
              Ответить
              • >замыканий нет
                Мечтай. Это больше не киллер-фича функциональных языков. Они скоро и до VB дойдут, если ни уже.
                http://www.job-blog.bullgare.ru/2009/08/новое-в-php-5-3-замыкания-лямбда-функции/
                Ответить
      • Учите паттерны не помешает...
        Ответить
        • Fluent Interface - это не паттерн в терминологии GOF, а способ построения API. Не знаешь сам - не учи других.
          Ответить
          • Хым интересно... Что-же по Вашему тогда паттерн? Было тяжело прогуглить чтоли?
            http://www.google.kg/search?q=pattern+Fluent+interface&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
            Ответить
            • http://www.ozon.ru/context/detail/id/2457392/
              Прочитайте таки эту книжку. Эффорта мало, бенефита много.
              Ответить
              • Обязательно ради вас :) Вам бы тоже не помешало вспомнить забытое или научиться неизведанному
                Ответить
          • По моему общая цель всех видов паттернов это создания некого АПИ! Школота...
            Ответить
            • Цель паттернов - предоставить способы решения стандартных программно-инженерных задач в малом, упростить и удешевить разработку ПО, упростить взаимодействие разработчиков.

              > Школота...
              no comments.
              Ответить
              • Согласен! По каким критериям сюда не подходит fluent interface? Изначально вдумайтесь в словосочетание - Шаблон проектирования. Т.е мы с помощью fluent interface проектируем наш объект так, чтобы можно было бы по цепочке формировать какие-либо данные
                Ответить
              • Соот-но это упростит работу с нашим объектом и разработчикам создаст некий апи для работы с ним. Мне все очевидно, а Вам?
                Ответить
                • Ок, какую инженерную задачу, проблему он решает? На мой взгляд, он просто иногда делает код более читаемым, уменьшает число временных переменных.
                  Не знаю, как вы, а я всё же ощущаю большую идеологическую разницу между fluent interface и, к примеру, AbstractFacotory, Flyweight, Composite, MVC ...
                  Ответить
                  • Вы знаете я ее тоже ощущаю :)
                    Не даром ведь шаблоны были разбиты на группы:
                    1. Порождающие
                    2. Поведенческие
                    3. Сруктурные
                    4. Базовые (общего назначения). К которому и относится наш Fluent!

                    Какую задачу он решает Вы ответил уже сами...
                    Ответить
                    • Вы пропустили слово "инженерную". Я читал оригинальную статью Фаулера по этой теме примерно полгода назад. Обратите внимание на теги: API design, DSL. Про design patterns ни слова.
                      Приведите, пожалуйста, ссылку, где FI причисляют к базовым шаблонам.
                      Ответить
                      • 1. Какой смысл вы вкладываете в слово "инженерный"?
                        2. Вот список наиболее рапространненых патернов (куда входит паттерн о котором мы говорим):
                        http://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1% 80%D0%B8%D1%8F:%D0%A8%D0%B0%D0%B1%D0%BB% D0%BE%D0%BD%D1%8B_%D0%BF%D1%80%D0%BE%D0% B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D 0%B0%D0%BD%D0%B8%D1%8F
                        3. Мне тяжело вам будет сейчас на скорую руку найти источник откуда я взял что данный
                        паттерн входит в базовые паттерны общего назначения. Fluent interface из-той же оперы что и эти шаблоны:
                        Основные
                        Делегирование
                        Интерфейс
                        Неизменяемый объект

                        т.е отнести их к выше описанным 3 категориям не удасться. Т.е их лучше охарактеризовать как базовые (общие)
                        Ответить
                        • Все design patterns призваны решать инженерные задачи, т.е. преодолевать трудности масштабируемости системы, инкапсуляции логики приложения, снижать потребление ресурсов, повышать повторное использование элементов, etc.

                          Даже если по списку:
                          Делегирование - позволяет сделать систему гибче, сделать её более прозрачной для клиента.
                          Интерфейс - повышает гибкость, позволяет компилировать части приложения раздельно, предоставлять множество реализаций, etc.
                          Неизменяемый объект - позволяет упростить логику многопоточных программ, повысить надёжность системы в целом за счёт уменьшения возможных источников side-effect'ов.

                          Fluent Interface же никак не влияет на систему в целом. Сам по себе он делает систему более масшабируемой, не снижает потребление ресурсов. Его цель - удобство использования api. Я не говорю, что это ненужная задача (я сам постоянно использую FI на практике). Просто на design pattern не тянет.
                          Ответить
                          • > Сам по себе не он делает
                            selffix
                            Ответить
                          • Во общем видимо у нас разное понимание патернов проектирования.
                            Вам кажется это, что-то более академичным, направлено имено на оптимизацию потребление ресурсов итд.
                            Для меня же паттерны это - удачные решения тех или инных задач опытными программистами.
                            Направленными в различные аспекты, как можно догадаться из существующих категоий паттернов.
                            Некторые из них действительно призваны для эфективной работы с памятью, а некоторые как этот
                            для удобства заполнения структур итд. Не нужно быть таким категоричным на то они и шаблоны, а не
                            доктрины
                            Ответить
                      • Блин ссылка не рабочая. вот на вики - http://en.wikipedia.org/wiki/Fluent_interface

                        Снизу можете прочитать категию куда отнесли тему
                        Ответить
                        • > Fluent Interface - это не паттерн в терминологии GOF
                          warning: self reference.

                          В этой категории много статей, косвенно относящихся к design patterns. Там есть, к примеру, "Повторное использование кода".
                          Ответить
                          • Вот поэтому я воткнул фразу - паттерн общего назначение (т.е удачное примения этого приема) не относящегося к 3 перечисленным.
                            Ответить
                    • Во нашел снова линку:
                      http://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1% 80%D0%B8%D1%8F:%D0%A8%D0%B0%D0%B1%D0%BB% D0%BE%D0%BD%D1%8B_%D0%BF%D1%80%D0%BE%D0% B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D 0%B0%D0%BD%D0%B8%D1%8F
                      Ответить
                  • >я всё же ощущаю большую идеологическую разницу между fluent interface и, к примеру,

                    Если ощущаешь, то приведи ещё примеры, которые относятся к к тому же классу, что и fluent interface.

                    Ты сможешь привести несколько примеров только, если ощущаешь.
                    Ответить
                    • roman-kashitsyn, ощущаешь не очень удачное слово для инженера. Я бы подправил твоё предложение, убрав слово "ощущаю" в угоду использования фразы: "выделяю в отдельный класс".
                      Ответить
                    • Есть, к примеру, приём, используемый, когда нужно заставить клиентский код вызвать несколько методов твоего интерфейса в определённом порядке. Желательно, чтобы порядок было нельзя перепутать.
                      В таком случае каждый метод должен возвращать объект, передающийся на вход другому методу:
                      SomeDescriptor d = MyLib.initialize();
                      // User will be unable to miss initialization
                      MyLib.doSomething(d);
                      Вот это примерно из той же оперы: проектирование программных интерфейсов.
                      Ответить
                      • Ок, в класс ты отдельный FI (и др) выделил. Теперь ждем названия этого класса. Если это не паттерн, то что это? На всякий случай вспомни перевод слова pattern и вспомни, что бывают определения в узком и широком смысле.
                        Ответить
    • И как это никто не сказал, что это Kohana framework?
      Ответить

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