![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 114 Pomógł: 0 Dołączył: 3.08.2017 Ostrzeżenie: (0%) ![]() ![]() |
Nie czuję do końca stosowania interfejsów w mojej aplikacji... Poniżej podaję, jak to obecnie wygląda. Może tak zostać bądź coś poprawić?
Utworzyłem interfejs Mysqli dla klasy Database: Kod <?php declare(strict_types=1); namespace App\Core; interface Mysqli { public function dbConnect(): void; public function dbClose(): void; public function dbQuery(string $query): mixed; public function dbFetchArray(mixed $result): array|null|false; public function dbNumberRows(mixed $result): int; public function dbAffectedRows(): int; public function dbInsertId(): int; public function dbStartTransaction(): bool; public function dbCommit(): bool; public function dbRollback(): bool; } Interfejs Mail jest implementowany przez Email: Kod <?php declare(strict_types=1); namespace App\Core; interface Mail { public function sendEmail( string $serverName, string $emailFrom, string $emailTo, string $subject, string $message ): bool; } Oraz interfejs Validator jest implementowany przez abstrakcyjne klasy Code, Error i Message, które są potem rorszerzane przez podklasy odpowiedziane za validację (np. MainPageValidator) danych z formularzy czy api: Kod <?php declare(strict_types=1); namespace App\Core; interface Validator { public function isValid(): bool; } Wypadałoby dodać jeszcze inne interfejsy dla moich klas tutaj? Trochę nie czuję, gdzie powinienem stosować interfejsy... |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Moderatorzy Postów: 36 559 Pomógł: 6315 Dołączył: 27.12.2004 ![]() |
Odnosnie tego co zwraca query() to nie poprawione to jest. ok, niby zwracasz bool, ale inne zapytania jak fetch() nadal wymagaja tego resource, wiec nic sie nie zmienilo, wiec nie potrzebnie to trzymasz tez jako wlasciwosc w klasie bo trzymasz tylko jedno, jak masz kilka query to kazde zwroci inne resource.
Idea byla by metody ala fetch, nie musialy juz tego brac jako parametr, tylko by sobie braly z wlasciwosci klasy. moze ja za bardzo kombinuje, ale ja osobiscie bym zrobil to teraz tak: query niech zwraca to resource, w type mixed zapisuj to tez we wlasciwosci klasy jak to robic, zas metody ala fetch: user moze podac nam ten resource albo nie. Jak nie poda to fetch wezmiej ostatni zapisyny we wlasciowosci klasy. Wtedy kod moze wyglada tak $con->query('blabla'); $con->fetch() Albo $res - $con->query('blabla'); $con->fetch($res) |
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 1 Pomógł: 0 Dołączył: 3.03.2025 Ostrzeżenie: (0%) ![]() ![]() |
Odnosnie tego co zwraca query() to nie poprawione to jest. ok, niby zwracasz bool, ale inne zapytania jak fetch() nadal wymagaja tego resource, wiec nic sie nie zmienilo, wiec nie potrzebnie to trzymasz tez jako wlasciwosc w klasie bo trzymasz tylko jedno, jak masz kilka query to kazde zwroci inne resource. Idea byla by metody ala fetch, nie musialy juz tego brac jako parametr, tylko by sobie braly z wlasciwosci klasy. moze ja za bardzo kombinuje, ale ja osobiscie bym zrobil to teraz tak: query niech zwraca to resource, w type mixed zapisuj to tez we wlasciwosci klasy jak to robic, zas metody ala fetch: user moze podac nam ten resource albo nie. Jak nie poda to fetch wezmiej ostatni zapisyny we wlasciowosci klasy. Wtedy kod moze wyglada tak $con->query('blabla'); $con->fetch() Albo $res - $con->query('blabla'); $con->fetch($res) trochę za bardzo kombinujesz, ale pomysł jest sensowny. Jeśli query() będzie zwracać resource i zapisywać go w właściwości klasy, metody jak fetch() będą mogły działać bez konieczności przekazywania parametru. Takie podejście uprości kod i sprawi, że będzie bardziej elastyczny. Można to zrobić na dwa sposoby, jak zaproponowałeś, czyli albo z automatycznym pobieraniem ostatniego zapisanego resource, albo z opcją przekazania własnego. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 12.10.2025 - 16:07 |