Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [PHP] Jak stosować interfejsy?
Forum PHP.pl > Forum > PHP > Object-oriented programming
eerie
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...
nospor
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
eerie
Poprawiłem (szczegóły tutaj):

Kod
<?php

declare(strict_types=1);

namespace App\Core;

interface Database
{
    public function connect(): void;
    public function close(): void;
    public function query(string $query): bool;
    public function result(): mixed;
    public function fetchArray(mixed $result): array|null|false;
    public function numberRows(mixed $result): int;
    public function affectedRows(): int;
    public function insertId(): int;
    public function startTransaction(): bool;
    public function commit(): bool;
    public function rollback(): bool;
}


Kod
<?php

declare(strict_types=1);

namespace App\Core;

class Mysqli implements Database
{
    [...]

    public function query(string $query): bool
    {
        $this->mysqlResult = mysqli_query($this->mysqlLink, $query);

        return (bool) $this->mysqlResult;
    }

    public function result(): mixed
    {
        return $this->mysqlResult;
    }

    [...]
}


Kod
abstract class Controller
{
    [...]

    public function setManager(string $name = 'Mysqli'): void
    {
        if (!isset($this->manager[$name])) {
            $this->database[$name] = new $name($name);
            $this->manager[$name] = new Manager($this->database[$name]);

            $this->database[$name]->connect();
        }
    }

    public function getManager(string $name = 'Mysqli'): Manager
    {
        $this->setManager($name);

        return $this->manager[$name];
    }

    [...]
nospor
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)
Loguss
Cytat(nospor @ 3.03.2025, 18:00:06 ) *
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.
eerie
Poprawione: https://github.com/EEQSOFT/framework.eeq/tree/main/src

Teraz powinno być dobrze... smile.gif
nospor
Cytat
trochę za bardzo kombinujesz, ale pomysł jest sensowny

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

Cytat
Teraz powinno być dobrze..

prawie wink.gif

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
viking
A nie lepiej po prostu przejść na pdo, albo chociaż obiektowe mysqli?
eerie
Cytat
A nie lepiej po prostu przejść na pdo, albo chociaż obiektowe mysqli?

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

Cytat
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

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).
nospor
Cytat
Po usunięciu małpy wywala ostrzeżenie, więc zostawiłem.

Jakie ostrzezenie? Ostrzezenia sie naprawia a nie wylacza ich wyswietlanie

Cytat
Wyjątek obsłużyłem w głównym pliku, gdzie tworzę obiekt kontrolera (index.php).

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 wink.gif
eerie
Cytat
Jakie ostrzezenie? Ostrzezenia sie naprawia a nie wylacza ich wyswietlanie

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

Cytat
Warning: mysqli_connect(): (HY000/2002): Nie można nawiązać połączenia, ponieważ komputer docelowy aktywnie go odmawia in C:\Work\Domain\framework.eeq\src\Core\Mysqli.php on line 38
Could not connect to MySQL

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

Cytat
Milion razy duplikujesz tam try catch... zrob jeden a nie w kazdym case osobno.

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

Cytat
No i appka powinna przekierowac wowczas na strone z bledem a nie echo "nie dziala"; exit. No tak sie nie robi wink.gif

Ja tę app'kę traktuję na razie edukacyjnie. Jak będzie sens, to kiedyś to przerobię bardziej profesjonalnie. wink.gif
nospor
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
eerie
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ś. smile.gif
nospor
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 wink.gif

No i to co w error.php to tez to powinna byc klasa a nie funkcje. Nie idz na latwizne wink.gif
eerie
Ok. Dzięki za uwagi. Poprawione. smile.gif
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.