Інтерфейс журналювання PSR (і чому журналювання важливо)
Дві функції PHP, якими, на мою думку, часто зловживають, коли йдеться про «налагодження», — це використання echo та var_dump. Я говорив про це в кількох різних статтях про налагодження (наприклад, тут і тут ).
Незважаючи на те, що я прихильник використання налагоджувача, я вважаю, що також важливо запровадити певний тип системи журналювання, щоб ви або ваш клієнт могли повернутися назад і переглянути дії, які відбувалися в системі, як вони або їхні користувачі Ви знаєте, використовували його.
Однак є два аспекти, щоб зробити це, особливо якщо ви хочете дотримуватися інтерфейсу журналювання PSR, і вони:
- правила для фактичного інтерфейсу журналювання,
- проект, який належним чином реалізує згаданий інтерфейс журналювання.
Тож чому б не розглянути обидва в цій публікації?
Інтерфейс журналювання PSR
Інтерфейс журналювання PSR (або PSR-3) охоплює низку речей, про які ви можете прочитати більш детально на справжній сторінці.
До них належать:
- Основи
- Повідомлення
- Контекст
- Допоміжні класи
- пакети
- Інтерфейси
- Рівні журналу
- І більше.
Але для цілей цієї статті я хочу поговорити конкретно про сам інтерфейс, проект, який його реалізує, і чому це важливо.
Інтерфейс реєстрації
На домашній сторінці документації зазначено:
Цей документ описує загальний інтерфейс для журналювання бібліотек.
Основна мета — дозволити бібліотекам отримувати об’єкт PsrLogLoggerInterface і записувати до нього журнали простим і універсальним способом.
З точки зору розвитку, це добре, чи не так? Я маю на увазі, що він забезпечує єдиний послідовний спосіб, на який ми можемо зробити ставку на будь-яку бібліотеку журналювання, яку ми вирішимо використовувати в наших проектах. Я розповім про свою улюблену бібліотеку далі в статті.
Для тих, хто новачок у об’єктно-орієнтованому програмуванні або просто цікаво дізнатися, яку користь нам приносить узгоджений інтерфейс, подумайте про це так: незалежно від того, яку систему ви виберете, ви гарантовано матимете певний набір функцій, станів тощо. можна використовувати у своїй програмі.
Зрештою, додавання системи журналювання, яка має стандарт, якому вона повинна відповідати, забезпечує низку переваг, незалежно від того, яку бібліотеку ви оберете (за умови, що вона відповідає PSR-3).
Спробуйте монолог
Monolog — це більш-менш фактична утиліта журналювання для програм PHP.
Проект легко додати за допомогою Composer, але він також включає різні способи виведення даних:
Monolog надсилає ваші журнали до файлів, розеток, вхідних повідомлень, баз даних і різних веб-служб. Дивіться повний список обробників нижче. Спеціальні обробники дозволяють створювати розширені стратегії журналювання.
Особисто я використовував його лише в контексті надсилання виводу до файлів; однак мати можливість виводити його в інші системи (особливо в бази даних, наприклад, під час роботи з WordPress) добре. Звичайно, ви не хочете зловживати цією здатністю.
По-друге, важливо визнати, що хоча ви можете створити екземпляр Logger у функції чи іншому класі, існують інші, більш об’єктно-орієнтовані способи зробити це. PSR-3 покриває це (як зазначено вище).
Коротше кажучи, ви хочете переконатися, що ваш клас приймає екземпляр класу, який реалізує LoggerInterface. Monolog реалізує зазначений інтерфейс, тому це не проблема.
Крім того, що відбувається, коли у вас є група пов’язаних класів, усі з яких потребують реалізації журналювання?
- Чи успадковують ці класи від спільного батька?
- Чи реалізують ці класи рису? (Це варіант, який нещодавно представив мені друг.)
- Чи кожен клас просто приймає залежність через впровадження конструктора?
Існує багато способів додавання реєстраторів до класу, і це залежить від того, як організовано ваш проект.
Більше про журналювання
У будь-якому випадку впровадження входу в програму є важливим з різних причин, таких як можливість усунути неполадки, коли щось поводиться не так, як очікувалося, як у розробці, на етапі, так і особливо у виробництві.