Autor: Damian Tylczyński Aktualne serwisy internetowe coraz częściej przypominają rozbudowane aplikacje, tworzone w dużych zespołach programistów z myślą o długofalowym rozwoju. Opowiem jak okiełznać pokaźne bazy kodu i umożliwić elastyczną rozbudowę aplikacji dzięki architekturom typu plug-in.

1. Wprowadzenie do implementacji
architektur plug-in w PHP
Damian Tylczyński

2. „Gdybym wiedział co robię, to przecież nie była by
praca badawcza„
- Albert Einstein

3. Funkcjonalność
System
monolityczny

4. „smaller parts (modules) that can be
independently created and then used in different
systems to drive multiple functionalities”
- Wikipedia, Modular design

5. Plug-in
Niezmienna postać,
Stabilne API zmienna funkcjonalność
na żądanie
System
architektury
plug-in Miejsce na dalszy rozwój
Usługi systemu

6. „LINUX is a monolithic style system. This is a
giant step back into the 1970s. That is like taking
an existing, working C program and rewriting it in
BASIC. To me, writing a monolithic system in
1991 is a truly poor idea„
- Andy Tanenbaum

7. Spoiler:
Darwin, Linux, Windows NT
nie są mikro-jądrami

8. XULRunner

10. Plug-in powinien skupić się
na wykonaniu pojedynczego zadania

11. Nie ArticlesPlugin
tylko:
● PagePlugin – wyświetlanie i edycja,
● CategoriesPlugin – kategoryzacja,
● TagPlugin – tagi,
● CommentsPlugin – komentarze,
● ScorePlugin – ocenianie,

12. Nie UsersPlugin
tylko:
● AuthPlugin – ACL i autoryzacja,
● LoginPlugin – logowanie,
● RegisterPlugin – rejestracja,
● UserDataPlugin – dane użytkownika,

13. Dostęp do bazy danych?
Sesje?
Także plug-in

14. (mikro) jądro
Udostępnienie fundamentalnego
środowiska działania plug-in

15. Jądro i zdarzenia
Konfiguracja Rejestracja Uruchomienie
środowiska i konfiguracja pluginów aplikacji

16. Cykl życia pluginu:
Instalacja,
→ Uruchomienie,
→ Działanie,
Aktualizacja
→ Zatrzymanie,
Usunięcie.

17. Zarządzanie pluginami
Tak, to też plugin

18. Zależności
Udostępnianie „narzędzi”
Pliki multimedialne
Instalacja
Plug-in to nie tylko „jakaś”
funkcja do wywołania
Reagowanie
Aktualizacja
Nadpisywanie

19. Abstrakcja System
M C V
bazy danych szablonów
Obsługa
Wywołanie Odpowiedź
żądania
akcji HTTP
HTTP
Zarządzanie
Jądro plug-in Plug-iny

20. Plug-in musi mieć możliwość komunikacji
z innymi częściami systemu
(i z innymi pluginami)

22. Luźne wiązania

23. Pośrednik

24. Programowanie zdarzeniowe

25. Wysłanie
Odebranie

26. Bąbelkowanie

27. Zatrzymywanie bąbelkowania

29. I funkcje domyślne też

30. getContext()
Obiekt kontekstu naszym pośrednikiem
(wielozadaniowym)

31. Wstrzykiwanie zależności umożliwia
rozpropagowywanie obiektu kontekstu

33. Każdy plug-in
musi posiadać dostęp do własnego
obiektu kontekstu
Każda klasa.
Każda usługa.

34. Usługi?

35. Usługa to zestaw funkcji posiadających
zunifikowane API, implementujące rozwiązanie
pewnego problemu (uff...)

36. Dlaczego nie wszędzie zdarzenia?
Na zdarzenie nie musi reagować
żadna funkcja

37. Plugin != Usługa
Plugin > Usługa

38. LogsService – logowanie w aplikacji.
Pluginy?
LogsTxtPlugin
LogsNullPlugin
Zunifikowany interfejs?
log( $msg )
warn( $msg )
err( $msg )

39. Kontekst musi udostępniać usługi
(zachowywać się jak kontener zależności)

41. Narzędzia
Programowanie zdarzeniowe.
Wzorzec filtra.
Wzorzec dekoratora.
Wzorzec strategii.
Obiekty proxy.
Kontener wstrzykiwania zależności.

43. Stabilność
Dziel i rządź GTD programowania
Zalety
Zrównoleglenie prac
Mniej zależności
Bezpieczeństwo

44. Dziękuję za uwagę