Вопрос актуализации манов, кто за ними следит, и почему жалуются на устаревшие примеры, которые переходят из проекта в проект при существующих современных альтернатив?

[Alar]

Мы же часто берем примеры из манов не задумываясь, особенно на старте изучения.

можно рассмотреть примёр у Флёнова. - http://www.flenov.info/blog/show/Mal...svyazannyy-kod

Скопировал на форум для ознакомления со статьёй:

Наверно в каждой книге написано про то, что нужно писать код без жёстких зависимостей - использовать интерфейсы и инъекцию зависимостей. Но почему-то мало, кто реально следует этому. И отчасти это проблема документации, на которую смотрят программисты.

Вот взять для примера всеми любимые фреймворки для PHP и посмотреть на код оправки почты - вот возьмем пример отправки E-mail из Symfony. Я специально беру его, потому что фреймворк хороший и в нем можно писать код без зависимостей.

public function indexAction($name, \Swift_Mailer $mailer)
{
    $message = (new \Swift_Message('Hello Email'))
        ->setFrom('send@example.com')
        ->setTo('recipient@example.com')
        ->setBody(
            $this->renderView(
                // templates/emails/registration.html.twig
                'emails/registration.html.twig',
                array('name' => $name)
            ),
            'text/html'
        )
}

Пример взят с сайта сайта Symfony.

Прямо в методе контроллера нам предлагают использовать жёсткую привязку к конкретной реализации Swift Message. А что если завтра эта реализация умрет? Где интерфейс, который абстрагируется от этой конкретной реализации? Где Dependency Injection?

Фреймворк - это круто, он предоставляет кучу вкусняшек, но уже вот здесь пользователи видят как не нужно в реальности делать.

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

А ведь в Symfony уже есть все готовое, просто пример на сайте не отражает это. Можно зарегистрировать сервис:

services:

    sample.service:

        class:     %sample.service.class%

        arguments: [@mailer]

И теперь через конструктор получать его:

 __construct($mailer)

Можно сохранить этот мейлер в качестве локальной переменной и использовать его. Больше не нужно задумываться о том, какой сервис будет создан, легче перейти на другой, в случае необходимости и так далее.

[Pavia]

Автор прав что не пишут в примерах абстракции. Но зачем городить лишние абстракции? Когда я ищу код я в первую очередь ожидаю увидеть минимально рабочий пример. Потому что одно дело увидеть а другое дело пощупать этот пример. Вот рабочий пример я могут скомпилировать и поломать по модифицировать по отлаживать.

А тут автор предлагает либо писать абстракции это же получается полуфабрикаты получаются. Которые ещё и приготовить надо и не факт что эти приготовления займут как с Юпи 5 минут (Юпи-просто добавь воды). Скорее напротив несколько часов.

Зачем мне в примере шелуха по созданию интрефейса? Лишний код только отвлекает от главного.

Так что с автором я не согласен. Если он хочет видеть качественный код то для этого мастер-классы.

[Скарам]

А какой смысл им в примере для отправки письма приводить пример DI? Если он у тебя в проекте есть, то ты сам решишь хочешь ли абстрагироваться от конкретной реализации. В большинстве проектов этого нет, особенно в легаси. Любая технология должна применяться к месту и со знанием дела. Это относиться и к инверсии контроля. И вообще применять SOLID, без определенного набора знаний вредно. Поэтому фреймворк показывает самый примитивный пример.
Возьмем людей, с которыми работаю я (все программисты на .net или oem-щики). Для большей части лень прочитать документацию по TPL и ключевым словам async/await. Вводить асинхронное программирование сложно, любая ошибка с использованием тасок приводит к панике. Приходиться сидеть с ними, объяснять, читать лекции. Поэтому SOLID или TDD у нас тоже зависает на уровне сервисов, которые написал я. Я не могу сказать, что у них недостаточно квалификации или еще чего-то, просто они очень инертны. Таким людям нужны примеры с DI? Серьезно? Они либо выкинут DI, либо найдут пример, где его нет. Ну или фреймворк сменят (может и на более худший), где этого "непонятного" нет.

[jura_k]

Лень двигала прогресс всегда вперёд.