Forum PHP.pl

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:



Interfejs Mail jest implementowany przez Email:



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:



Wypadałoby dodać jeszcze inne interfejsy dla moich klas tutaj? Trochę nie czuję, gdzie powinienem stosować interfejsy...

1) Napisales ktore klasy implementuja ktore interfejsy, ale wchodzac w ich kod, nie widze zadnej implementacji.
2) Po co ten przedrostek "db" ?
3)
public function dbQuery(string $query): mixed
{
return mysqli_query($this->mysqlLink, $query);
}

Ta metoda powinna zwracac bool a nie zasob mysqli. Po to sie robi interfejsy, by klasa byla uniwersalna a nie ty wymuszasz na nas znajmosc faktu iz zwraca jakis zasob mysqli. Mnie, jako uzytkownika tej klasy guzik obchodzic powinno czy to mysqli, czy mysql czy pdo. wykonuje query, a potem chce pobrac rekordy z tego query. wiec np. ten zasob powinien byc trzymany w klasie.
Z drugiej strony, moze byc faktycznie sytuacja, gdzie na raz wykonujesz dwa zapytania, np petla w petli i wtedy ten zasob jest potrzebny. No ale to mozna rozwiazac inaczej, np. klasa nie zwraca zasob ale number zasobu, i zasoby nadal so trzymany w klasie w tablicy, albo jak chcesz zwracac zasob, to moze warto tez zrobic to na interfejscie DBResource
4) interface Mysqli
Nie, masz zrobic interface DB, a potem klase MysqlI ktore go implementuje. Interfacy sluza by mowic o czym ogolnie, a nie robisz interface pod dana klase od razu

Poprawiłem (szczegóły tutaj):







Ten post edytował eerie 3.03.2025, 17:40:26

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.

Poprawione: https://github.com/EEQSOFT/framework.eeq/tree/main/src

Teraz powinno być dobrze...

No niestety czasami tak mam. Raz wychodzi na dobre, raz niekoniecznie


prawie

popraw to
public function connect(): void
{
$this->mysqlLink = @mysqli_connect(
$this->mysqlHost,
$this->mysqlUser,
$this->mysqlPassword,
'',
$this->mysqlPort
) or die('Could not connect to MySQL');

mysqli_select_db($this->mysqlLink, $this->mysqlDatabase)
or die('Could not choose the database');

mysqli_set_charset($this->mysqlLink, $this->mysqlNames);
}

wywal te malpe or wywal te die(). zadna klasa nie powinna konczyc w tak drastyczny sposob aplikacji. Zamiast tego rzucaj wyjatkiem i to niech aplikacja sie martwi co dalej a nie klasa

A nie lepiej po prostu przejść na pdo, albo chociaż obiektowe mysqli?

Pewnie byłoby lepiej, ale na razie nie chce mi się zmieniać...


Po usunięciu małpy wywala ostrzeżenie, więc zostawiłem. Zamiast die() dałem "throw new AppException()" (Mysqli). Wyjątek obsłużyłem w głównym pliku, gdzie tworzę obiekt kontrolera (index.php).

Jakie ostrzezenie? Ostrzezenia sie naprawia a nie wylacza ich wyswietlanie


Milion razy duplikujesz tam try catch... zrob jeden a nie w kazdym case osobno.
No i appka powinna przekierowac wowczas na strone z bledem a nie echo "nie dziala"; exit. No tak sie nie robi

Po włączeniu samego php, bez bazy danych, wyświetla mi bez małpy takie coś:


Moim zdaniem nic na to nie poradzę, a info niepotrzebnie się dubluje...


Pewnie mi się znowu dostanie, ale zrobiłem to w głównym public dla głównego require() [index.php].


Ja tę app'kę traktuję na razie edukacyjnie. Jak będzie sens, to kiedyś to przerobię bardziej profesjonalnie.

Odnosnie bledu i malpy. Nie uzywaj malp. Zamiast tego napisz swoj wlasny error handler i zamiast bledy wyswietlac, to zapisuj do np. pliku

https://www.php.net/manual/en/function.set-error-handler.php

Dzięki za podpowiedź. Miałem dzisiaj trochę wolnego czasu i zastosowałem to rozwiązanie. Usunąłem małpę i zapisuję błędy do pliku. Wyświetlam też komunikat użytkownikowi, że cos poszło nie tak, na oddzielnej stronie, jak sugerowałeś.

Nie
print_r($logData, 1);

a
print_r($logData, true);

Drugi argument to BOOL a nie INT. Ja wiem, ze php to mapuje, ale jak kiedys php wkoncu wlaczy super strict mode, to sie zdziwisz

No i to co w error.php to tez to powinna byc klasa a nie funkcje. Nie idz na latwizne

Ok. Dzięki za uwagi. Poprawione.