Контакты

Достижения

Все достижения (7)

Наибольший вклад в теги

Все теги (26)

Лучшие ответы пользователя

Все ответы (18)
  • Где найти самое простое объяснение Dependency Injection паттерна?

    iximiuz
    @iximiuz
    Мартин Фаулер круто пишет обо всех паттернах. Про DI можно почитать тут. Вообще у него отличный блог. И он же автор книги P of EAA. Правда русский ее перевод крайне не рекомендую читать, можно только запутаться, так что читайте в оригинале.

    Если хотите разобраться с паттернами, то самая простая (и при этом дельная!) книга - это Фриман&Фриман. Ее можно читать и на русском.

    Применительно к PHP - вот лучшая книга про шаблоны (и не только), которую я видел PHP. Объекты, шаблоны и методики программирования от Мэт Зандстра.

    Порядок прочтения рекомендую следующий: Фриман&Фриман, затем Мэт Зандстра, и на десерт Фаулера P of EAA.

    UPD:
    Важно отличать паттерн Dependency Injection от Dependency Injection Container.
    Простейший пример внедрения зависимости:
    interface IEngine {}
     
    class V8Engine implements IEngine {}
     
    class Car {
      public function __constructor(IEngine $engine) {
        $this->engine = $engine;
      }
    }
     
    $car = new Car(new V8Engine());

    Простейший пример игнорирования явного внедрения (для такого кода трудно писать unit-тесты, его труднее понимать и править):
    class V8Engine {}
    
    class Car {
      public function __constructor() {
        $this->engine = new V8Engine();
      }
    }
    
    $car = new Car();

    Отличный (и легковесный) пример DIC - это pimple:
    // define some services
    $container['session_storage'] = function ($c) {
        return new SessionStorage('SESSION_ID');
    };
    
    $container['session'] = function ($c) {
        return new Session($c['session_storage']);
    };

    Советую прочитать и понять его исходники, чтобы убедиться, что в DIC (во всяком случае для PHP) нет никакой магии. Первая версия была всего ~100 строк. Необходимо также отметить, что класс Session использует шаблон Dependency Injection, явно определяя свою зависимость от SessionStorage. А контейнер делает лишь правильную связку.

    И да, контейнер сам по себе можно использовать как service locator, если к нему, например, есть глобальный доступ. Но это очень плохая практика, потому что если что-то обращается к сервис локатору, то формально оно начинает зависеть сразу от всех компонентов системы.
    Ответ написан
    4 комментария
  • Какой язык программирования выбрать?

    iximiuz
    @iximiuz
    Python или JS. А PHP ни в коем случае, как стартовый язык. Он дает слишком искаженное понимание бекграунда веб-разработки из-за особенностей работы интерпретатора (изолирование окружение скрипта, reset интерпретатора между запросами). При этом Python, JS, Ruby и скорее всего Java, хотя на последней у меня нет опыта, в плане веб-разработки выглядят очень похожими. Общие принципы построения и запуска приложений, многопоточность, асинхронность (как возможность). В PHP ничего этого нет, там все выглядит куда более линейным и упрощенным. Пересесть с Python или Ruby на PHP (при необходимости!) будет элементарной задачей, а вот обратное - не верно, слишком много новых концепций нужно будет освоить.

    И никаких фреймворков в начале обучения! Программист на Django звучит также ужасно, как программист на jQuery. Это как клеймо. Программист - это прежде всего понимание общих принципов разработки, а уже потом языки, фреймворки и пр. Так что прежде всего необходимо разобраться с wsgi. Написать пару своих скриптов, обрабатывающих запросы. Проверить, как работает эта кухня. Потом можно начать использовать flask.

    P.S. Доп. плюсы Python, JS и пр. - область их использования не ограничена вебом. Возможно в будущем вы будете этому рады, когда решите вместо сайтов программировать боевых роботов или попробовать себя в машинном обучении или еще где-нибудь.
    Ответ написан
    4 комментария
  • С чего начать написание парсера?

    iximiuz
    @iximiuz
    Отличная и мощнейшая библиотека для парсинга сайтов на Python - это scrapy.

    В то же время, есть два "интересных" проекта - zenrus.ru и ruszen.ru. И где-то я видел статью, что как минимум одному из них, сделанному на коленке, было очень трудно справляться с неожиданно выросшей нагрузкой. Я бы порекомендовал вам использовать какой-либо бродкастинг для оповещения всех подключенных клиентов об изменении курса - что-то вроде websocket.
    Ответ написан
    Комментировать
  • Как удобней передать в шаблонизатор кучу аргуметов?

    iximiuz
    @iximiuz
    Сделайте так:
    tpl_params = {...}  # сколько угодно строк, заполняющих dict.
    return render_template("index.html", **tpl_params)

    А вообще... Есть такая практика - не передавать в шаблон море переменных. Кажется в Rails, если пишешь код в RubyMine, даже предупреждения будут, если передал в шаблон больше 1 или 2 объектов. Есть такой паттерн - View Object. Это про то, что нужно собрать все данные, требуемые текущей страницей, в один более или менее согласованный (по интерфейсу) объект и передать в шаблон именно его. При таком подходе код становится чище, и проще писать тесты на шаблонизацию.
    Ответ написан
    Комментировать
  • Хотейки и вопросы по проектированию классов?

    iximiuz
    @iximiuz
    По первому пункту налицо нарушение закона Деметры. Вероятнее всего нужно по-другому поделить ответственность между классами, чтобы не возникала необходимость делать длинные цепочки вызовов.

    По поводу второго пункта. PHP и так вполне себе DDL язык. Если нужно хранить данные, то можно спокойно их хранить в специальных PHP файлах, содержащих один массив, например. И инклюдить их в нужном месте. Все эти замесы с ini-файлами (и еще того хуже xml-файлами) пошли от компилируемых языков, особенно из Java, когда описать конфиги непосредственно в Java-коде с возможностью их изменения без перекомпиляции всей программы достаточно проблематично.
    Ответ написан
    2 комментария

Лучшие вопросы пользователя

Все вопросы (5)