Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [PHP]OOP - kilka pytań o sens i poprawność "mojego" kodu
Forum PHP.pl > Forum > Przedszkole
sadistic_son
5.01.2023, 10:17:43
Cześć,
Przerobiłem na własne potrzeby kod z ksiązki ale nie do końca rozumiem, czy robię to logicznie. Generalnie to kod działa, ale sądzę, że mam tam zbędne kawałki. dodatkowo pytanie - czy to w ogóle tak powinno wyglądać?

klasa PageDisplay:
[PHP] pobierz, plaintext 
  1. namespace nameOne;
  2.  
  3. class PageDisplay
  4. {
  5.     private $request;
  6.     private $post;
  7.     private $get;
  8.  
  9.     public function __construct($request)
  10.     {
  11.         $requestString = \explode("?", $request);
  12.         $this->request = empty($requestString) ? $request : $requestString[0];
  13.     }
  14.     public function processRequest()
  15.     {
  16.  
  17.         if (!$this->request) {
  18.             return;
  19.         }
  20.  
  21.         $this->post = filter_input_array(INPUT_POST, FILTER_SANITIZE_STRING);
  22.         $this->get = filter_input_array(INPUT_GET, FILTER_SANITIZE_STRING);
  23.  
  24.         switch ($this->request) {
  25.             case "/":
  26.                 $title = 'Product List';
  27.                 $pageContent = "ProductList";
  28.                 include("ProductList.php");
  29.                 break;
  30.             case SUBDOMAIN."add-product":
  31.                 $title = 'Product Add';
  32.                 $pageContent = "ProductAdd";
  33.                 include("ProductAdd.php");
  34.                 break;
  35.             case "/mass_delete":
  36.                 //metoda massDelete
  37.                 break;
  38.             case "/save":
  39.                 //metoda save new product
  40.                 break;
  41.             default:
  42.                 $title = 'Product List';
  43.                 $pageContent = "ProductList";
  44.                 include("ProductList.php");
  45.                 break;
  46.  
  47.         }
  48.         $this->displayHeader($title);
  49.         require('views/' . $pageContent . '.view.php');
  50.         $this->displayFooter();
  51.     }
  52.  
  53.  
  54.     private function displayHeader($title)
  55.     {
  56.         require_once("views/html/header.html");
  57.     }
  58.  
  59.  
  60.     private function displayFooter()
  61.     {
  62.         require_once("views/html/footer.html");
  63.  
  64.     }
  65.  
  66. }
[PHP] pobierz, plaintext


Teraz w index.php mam wywołanie tej klasy i metod:
[PHP] pobierz, plaintext 
  1. include("PageDisplay.php");
  2. $page = new PageDisplay($_SERVER['REQUEST_URI']);
  3. $page->processRequest();
[PHP] pobierz, plaintext


Moje pytania.

1. Uważam, że obiekt klasy PageDisplay jest zbędny. Skoro odwołuję się tylko do jej metod to przerobiłbym processRequest() , displayHeader($title) oraz displayFooter() na metody statyczne i w index.php odwoływałbym się do PageDisplay::processRequest Ma to sens?

2. Czy w $page = new PageDisplay($_SERVER['REQUEST_URI']); powinienem jako paramert podać właśnie REQUEST_URI? Właściwie tylko to działa....

3. Jak mam się odwoływać do $_POST czy $_GET w reszcie kodu ? No bo już nie tradycyjnie if(isset($POST['add'])){ //add(); } skoro mamy taki zapis $this->post = filter_input_array(INPUT_POST, FILTER_SANITIZE_STRING);

Trochę się w tym pogubiłem i potrzebuję naprowadzenia. Dzięki z góry.
nospor
5.01.2023, 10:39:29
- Brakuje typowania
- jak zwykle nazwy zmiennych z 4 liter
przyklady: $request i $this->request
przeciez te zmiennej nazywaja sie tak samo a zawieraja zupelnie co innego

albo to:
$requestString = \explode("?", $request);
przeciez explode zwraca tablice a ty zmienna nazwales string, jakby zawierala tekst.

- case SUBDOMAIN."add-product":
klasa nie powinna miec wiedzy o jakies tam stalej SUBDOMAIN

- do GET/POST powinnienies miec oddzielna klase

- i nie, unikaj metod statycznych

- $this->request = empty($requestString) ? $request : $requestString[0];
explode zawsze zwraca tablice z przynjamniej jednym elementem wiec nigdy nie bedzie puste wiec twoj kod moze wygladac tak:
$this->request = $requestString[0];
pomijajac rzecz jasna nazewnictwo o ktorym juzpisalem

- no i badz konsekwentny, jak juz uzywasz glownego namespace dla explode, to uzywaj i dla empty czy tam innych metod z glownego namespace
sadistic_son
5.01.2023, 10:47:40
Cytat(nospor @ 5.01.2023, 10:29:53 ) *
- Brakuje typowania
Ma być wszędzie? Do każdej zmiennej i metody? To chyba stosunkowo nowe podejście, bo jak zaczynałem przygodę z php w 2006 to wtedy było mówione, że w php tego robić nie trzeba. A przynajmniej tak pamiętam..

Cytat(nospor @ 5.01.2023, 10:29:53 ) *
- jak zwykle nazwy zmiennych z 4 liter
Tylko $page, $get i $post mają mniej niż 5 liter (no i $this). To mam te 3 zmienne nazwać inaczej? Nie mówią same za siebie czym są?

Cytat(nospor @ 5.01.2023, 10:29:53 ) *
przyklady: $request i $this->request
przeciez te zmiennej nazywaja sie tak samo a zawieraja zupelnie co innego
Nie rozumiem. Jak tworzę private $request; i używam go w metodzie jako parametru, to odwołując się do $this->request odwołuję się do innej zmiennej?


Cytat(nospor @ 5.01.2023, 10:29:53 ) *
- $this->request = empty($requestString) ? $request : $requestString[0];
explode zawsze zwraca tablice z przynjamniej jednym elementem wiec nigdy nie bedzie puste wiec twoj kod moze wygladac tak:
$this->request = $requestString[0];
Ok, racja. Przepisałem to żywcem z książki, to widzę, że autor popełnił bubel.


Cytat(nospor @ 5.01.2023, 10:29:53 ) *
- case SUBDOMAIN."add-product":
klasa nie powinna miec wiedzy o jakies tam stalej SUBDOMAIN
Całą tą stonę mam w folderze, powiedzmy 'stronka'. Więc jej adres to localhost/stronka a po przeniesieniu na hosting będzie mójhosting.pl/stronka. Więc skoro korzystam z $_SERVER['REQUEST_URI'] to po wybraniu /add-product $_SERVER[REQUEST_URI'] zawiera /stronka/add-product. Jak inaczej w takim razie miałby wyglądać ten case skoro nie powinienem tam dodać SUBDOMAIN, które ma wartość '/stronka/' ?

Cytat(nospor @ 5.01.2023, 10:29:53 ) *
- do GET/POST powinnienies miec oddzielna klase
Dobra, się zrobi.

Cytat(nospor @ 5.01.2023, 10:29:53 ) *
- i nie, unikaj metod statycznych
Dlaczego? To zła praktyka? Mam zawsze tworzyć obiekt?


A moje pytania 2 i 3 ?


nospor
5.01.2023, 11:13:45
Cytat
Ma być wszędzie? Do każdej zmiennej i metody? To chyba stosunkowo nowe podejście, bo jak zaczynałem przygodę z php w 2006 to wtedy było mówione, że w php tego robić nie trzeba. A przynajmniej tak pamiętam..

Przez 17 lat BARDZO wiele sie zmienilo. Naprawde nie kieruj sie tym co ciebie wtedy uczono. Sam caly czas powtarzasz ze chcesz sie uczyc dobrych praktyk itp a ciagle mu z toba walczyc o to samo tongue.gif

Cytat
Tylko $page, $get i $post mają mniej niż 5 liter (no i $this). To mam te 3 zmienne nazwać inaczej? Nie mówią same za siebie czym są?

A czy ja cos mowilem o tych zmiennych? przeciez wyraznie napisalem co jest zle

Cytat
Nie rozumiem. Jak tworzę private $request; i używam go w metodzie jako parametru, to odwołując się do $this->request odwołuję się do innej zmiennej?

No teraz ja nie kumam. Gdzie cos takiego napisalem?

Cytat
Całą tą stonę mam w folderze, powiedzmy 'stronka'. Więc jej adres to localhost/stronka a po przeniesieniu na hosting będzie mójhosting.pl/stronka. Więc skoro korzystam z $_SERVER['REQUEST_URI'] to po wybraniu /add-product $_SERVER[REQUEST_URI'] zawiera /stronka/add-product. Jak inaczej w takim razie miałby wyglądać ten case skoro nie powinienem tam dodać SUBDOMAIN, które ma wartość '/stronka/' ?

To powinno byc przekazane w konstruktorze PAgeDisplay. Generalne zadne klasy nie powinny wiedziec co sie dzieje poza nimi, czyli nie powinny miedzy innymi znac jakie sa stale w twojej aplikacji. Klasa to zamkniety twor, jesli cos potrzebuje to dostaje to w konstruktorze

Cytat
Dlaczego? To zła praktyka? Mam zawsze tworzyć obiekt?

Tak, zla praktyka. Naprawde wyjatkowo sie zdarza ze musisz uzyc metody statycznej. Ja osobiscie tylko raz jej uzylem w jednym projekcie.


Cytat
A moje pytania 2 i 3 ?

Nie kumam pytania 2 a na 3 chyba ci juz odpowiedzialem przeciez.

Cytat
Całą tą stonę mam w folderze, powiedzmy 'stronka'. Więc jej adres to localhost/stronka a po przeniesieniu na hosting będzie mójhosting.pl/stronka. Więc skoro korzystam z $_SERVER['REQUEST_URI'] to po wybraniu /add-product $_SERVER[REQUEST_URI'] zawiera /stronka/add-product. Jak inaczej w takim razie miałby wyglądać ten case skoro nie powinienem tam dodać SUBDOMAIN, które ma wartość '/stronka/' ?

yy... ze jak? Co ma folder w ktorym znajduje sie twoja strona do adresu URL? No zdecydowanie cos zle robisz
sadistic_son
5.01.2023, 11:15:54
Tak, chcę się uczyć nowych dobrych praktyk. Ale jak coś zapamiętałem inaczej, a nie dowiedziałem się jeszcze że obecnie wygląda inaczej to dopytuję, nie kłócę się tongue.gif Ok, czyli typujemy zmienne. Kurde, sporo zmieniania kodu przede mną sad.gif Chyba zostawię to na koniec, na dopieszczanie kodu jak już wszystko będzie działać.



Cytat(nospor @ 5.01.2023, 10:39:29 ) *
przyklady: $request i $this->request
przeciez te zmiennej nazywaja sie tak samo a zawieraja zupelnie co innego
Ten fragment zrozumiałem, że $request oraz $this->request zawierają co innego, czyli to inne zmienne. Nie to miałes na myśli? Więc co?


Cytat(nospor @ 5.01.2023, 10:39:29 ) *
To powinno byc przekazane w konstruktorze PAgeDisplay. Generalne zadne klasy nie powinny wiedziec co sie dzieje poza nimi, czyli nie powinny miedzy innymi znac jakie sa stale w twojej aplikacji. Klasa to zamkniety twor, jesli cos potrzebuje to dostaje to w konstruktorze
A ok, czaję. Czyli tak?
[PHP] pobierz, plaintext 
  1. // (...)
  2. private $subdomain;
  3. // (...)
  4.     public function __construct($request)
  5.     {
  6. // (...)
  7.         $this->subdomain = SUBDOMAIN;
  8.     }
  9.  
  10. // (...)
  11.  
  12.             case $this->subdomain."add-product":
[PHP] pobierz, plaintext




Co do pytania 2 to...
Konstrukcja switch w klasie PageDisplay zakłada, że zostanie zaincludowane coś w zależności od tego co user kliknie, wpisze itd. Czyli założyłem, że jak wpisze strona.pl/stronka/add-product no to go przeniesie na stronę dodawania produkctu. W tym wypadku zczytuję z $_SERVER['REQUEST_URI'] to co user wpisał w pasku adresu, lub czy kliknął w link do tego adresu. Ale kiedy naciśnie on submit w formularzu przenoszącym do stronka.pl/stronka i prześle dane $_POSTem czy $_GETem (GET nie planuję używać) to jakoś muszę wychwycić, że np został naciśnięty submit i że wypełnił input. Stąd moje pytanie jak to w OOP realizować. Czy w switchu, w konkretnym case powinienem mieć jeszcze zwykłe if(isset($_POST['submit'] && $_POST['inputText'])) ? I z ostatnim zdaniem wiąże się moje 3. pytanie. Skoro mam utworzyć oddzielną klasę do obsługi post i get (nazwijmy ją requestProcessor) to mam się potem tak odwoływać do danych przesłanych z formularza?
[PHP] pobierz, plaintext 
  1. $dataFromForm = new RequestProcessor();
  2.  
  3. // zamiast if(isset($_POST['submit']))
  4. if(isset($dataFromForm->postArray['submit']))
[PHP] pobierz, plaintext
Dobrze rozumuję?
Moje pytania mogą być pokrętne bo w OOP czuję się trochę jak dziecko we mgle.
nospor
5.01.2023, 11:22:17
Cytat
Ale jak coś zapamiętałem inaczej, a nie dowiedziałem się jeszcze że obecnie wygląda inaczej to dopytuję, nie kłócę się

Sek w tym ze ci juz przynajmniej 3 raz o tym mowimy, wiec nie mow ze nie widziales tongue.gif
I nie, nie czekaj do konca, tylko poprawiaj na biezaco

Cytat
Ten fragment zrozumiałem, że $request oraz $this->request zawierają co innego, czyli to inne zmienne. Nie to miałes na myśli? Więc co?

No wlasnie to mialem na mysli. Skoro zawieraja co innego to czemu tak samo sie nazywaja?

Cytat
$this->subdomain = SUBDOMAIN;

No nie. Wyraznie mowie ma byc przekazane w konstuktorze a nie ustawione w konstruktorze.... Konstruktor to nadal klasa i konstuktor nie wie ze instnieje stala SUBDOMAIN.
public function __construct($request, $subdomain)
{
// (...)
$this->subdomain = $subdomain;
}


Ale jak juz pisalem w czesniej, cos masz zwalone, patrz ten komment:
"yy... ze jak? Co ma folder w ktorym znajduje sie twoja strona do adresu URL? No zdecydowanie cos zle robisz"


Cytat
Co do pytania 2 to...
Konstrukcja switch w klasie PageDisplay zakłada, że dostanie zaincludowane coś w zależności od tego co user kliknie, wpisze itd. Czyli założyłem, że jak wpisze strona.pl/stronka/add-product no to go przeniesie na stronę dodawania produkctu. W tym wypadku zczytuję z $_SERVER['REQUEST_URI'] to co user wpisał w pasku adresu, lub czy kliknął w link do tego adresu. Ale kiedy naciśnie on submit w formularzu przenoszącym do stronka.pl/stronka i prześle dane $_POSTem czy $_GETem (GET nie planuję używać) to jakoś muszę wychwycić, że np został naciśnięty submit i że wypełnił input. Stąd moje pytanie jak to w OOP realizować. Czy w switchu, w konkretnym case powinienem mieć jeszcze zwykłe if(isset($_POST['submit'] && $_POST['inputText'])) ? I z ostatnim zdaniem wiąże się moje 3. pytanie. Skoro mam utworzyć oddzielną klasę do obsługi post i get (nazwijmy ją requestProcessor) to mam się potem tak odwoływać do danych przesłanych z formularza?

REQUEST_URI zawiera ten "url", wiec ok. Ten "url" istnieje zarowno jak przeyslasz get i post wiec w czym problem?

Klase powinienes nazwac Request, jak to sie nazywa w kazdym normalnym FW. Klasa ta powinna ci zwracac twoje REQUEST_URI jak rowniez POST i GET. Moze tez miec metode isPost() ktore bedzie ci zwracala ci info czy to idzie get czy post itd
sadistic_son
5.01.2023, 11:56:51
Cytat(nospor @ 5.01.2023, 11:22:17 ) *
No wlasnie to mialem na mysli. Skoro zawieraja co innego to czemu tak samo sie nazywaja?
Ej no weź mnie pobij, ale teraz nie rozumiem. Albo ciebie, albo w ogóle rozminąłem się z jakimś sporym fragmentem traktującym o OOP.
[PHP] pobierz, plaintext 
  1. class PageDisplay
  2. {
  3.     private $request; //ten $request (1)
  4.  
  5.     public function __construct($request, $subdomain) /*ten $request (2)*/
  6.     {
  7.         $requestArray = explode("?", $request);
  8.         $this->request = $requestArray[0]; //ten $this->request (3)
  9.         $this->subdomain = $subdomain;
  10.     }
  11. }
[PHP] pobierz, plaintext
Zmienne (1), (2) i (3) nie zawierają tego samego? (1) i (2) tak, tak? Jak rozumiem mówisz, że (1,2) i (3) nie zawierają tego samego? Tak? Dobrze teraz rozumiem? Jesli tak to to wywraca moje pojmowanie... sad.gif




Cytat(nospor @ 5.01.2023, 11:22:17 ) *
No nie. Wyraznie mowie ma byc przekazane w konstuktorze a nie ustawione w konstruktorze....
(...)
Ok, już czaję. Thx.


Cytat(nospor @ 5.01.2023, 11:22:17 ) *
REQUEST_URI zawiera ten "url", wiec ok. Ten "url" istnieje zarowno jak przeyslasz get i post wiec w czym problem?
Klase powinienes nazwac Request, jak to sie nazywa w kazdym normalnym FW. Klasa ta powinna ci zwracac twoje REQUEST_URI jak rowniez POST i GET. Moze tez miec metode isPost() ktore bedzie ci zwracala ci info czy to idzie get czy post itd
Ok, tak zrobię. Do wyczyszczenia post z syfu od usera używam filter_input_array(INPUT_POST, FILTER_SANITIZE_STRING);
Czy do $_SERVER['REQUEST_URI'] oraz $_SERVER['HTTP_HOST'] też mam użyć FILTER_SANITIZE_STRING ? Zakładam też że nie filter_input_array bo to są stringi. Czy całą $_SERVER potraktować tym filter_input_array ?


Cytat(nospor @ 5.01.2023, 11:22:17 ) *
"yy... ze jak? Co ma folder w ktorym znajduje sie twoja strona do adresu URL? No zdecydowanie cos zle robisz"
Mam hosting o adresie stronka.pl
W nim mam foldery strona1 i strona2. W każdym z tych folderów index.php do obsługi zupełnie innych stron. Strona1 to forum budowlane a strona2 to portal o świnkach morskich smile.gif
No więc stronka.pl/strona1 to zupełnie co innego od stronka.pl/strona2 prawda?

A więc mam w config.php:
[PHP] pobierz, plaintext 
  1. // Define URL
  2. define("SUBDOMAIN", "/strona1/");
  3. define("PRODUCT_LIST_LANDING", "localhost" . SUBDOMAIN);
  4. define("PRODUCT_ADD_LANDING", "localhost" . SUBDOMAIN . 'add-product');
  5. //na razie localhost, bo jak się przeniosę na strona.pl to zmienię 'localhost' na 'strona.pl'
[PHP] pobierz, plaintext
A w formularzu:
[HTML] pobierz, plaintext 
  1. <form method="POST" name="productAddForm" action="http://<?= PRODUCT_LIST_LANDING ?>">
  2. (...)
  3.             <button type="button"
  4.                 onclick="location.href='http://<?= PRODUCT_LIST_LANDING ?>add-product';" />ADD</button>
[HTML] pobierz, plaintext
viking
5.01.2023, 12:04:03
A dlaczego tych oddzielnych stronek nie wstawisz jako oddzielne subdomeny? Dla bezpieczeństwa i czytelności nie powinny być nawet dostępne publiczne, a zakładam że przy takiej strukturze są.
Popatrz sobie też na jakieś przykładowe klasy np https://github.com/laminas/laminas-http/tree/2.19.x/src
https://github.com/illuminate/http
nospor
5.01.2023, 12:14:13
ja mowie o $request przekazanej w konstuktorze i o $this->request ( private $request;).
Ok, w wszczegolnym przypadku beda mialy to samo, ale generalnie $reqiest zawiera twoje URI a $this->request tylko kawalek.
Wiec $reqiest w konstuktorze powinno sie nazywac $uri a $this->reqiest powinno sie nazywac no nie wiem $this->shortUri
ROzumiesz oczym teraz mowie?

Cytat
Ok, tak zrobię. Do wyczyszczenia post z syfu od usera używam filter_input_array(INPUT_POST, FILTER_SANITIZE_STRING);

Nie powinno sie uzywac globalnie takich funkcji. Czasami, a w zadsadzie bardzo czesto, chcesz wkladac do bazy dokladnie to co user ci wpisal a nie wyfiltrowane. Filtrujesz tylko wtedy kiedy potrzeba. Takie globalne robienie wszystkiego to syf w kodzie.

Cytat
Czy do $_SERVER['REQUEST_URI'] oraz $_SERVER['HTTP_HOST'] też mam użyć FILTER_SANITIZE_STRING ? Zakładam też że nie filter_input_array bo to są stringi. Czy całą $_SERVER potraktować tym filter_input_array ?

Patrz wyzej

Cytat
Mam hosting o adresie stronka.pl
W nim mam foldery strona1 i strona2. W każdym z tych folderów index.php do obsługi zupełnie innych stron. Strona1 to forum budowlane a strona2 to portal o świnkach morskich smile.gif
No więc stronka.pl/strona1 to zupełnie co innego od stronka.pl/strona2 prawda?

No i wlasnie masz zle. Kazda stronka powinna miec swoja konfiguracje, swoja domene/subdomene (jak to napisal viking) i jej katalog powinieni byc ustawony jako katalog startowy. Wowczas twoj URI zawsze wyglada tak samo
Johnas
5.01.2023, 12:29:34
Cytat(sadistic_son @ 5.01.2023, 11:56:51 ) *
Ej no weź mnie pobij, ale teraz nie rozumiem. Albo ciebie, albo w ogóle rozminąłem się z jakimś sporym fragmentem traktującym o OOP.



Ludzie... Ile zapytań odnośnie jednego requesta... chodzi o to że w posiadając tak samo nazwane zmienne będziesz się mylić odnośnie ich stosowania...

Przeczytałem nową lekturę i też zauważyłem że mam duże braki... już wiem co muszę nadrobić...

https://itporady.pl/php-mysql/nowosci-w-php-82
sadistic_son
5.01.2023, 12:31:49
Cytat(nospor @ 5.01.2023, 12:14:13 ) *
ja mowie o $request przekazanej w konstuktorze i o $this->request ( private $request;).
Ok, w wszczegolnym przypadku beda mialy to samo, ale generalnie $reqiest zawiera twoje URI a $this->request tylko kawalek.
Wiec $reqiest w konstuktorze powinno sie nazywac $uri a $this->reqiest powinno sie nazywac no nie wiem $this->shortUri
ROzumiesz oczym teraz mowie?

Tak , terqz juz rozumiem. $request w konstruktorze już nie jest tym samym co $this->request skoro zostało potraktowane $this->request = $requestArray[0]; więc powinno nazywać się inaczej. Dzięki.

Cytat(nospor @ 5.01.2023, 12:14:13 ) *
Nie powinno sie uzywac globalnie takich funkcji. Czasami, a w zadsadzie bardzo czesto, chcesz wkladac do bazy dokladnie to co user ci wpisal a nie wyfiltrowane. Filtrujesz tylko wtedy kiedy potrzeba. Takie globalne robienie wszystkiego to syf w kodzie.
Dobra, to jak zabiorę się za zczytywanie danych z formularzy i przetwarzanie ich to się zagłębie w temat, i pewnie pojawią się kolejne tematy w tej sprawie wink.gif


Cytat(nospor @ 5.01.2023, 12:14:13 ) *
No i wlasnie masz zle. Kazda stronka powinna miec swoja konfiguracje, swoja domene/subdomene (jak to napisal viking) i jej katalog powinieni byc ustawony jako katalog startowy. Wowczas twoj URI zawsze wyglada tak samo

Fak, to o tym nawet nie wiedziałem. Nigdy sobie tym głowy nie zaprzątałem, bo w sumie nie uważałem nawet za potrzebne, skoro po moich stronkach latają tylko nieobeznani znajomi, lub ewentualnie to jakieś wizytówki small biznesów, bez formularzy nawet. Ale trzeba będzie to wszystko kiedys poprawić żeby było po bożemu.

Dzięki nospor i viking za pomoc.


EDIT: Z artykułu podanego przez Johnasa to jest ciekawe:

Wersja PHP 8.1 wprowadziła modyfikator readonly do właściwości klas. Wersja PHP 8.2 wprowadza ten modyfikator do oznaczenia klasy, dzięki czemu można skrócić zapis i nie oznaczać po kolei wszystkich właściwości klas jako readonly.
[PHP] pobierz, plaintext 
  1. class User
  2. {
  3.     public function __construct(
  4.         public readonly string $firstName,
  5.         public readonly integer $status,
  6.         public readonly DateTime $createdAt,
  7.     ) {}
  8. }
[PHP] pobierz, plaintext

Wersja w PHP 8.2 może wyglądać następująco:
[PHP] pobierz, plaintext 
  1. readonly class User
  2. {
  3.     public function __construct(
  4.         public string $firstName,
  5.         public integer $status,
  6.         public DateTime $createdAt,
  7.     ) {}
  8. }
[PHP] pobierz, plaintext
Johnas
5.01.2023, 12:57:55
Cytat(sadistic_son @ 5.01.2023, 12:31:49 ) *
EDIT: Z artykułu podanego przez Johnasa to jest ciekawe:

Wersja PHP 8.1 wprowadziła modyfikator readonly do właściwości klas. Wersja PHP 8.2 wprowadza ten modyfikator do oznaczenia klasy, dzięki czemu można skrócić zapis i nie oznaczać po kolei wszystkich właściwości klas jako readonly.
[PHP] pobierz, plaintext 
  1. class User
  2. {
  3.     public function __construct(
  4.         public readonly string $firstName,
  5.         public readonly integer $status,
  6.         public readonly DateTime $createdAt,
  7.     ) {}
  8. }
[PHP] pobierz, plaintext

Wersja w PHP 8.2 może wyglądać następująco:
[PHP] pobierz, plaintext 
  1. readonly class User
  2. {
  3.     public function __construct(
  4.         public string $firstName,
  5.         public integer $status,
  6.         public DateTime $createdAt,
  7.     ) {}
  8. }
[PHP] pobierz, plaintext


tak, ale chyba również powinieneś określać typ zwracanych danych. Dla przykładu:

[PHP] pobierz, plaintext 
  1. readonly class User
  2. {
  3.     public function __construct(public integer $status) : int
  4.     {
  5.         retutn $status;
  6.     }
  7. }
[PHP] pobierz, plaintext



Edit: Na 100% źle to napisałem, bo sam nie mam teraz przykładu
sadistic_son
5.01.2023, 13:30:02
Ale to co ja wekleiłem to jest żywcem z tej strony co podałeś biggrin.gif
nospor
5.01.2023, 13:30:38
Cytat
Edit: Na 100% źle to napisałem, bo sam nie mam teraz przykładu

Dla konstruktora nie okresla sie typu zwracanych danyc, a dla Sadistica juz pisalem o typowaniu zarowno parametrow jak i zwracanych typow
Johnas
5.01.2023, 19:01:20
Cytat(sadistic_son @ 5.01.2023, 13:30:02 ) *
Ale to co ja wekleiłem to jest żywcem z tej strony co podałeś biggrin.gif

Wiem, ja chciałem naprowadzić Ciebie na to o czym mówił nospor smile.gif

Cytat(nospor @ 5.01.2023, 13:30:38 ) *
Dla konstruktora nie okresla sie typu zwracanych danyc, a dla Sadistica juz pisalem o typowaniu zarowno parametrow jak i zwracanych typow


wiem, dlatego też próbowałem napisać funkcję przykładową, ale siedzę w bibliotece bo nie ładuje mi macbooka i nie mam tutaj phpstorma - on doskonale podpowiada jak powinna być napisana składnia klasy tongue.gif
Salvation
5.01.2023, 19:19:51
Cytat(Johnas @ 5.01.2023, 19:01:20 ) *
(...) nie mam tutaj phpstorma - on doskonale podpowiada jak powinna być napisana składnia klasy tongue.gif

OMG xDDD co my, jako programiści, byśmy zrobili bez inteligentnego IDE xDDD

Takie rzeczy powinieneś sam wiedzieć, a nie bazować na podpowiedzi programu, w którym pracujesz.
Johnas
5.01.2023, 19:42:59
Cytat(Salvation @ 5.01.2023, 19:19:51 ) *
OMG xDDD co my, jako programiści, byśmy zrobili bez inteligentnego IDE xDDD

Takie rzeczy powinieneś sam wiedzieć, a nie bazować na podpowiedzi programu, w którym pracujesz.



Dzięki za radę, teraz już wiem że powinienem wiedzieć 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.