Prezentacja przygotowana na szkolenie wewnętrzne w Intersynergy

1. PROGRAMOWANIE OBIEKTOWE
NA PRZYKŁADZIE JĘZYKA PHP
ORAZ PSR

2. KIM JESTEM I DLACZEGO
PROWADZĘ TO SZKOLNIE?

3. DLATEGO :)

4. PROGRAMOWANIE
OBIEKTOWE
Programowanie obiektowe jest jednym
z paradygmatów programowania. Jest
to próba przedstawienia rzeczywistości
i relacji w niej zachodzących za pomocą
obiektów i klas.

5. KLASA A OBIEKT
Klasa jest typem danych.
Typem danych może być np.
integer, string, boolean lub
klasa stworzona przez nas.
Klasa definiuje metody czyli
funkcjonalności oraz pola
(właściwości) czyli zmienne.
Czym jest obiekt? Jest to
instancja danej klasy, czyli
konkretna zmienna danego
typu.
KLASA
POLE
METODA
OBIEKT

6. 4 POJĘCIA ZWIĄZANE Z
PROGRAMOWANIEM
OBIEKTOWYM
PROGRAMOWANIE
OBIEKTOWE
Abstrakcja
Dziedziczenie
Hermetyzacja
Polimorfizm

7. ABSTRAKCJA
Pojęcie w programowaniu
obiektowym najczyściej
utożsamiane z klasą. Jest
modelem, który w rzeczywistości
nie reprezentuje żadnego
istniejącego obiektu, a jedynie na
podstawie którego definiowane
są inne obiekty. Przykładem
może być ssak, lub zwierzę – nie
ma ich rzeczywistego obiektu, a
jedynie obiekty potomne
bazujące na ich własnościach.

8. POLIMORFIZM
Inaczej
wielopostaciowość,
metoda
pozwalająca funkcji
wirtualnej
przyjmować różne
sposoby jej
realizacji.

9. HERMETYZACJA
Czyli ukrywanie
implementacji,
enkapsulacja. Zapewnia, że
obiekt nie może zmieniać
stanu wewnętrznego innych
obiektów w nieoczekiwany
sposób. Tylko własne
metody obiektu są
uprawnione do zmiany jego
stanu (np. gettery i settery).

10. DZIEDZICZENIE
Porządkuje i wspomaga
polimorfizm i enkapsulację
dzięki umożliwieniu
definiowania i tworzenia
specjalizowanych obiektów na
podstawie bardziej ogólnych.
Dla obiektów specjalizowanych
nie trzeba redefiniować całej
funkcjonalności, lecz tylko tę,
której nie ma obiekt
ogólniejszy.

11. KLASY ABSTRAKCYJNE I
INTERFEJSY

12. KLASA ABSTRAKCYJNA
• Klasa abstrakcyjna jest to klasa której obiekty nie mogą być
tworzone, może być natomiast dziedziczona.
• Klasa abstrakcyjna może posiadać konstruktor jak i destruktor, mogą
być one jednak wywołane tylko przez klasy pochodne.
• Klasę abstrakcyjną tworzymy przy pomocy modyfikatora abstract
• Dodatkowo klasa abstrakcyjna może posiadać funkcje abstrakcyjne,
funkcja taka posiada listę argumentów, jednak nie posiada ciała.
• Funkcje abstrakcyjne muszą zostać nadpisane w klasach
pochodnych. Tworzone są one również modyfikatorem abstract

13. KLASA ABSTRAKCYJNA -
PRZYKŁADStworzyliśmy klasę
abstrakcyjną Animal która
posiada konstruktor i
funkcję abstrakcyjną.
Klasa Elephant która
dziedziczy klasę
abstrakcyjna Animal
nadpisuje funkcje
abstrakcyjna (musi to
zrobić), jak i wywołuje
konstruktor klasy
abstrakcyjnej w ciele
swojego konstruktora.

14. INTERFEJSY
• może mieścić jedynie metody, które z założenia są abstrakcyjne.
• wszystkie metody zawarte w interfejsie muszą zostać nadpisane w klasach
pochodnych.
• Przy pomocy interfejsów masz możliwość wymuszenia na klasach, aby
posiadały niezbędne do współpracy z innymi elementami metody, tak więc
interfejsy zapewniają określone cechy klasy.
• Interfejs tworzymy słowem kluczowym interface
• Klasy nie dziedziczą interfejsów, klasy je implementują, dokonujemy tego
używając modyfikatora implements po którym podajemy nazwy interfejsów do
zaimplementowania.
• Do danej klasy możemy implementować dowolną ilość interfejsów.

15. INTERFEJS - PRZYKŁAD
Stworzyliśmy dwa interfejsy,
Carnivorous i Herbivorous.
Interfejsy te posiadają
odpowiednio metody eatMeat
jak i eatVegetables. Tak więc
klasy implementujące je muszą
te metody nadpisać. Widzimy
że klasa Human implementuje
interfejs Carnivorous jak i
Herbivorous, taki sam efekt
moglibyśmy otrzymać
implementując interfejs
Omnivorous który dziedziczy
po Carnivorous i Herbivorous.

16. WZORCE PROJEKTOWE

17. Wzorzec projektowy (ang. design
pattern) – uniwersalne, sprawdzone w
praktyce rozwiązanie często
pojawiających się, powtarzalnych
problemów projektowych. Pokazuje
powiązania i zależności pomiędzy klasami
oraz obiektami i ułatwia tworzenie,
modyfikację oraz pielęgnację kodu
źródłowego.

18. SINGLETON
Singleton jest jednym z najprostszych
wzorców projektowych. Jego celem jest
ograniczenie możliwości tworzenia obiektów
danej klasy do jednej instancji oraz
zapewnienie globalnego dostępu do
stworzonego obiektu – jest to obiektowa
alternatywa dla zmiennych globalnych.

19. PRZYKŁAD
Klasa Config zawiera tablicę z
podstawowymi ustawieniami
aplikacji. Dzięki zastosowaniu
Singletona zmiana ustawień w
jednym miejscu (np. zmiana języka
na stronie przez użytkownika) jest
„widoczna” w każdym miejscu
aplikacji. Ponadto można łatwo
zaprojektować klasę z konfiguracją,
tak by było można łatwo dodawać
kolejne ustawienia w miarę potrzeb.
‚pl’
‚en’

20. PROTOTYP
Prototyp jest wzorcem, opisującym mechanizm tworzenia
nowych obiektów poprzez klonowanie jednego obiektu
macierzystego. Mechanizm klonowania wykorzystywany
jest wówczas, gdy należy wykreować dużą liczbę
obiektów tego samego typu lub istnieje potrzeba
tworzenia zbioru obiektów o bardzo podobnych
właściwościach. Wzorzec Prototype można stosować w
sytuacjach, gdy tworzona jest duża liczba obiektów tego
samego typu. Stosuje się go głównie w celach
optymalizacji, gdyż klonowanie obiektu jest szybsze niż
jego stworzenie.

21. PRZYKŁADKlasa abstrakcyjna Book zawiera
pola title i topic, metody publiczne
(gettery i settery) oraz metodę
abstrakcyjną clone. Klasy PHPBook i
JAVABook rozszerzają klasę Book.
Konstruktory tych klas ustawiają
wartości dla pola topic.
Kat. JAVA, Tytuł: Książka 1
Kat. JAVA, Tytuł: Książka
1
Kat. JAVA, Tytuł: Książka 2
Kat. PHP, Tytuł: Książka 1

22. INNE WZORCE

23. PSR
Czyli PHP Standard Recommendations

24. PHP-FIG
PHP Framework Interop Group - grupa
miłośników języka PHP. Zajmują się oni
standaryzacją koncepcji programowania w
języku PHP. W skład tej grupy wchodzą
między innymi twórcy frameworków takich jak
Symfony, Codigniter itp.

25. PSR-1 — PODSTAWOWY
STYL KODOWANIA• Kod PHP musi znajdować się między znacznikami <?php ?> lub <?= ?> . Nie można stosować żadnych innych
znaczników do oznaczania skryptów PHP.
• Wszystkie pliki PHP muszą używać kodowania UTF-8 bez znaku kolejności bajtów (BOM). Wydaje się, że
spełnienie tego wymogu jest skomplikowane, ale w rzeczywistości edytory tekstu i środowiska programistyczne
załatwiają to automatycznie
• Pojedynczy plik PHP może definiować symbole (klasę, cechę, funkcję, stałą itd.) lub wykonywać czynność
powodującą skutki uboczne (np. tworzyć dane wyjściowe albo manipulować danymi). Plik PHP nie powinien
pełnić dwóch typów ról jednocześnie. Spełnienie tego wymogu nie jest trudne i wymaga jedynie nieco
planowania ze strony programisty
• Przestrzenie nazw (Namespaces) i klasy muszą spełniać wymogi standardu PSR-4. Programista ze swojej
strony musi tylko wybrać odpowiednie nazwy dla swoich symboli PHP i zadbać o to, aby zawierające ich
definicje pliki znajdowały się w odpowiednich miejscach.
• Nazwy klas PHP muszą być zgodne z NotacjąWielbłądzią czyli CamelCase lub TitleCase.
• Nazwy stałych w PHP należy zapisywać wielkimi literami, a do oddzielania słów używa się znaków
podkreślenia, np.: SUPER_PARTIA_KURWO
• Nazwy metod powinny być zgodne z taką notacjąWielbłądzią, tzn. pierwsza litera powinna być mała, a
pierwsze litery kolejnych wyrazów powinny być wielkie, np.: phpJestŚwietny

26. PSR-2 — RESTRYKCYJNY
STYL KODOWANIA
• Jednym z wymogów standardu PSR-2 jest zaadaptowanie wymagań
standardu PSR-1.
• Wcięcia muszą mieć wielkość 4 spacji
• Pliki PHP muszą kończyć się pustym wierszem oraz nie mogą mieć na
końcu znacznika ?>. Żaden wiersz kodu nie powinien być dłuższy niż
80 znaków. Żaden wiersz kodu nie może być dłuższy niż 120 znaków.
Na końcu wiersza kodu nie może być białych znaków
• zaleca się, aby wszystkie słowa kluczowe PHP pisać małymi literami np.
null, true, false

27. PSR-2 - NAMESPACES
Za każdą deklaracją
przestrzeni nazw powinien
znajdować się jeden pusty
wiersz. Także po bloku
instrukcji importu lub
tworzących aliasy
przestrzeni nazw za
pomocą słowa kluczowego
usenależy zostawić jeden
wiersz pusty.

28. PSR-2 - KLASY
Rekomendacja PSR-2 stanowi,
że znak otwarcia klamry musi
znajdować się w nowym
wierszu, bezpośrednio pod
nazwą tej klasy. Znak
zamknięcia klamry definicji
klasy również musi znajdować
się w osobnym wierszu, za
definicją klasy. Jeśli tworzona
klasa rozszerza inną klasę lub
implementuje interfejs, słowa
kluczowe extends i implements
muszą znajdować się w tym
samym wierszu co nazwa
klasy:

29. PSR-2 - METODY
Zasady dotyczące umiejscowienia
znaków otwarcia i zamknięcia klamry
są takie same jak dla klas. Znak
otwierający klamrę definicji metody
musi znajdować się w nowym wierszu
bezpośrednio za nazwą metody. Znak
zamykający należy umieścić w
nowym wierszu bezpośrednio za
ostatnią linijką definicji metody.
Szczególną uwagę trzeba poświęcić
argumentom. Za nawiasem
otwierającym i przed zamykającym
nie powinno być żadnych białych
znaków. Po każdym argumencie
oprócz ostatniego znajduje się
przecinek i jedna spacja

30. PSR-2 - WARUNKI I PĘTLE
Po każdym słowie kluczowym
konstrukcji sterującej musi
znajdować się jedna spacja. Słowa
kluczowe konstrukcji sterujących to: if,
elseif, else, switch, case, while, do
while, for, foreach, try, catch. Jeżeli po
słowie kluczowym musi znajdować się
nawias, to po znaku otwierającym i
przed znakiem zamykającym nie może
być białych znaków. W odróżnieniu
od definicji klas i metod, znak otwarcia
klamry powinien znajdować się za
słowem kluczowym i w tym samym
wierszu co to słowo. Znak zamknięcia
klamry musi znajdować się w
osobnym wierszu.

31. PSR-4 — AUTOMATYCZNE
WCZYTYWANIE
ZALEŻNOŚCICzwarta rekomendacja PHP-FIG opisuje
standardową strategię działania programu do
automatycznego wczytywania zależności
(autoloadera). Strategia ta polega na znajdowaniu klas
PHP, interfejsów lub cech i wczytywaniu ich do
interpretera PHP na żądanie w czasie działania
programu. Komponenty PHP i systemy szkieletowe
zgodne ze standardem PSR-4 mogą być lokalizowane
i wczytywane do interpretera PHP tylko przez jeden
autoloader

32. PSR-4 — AUTOMATYCZNE
WCZYTYWANIE
ZALEŻNOŚCI• PSR-4 opisuje strategię lokalizowania i
wczytywania klas, interfejsów i cech PHP
podczas działania programu. Rekomendacja ta
nie wymaga zmiany aktualnej implementacji
kodu, tylko sugeruje organizację kodu w
katalogach i przestrzeniach nazw. Strategia
PSR-4 wykorzystuje przestrzenie nazw i katalogi
do lokalizowania i wczytywania klas, interfejsów i
cech.

34. DZIĘKUJĘ ZA UWAGĘ !