OOP - czy mój kod ma cokolwiek wspólnego

0

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?

https://github.com/na5tyk/skrypt

1

Jakaś tu obiektowość jest, ale czy ona jest poprawna.. to tak średnio - powiedziałbym. Połowę metod zrobiłbym statycznymi.

1

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.

1

Przeczytaj:

Popełniasz mnóstwo błędów, ale każdy je popełniał. Z czasem będzie ich coraz mniej :)

0

A mógłbyś wskazać między innymi jakie błędy ;)?

0
  1. Zamiast dziedziczenia stosój Dependency Injection.
  2. Zapoznaj się z composerem.
  3. Widzę że dodajesz pojedyńcze parametry do metod, dodawaj tablicę wartość => klucz, czyli zamiast
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.

  1. MVC Twoim przyjacielem.
0

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.

0

mało ma ten kod wspólnego z OOP.

3
Pabloss napisał(a):

mało ma ten kod wspólnego z OOP.

Dzięki za wyczerpującą wypowiedź.

0
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ś.

0 użytkowników online, w tym zalogowanych: 0, gości: 0