Vokiel.com

Podczas pisania aplikacji internetowych ważną częścią projektu jest wiedza na temat działania owego produktu. Zdarzają się błędy wynikłe nie tylko ze złej implementacji, kodu aplikacji, ale także te niezależne od programisty. Mogą to być różnego rodzaju przerwy w działaniu innych serwisów, problemy z połączeniem internetowym, awarie. W takiej sytuacji bardzo przydatnym narzędziem jest możliwość logowania zdarzeń. W tym wpisie zajmę się opisaniem własnego pomysłu na klasę loggera.

Zacznijmy od założeń, wymgań dla klasy.

1. elastyczność
2. możliwość umieszczenia logów w różnych formatach i lokalizacjach
3. łatwość użycia
4. możliwość szybkiej zmiany silnika przechowywania

Zdarza się czasem, iż chcemy przechowywać logi w plikach, czasem w bazie danych. Nasza klasa powinna mieć możliwość łatwej zmiany silnika przechowywania logów oraz w miarę prostego sposobu przełączania się pomiędzy nimi.

Ewentualnie też, mogłaby mieć możliwość korzystania z kilku silników w jednym skrypcie. Ta opcja nie jest taka ważna, a na pewno nie jest koniecznością, jednak może się przydać w ekstremalnych sytuacjach. Załóżmy, że swoją klasę logowania ustawiliśmy na zapis do bazy. Co jednak w przypadku, gdy połączenie z bazą zostanie przerwane? W takiej sytuacji przydałoby się zapisać log w łatwiej dostępne miejsce – plik .log, .xml.

Aby móc korzystać z możliwości łatwego przełączania silnika loggera należy dobrze rozplanować struktury klas. Możemy skorzystać z klas abstrakcyjnych, interfejsów lub zwykłych klas. Aby zachować kompatybilność dodatkowych sterowników loggera postanowiłem oprzeć log class o interfejsy.

Jak podaje wikipedia: interfejs jest abstrakcyjną reprezentacją klasy pozwalającą na korzystanie z niej niezależnie od faktycznej implementacji.

Interfejs w PHP jest tak jakby tylko pomocnikiem dla programisty. Pokazuje jakie metody klasy implementujące muszą zaimplementować lecz sam ich nie udostępnia (w odróżnieniu od klasy abstrakcyjnej). Dla naszego zastosowania będzie to bardzo dobre rozwiązanie. Każdy rodzaj sterownika będzie dodawał zdarzenia do logów w inny sposób. Dodatkowo korzystając z interfesu będziemy mieli pewność, że dodatkowe sterowniki będą posiadały wymagane metody.

Jakie metody będą nam potrzebne? Jak dla mnie wystarczą 3 podstawowe: error();, warn();,info();. Schemat interfejsu będzie następujący:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<?php
/**
 * Interfejs dla klas logów
 * @author Vokiel
 * @package log
 */
interface log_log{
	/**
	 * Dodanie błędu do logów
	 * @param	string	$msg	Komunikat
	 */
	public static function error($msg);
	/**
	 * Dodanie ostrzeżenia do logów
	 * @param	string	$msg	Komunikat
	 */
	public static function warn($msg);
	/**
	 * Dodanie komunikatu informacyjnego do logów
	 * @param	string	$msg	Komunikat
	 */
	public static function info($msg);	
}// end of logInterface
?>

Nasz interfejs posiada 3 metody do których przekazywany jest komunikat. Zapytacie czemu nie jedna metoda z flagą oznaczającą rodzaj komunikatu. Otóż wynika to z trzeciego punku założeń. Utworzyliśmy metody statyczne, dzięki temu będziemy mogli się do nich odwołać poprzez:

<?php
log::info('Wszystko ok');
log::error('Wszystko jak krew w piach!');
?>

Co dalej? W dalszych odcinkach zajmiemy się tworzeniem klas implementujących interfejs log_log oraz utworzeniem klasy trzymającej to wszystko w kupie.