Cześć.
Jako, że uczę się PHP OOP to chciałbym się zapytać czy mój kod dostępny (nie skończony jeszcze) ma cokolwiek wspólnego z OOP?
Może popełniam jakieś błędy?
Cześć.
Jako, że uczę się PHP OOP to chciałbym się zapytać czy mój kod dostępny (nie skończony jeszcze) ma cokolwiek wspólnego z OOP?
Może popełniam jakieś błędy?
Jakaś tu obiektowość jest, ale czy ona jest poprawna.. to tak średnio - powiedziałbym. Połowę metod zrobiłbym statycznymi.
Zapoznaj się ze wzorcami projektowymi, jeden z najważniejszych i najprostszych to DRY, czyli "Nie powtarzaj się" (Don't repeat Yourself).
Do poczytania:
https://pl.wikipedia.org/wiki/DRY
Następnie są kolejne wzorce dotyczące samego projektowania obiektowego, ponieważ samo używanie klas i obiektów to nie znaczy jeszcze programowanie obiektowe :) Niektóre wzorce warto stosować zawsze (DRY), a inne przy projektach określonego typu.
Przeczytaj:
Popełniasz mnóstwo błędów, ale każdy je popełniał. Z czasem będzie ich coraz mniej :)
A mógłbyś wskazać między innymi jakie błędy ;)?
public function method($param1, $param2, $param3) {}
stosuj
public function method(['param1' => $param1, 'param2' => $param2, 'param3' => $param3]) {}
a już najlepiej zrobić sobię klasę z parametrami i
public function method(ClassWithParameters $classWithParameters) {}
metody są wtedy łatwiejsze do testowania.
Coś takiego:
public function method(['param1' => $param1, 'param2' => $param2, 'param3' => $param3]) {}
to jest koszmar przy dużych projektach - np. kilkaset relacji SQL i No-SQL, około tysiąca klas PHP a każda z nich kilkanaście metod.
Stosując taki sposób, aby szybko pracować, musisz pamiętać za każdym razem jakie parametry (klucze) dodać do tablicy, i co one znaczą, nie mówiąc o tym, że później w samej metodzie, znowu musisz się babrać z tablicą, żeby z niej wyciągać dane.
Natomiast np. coś takiego:
/**
* Funkcja do pobierania zasobu bez synchronizacji.
*
* @param string $group - grupa
* @param string $key - klucz
* @param int $lifetimeInSeconds - czas życia w sekundach
* @return mixed|null - zasób lub NULL jeżeli operacja nieudana
*/
protected function getValueNoSynchro($group, $key, $lifetimeInSeconds)
to miodzik, bo teraz w IDE takim jak Netbeans albo np. PHPStorm, po wpisaniu nazwy metody od razu dostajesz powiedzi jaki parametr do czego służy, i w ogóle jakie parametry funkcja przyjmuje.
Rozumiem, że przekazywanie tablicy jest bardziej elastyczne, bo później można łatwo dodać jakiś parametr, ale to jest antywzorzec programowania obiektowego w którym jako parametry do funkcji powinno się przekazywać przede wszystkim obiekty, i proste typy, a nie tablice.
PS. Nie chcę nawet pytać jak uzasadniasz stosowanie DI zamiast dziedziczenia z klasy, ale może nie pisz, bo się boje, że dostanę apopleksji.
mało ma ten kod wspólnego z OOP.
Pabloss napisał(a):
mało ma ten kod wspólnego z OOP.
Dzięki za wyczerpującą wypowiedź.
TomRZ napisał(a):
Coś takiego:
public function method(['param1' => $param1, 'param2' => $param2, 'param3' => $param3]) {}
to jest koszmar przy dużych projektach - np. kilkaset relacji SQL i No-SQL, około tysiąca klas PHP a każda z nich kilkanaście metod.
Stosując taki sposób, aby szybko pracować, musisz pamiętać za każdym razem jakie parametry (klucze) dodać do tablicy, i co one znaczą, nie mówiąc o tym, że później w samej metodzie, znowu musisz się babrać z tablicą, żeby z niej wyciągać dane.
Natomiast np. coś takiego:
/** * Funkcja do pobierania zasobu bez synchronizacji. * * @param string $group - grupa * @param string $key - klucz * @param int $lifetimeInSeconds - czas życia w sekundach * @return mixed|null - zasób lub NULL jeżeli operacja nieudana */ protected function getValueNoSynchro($group, $key, $lifetimeInSeconds)
to miodzik, bo teraz w IDE takim jak Netbeans albo np. PHPStorm, po wpisaniu nazwy metody od razu dostajesz powiedzi jaki parametr do czego służy, i w ogóle jakie parametry funkcja przyjmuje.
Rozumiem, że przekazywanie tablicy jest bardziej elastyczne, bo później można łatwo dodać jakiś parametr, ale to jest antywzorzec programowania obiektowego w którym jako parametry do funkcji powinno się przekazywać przede wszystkim obiekty, i proste typy, a nie tablice.
PS. Nie chcę nawet pytać jak uzasadniasz stosowanie DI zamiast dziedziczenia z klasy, ale może nie pisz, bo się boje, że dostanę apopleksji.
Dziękuję za odpowiedź, zabieram się za studiowanie i wdrażanie tego co napisałeś.