Ведение журнала с PSR-3 для улучшения возможности повторного использования

Но предположим, что мы хотим повторно использовать наш класс Mailer в другом проекте, который использует Analog для обработки взаимодействий журналирования. Теперь мы столкнулись с проблемой, потому что у Analog нет метода addInfo() Чтобы записать сообщение информационного уровня с Analog, мы вызываем Analog::log($message, Analog::INFO)

Мы могли бы изменить наш класс Mailer для использования методов Analog, как показано ниже.

 <?php
namespace Email;

class Mailer
{
    public function sendEmail($emailAddress)
    {
        // code to send an email...
        
        // log a message
        Analog::log("Email sent to $emailAddress", Analog::INFO);
    }
}

Мы можем использовать обновленный класс Mailer, используя следующий код:

 <?php
// set up Analog
Analog::handler(AnalogHandlerFile::init("mail.log"));

// create the mailer and send an email
$mailer = new EmailMailer();
$mailer->sendEmail("[email protected]");

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

Использование PSR-3 для избежания зависимости от регистратора

Как объяснил Алехандро Жервасио в своей превосходной статье на эту тему, принцип обращения зависимостей говорит нам, что мы должны зависеть от абстракций, а не от конкрементов. В случае с журналированием нашей проблемой до сих пор было отсутствие достойной абстракции, от которой можно было бы зависеть.

Вот тут-то и появляется PSR-3. PSR-3 предназначен для решения проблемы несовместимых реализаций журналирования, предоставляя универсальный интерфейс для регистраторов, метко названный LoggerInterface Предоставляя интерфейс, который не привязан к какой-либо конкретной реализации, PSR-3 освобождает нас от необходимости полагаться на определенный регистратор — вместо этого мы можем напечатать подсказку для LoggerInterface Я обновил класс Mailer ниже, чтобы продемонстрировать это:

 <?php
namespace Email;

class Mailer
{
    private $logger;
    
    public function __construct(PsrLogLoggerInterface $logger)
    {
        $this->logger = $logger;
    }
    
    public function sendEmail($emailAddress)
    {
        // code to send an email...
        
        // log a message
        $this->logger->info("Email sent to $emailAddress");
    }
}

Конструктор был изменен, чтобы принимать разработчика LoggerInterfacesendEmail()info()

Monolog уже соответствует PSR-3, и Analog предоставляет объект-оболочку, который реализует LoggerInterface

Вот как бы вы назвали класс с Monolog:

 <?php
// create a Monolog object
$logger = new MonologLogger("Mail");
$logger->pushHandler(new MonologHandlerStreamHandler("mail.log"));

// create the mailer and send an email
$mailer = new EmailMailer($logger);
$mailer->sendEmail("[email protected]");

И с аналогом:

 <?php
// create a PSR-3 compatible Analog wrapper
$logger = new AnalogLogger();
$logger->handler(AnalogHandlerFile::init("mail.log"));

// create the mailer and send an email
$mailer = new EmailMailer($logger);
$mailer->sendEmail("[email protected]");

Теперь мы можем использовать наш объект Mailer с любой библиотекой без необходимости редактировать класс Mailer или изменять способ его использования.

Использование шаблона адаптера для регистраторов, которые не поддерживают PSR-3

До сих пор мы успешно отделяли объект Mailer от любой конкретной реализации ведения журналов, запрашивая разработчик LoggerInterface Но как насчет регистраторов, которым еще предстоит добавить поддержку PSR-3? Например, популярная библиотека KLogger некоторое время не обновлялась и в настоящее время не совместима с PSR-3.

К счастью, нам просто сопоставить методы, предоставляемые KLogger, с методами, определенными LoggerInterfaceшаблона адаптера . Вспомогательные файлы в репозитории Psr / Log позволяют легко создавать классы адаптеров, предоставляя нам класс AbstractLogger Абстрактный класс просто перенаправляет восемь специфичных для уровня методов ведения журнала, определенных в LoggerInterfacelog() Расширяя класс AbstractLoggerlog() Я продемонстрирую это ниже, создав простой адаптер для KLogger:

 <?php
namespace Logger;

class KloggerAdapter extends PsrLogAbstractLogger implements PsrLogLoggerInterface
{
    private $logger;    
    
    public function __construct($logger)
    {
        $this->logger = $logger;
    }

    public function log($level, $message, array $context = array())
    {
        // PSR-3 states that $message should be a string
        $message = (string)$message;

        // map $level to the relevant KLogger method
        switch ($level) {
            case PsrLogLogLevel::EMERGENCY:
                $this->logger->logEmerg($message, $context);
                break;
            case PsrLogLogLevel::ALERT:
                $this->logger->logAlert($message, $context);
                break;
            case PsrLogLogLevel::CRITICAL:
                $this->logger->logCrit($message, $context);
                break;
            case PsrLogLogLevel::ERROR:
                $this->logger->logError($message, $context);
                break;
            case PsrLogLogLevel::WARNING:
                $this->logger->logWarn($message, $context);
                break;
            case PsrLogLogLevel::NOTICE:
                $this->logger->logNotice($message, $context);
                break;
            case PsrLogLogLevel::INFO:
                $this->logger->logInfo($message, $context);
                break;
            case PsrLogLogLevel::DEBUG:
                // KLogger logDebug() method does not accept a second
                // argument
                $this->logger->logDebug($message);
                break;
            default:
                // PSR-3 states that we must throw a
                // PsrLogInvalidArgumentException if we don't
                // recognize the level
                throw new PsrLogInvalidArgumentException(
                    "Unknown severity level"
                );
        }
    }
}

Метод log()LoggerInterface Оборачивая класс KLogger таким образом, мы можем использовать его, не нарушая контракт LoggerInterface

Теперь мы можем использовать адаптер KLogger для работы с классом Mailer:

 <?php
// create a new KLogger object which will log to the "logs" directory
$klogger = KLogger::instance("logs");

// inject KLoggger to a PSR-3 compatible KloggerAdapter
$logger = new LoggerKloggerAdapter($klogger);

// send an email
$mailer = new EmailMailer($logger);
$mailer->sendEmail("[email protected]");

Используя класс адаптера, мы можем использовать KLogger без изменения класса Mailer и все еще придерживаться LoggerInterface

KLogger не принимает второй аргумент для сообщений уровня отладки, поэтому он технически не соответствует PSR-3 даже с адаптером. Расширение KLogger до полной совместимости с PSR-3 было бы тривиальной задачей, но она выходит за рамки этой статьи. Тем не менее, можно с уверенностью сказать, что использование нашего класса адаптера очень близко приближает нас к полному соответствию PSR-3 и позволяет использовать LoggerInterface

Вывод

В этой статье мы увидели, как использование PSR-3 может помочь нам написать независимый от регистратора код, который не зависит от конкретной реализации ведения журнала. Многие крупные проекты PHP уже добавили поддержку PSR-3, в том числе Monolog, Symfony и Mustache.php , и другие известные имена, такие как Drupal , обсуждают, как лучше интегрировать его. Поскольку PSR-3 делает журналирование менее барьером для повторного использования кода, мы должны увидеть больше библиотек и структур, правильно использующих журналирование для предоставления полезной информации разработчикам.

Повлияет ли PSR-3 на то, как вы используете логирование в своих приложениях? Дайте нам знать в комментариях ниже.

Изображение через Fotolia