Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

2 Stron V  < 1 2  
Reply to this topicStart new topic
> URL shortener - Symfony 4.
athabus
post 24.09.2018, 19:22:12
Post #21





Grupa: Zarejestrowani
Postów: 898
Pomógł: 48
Dołączył: 2.11.2005
Skąd: Poznań

Ostrzeżenie: (0%)
-----


Czy ja wiem czy zle zaprojektowany. Php ma w sobie dynamike i czasem po prostu nie da sie twardo typowac (albo nie ma to sensu). Tak jak pisalem przyklad z dzisiaj - na wejsciu do kontenera DI mialem konfiguracje w postaci tablicy. Tablica zawierala parametry, ktore wykorzyatywalo reflection api do inicjalizacji klas. Co by nie zrobic to getter do takiej tablicy bedzie zwracal praktycznie dowolny typ danych. Object tu tematu nie rozwiaze, bo w takiej tablicy moga byc skalary, tablice, obiekty/kolejcje obiektow - praktycznie wszystko.
Od czasu jak narzucilem sobie typowanie udalo mi sie 90% sytuacji tak zorganizowac aby funkcja zwracala 1 i tylko 1 typ danych, co z perspektywy uwazam za super rozwiazanie, bo api metod i czytelnosc kodu na tym zyskaly. Ale w swiecie php zawsze znajdzie sie taki przypadek, ktorego nie da sie przerobic albo nie ma to sensu. Getter do rozbudowanej konfiguracji jest IMO takim przypadkiem.
Skoro jest void to i mixed moim zdaniem tez powinno byc aby zachowac jednolity interfejs. W php mixed to tez typ danych w pewnyn sensie smile.gif

Ten post edytował athabus 24.09.2018, 19:25:16
Go to the top of the page
+Quote Post
nospor
post 25.09.2018, 10:36:37
Post #22





Grupa: Moderatorzy
Postów: 36 440
Pomógł: 6290
Dołączył: 27.12.2004




Cytat
Object tu tematu nie rozwiaze, bo w takiej tablicy moga byc skalary, tablice, obiekty/kolejcje obiektow
Rozwiaze o tyle, ze mozesz zwracac obiekt, ktory bedzie mial te rozna wartosc w sobie. No ale potem get() w tym obiekcie znowu i tak bedzie zwracal mixed hehe wink.gif
No ok, jest te pare sytuacji gdzie moze i faktycznie nie da sie okreslic typu.


--------------------

"Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista
"Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer

Go to the top of the page
+Quote Post
Pyton_000
post 25.09.2018, 16:58:11
Post #23





Grupa: Zarejestrowani
Postów: 8 068
Pomógł: 1414
Dołączył: 26.10.2005

Ostrzeżenie: (0%)
-----


Nie ma takiej sytuacji że nie da się tego opisać jednolitym typem danych. IMO kwestia znalezienia rozwiązania.
Go to the top of the page
+Quote Post
borabora
post 27.09.2018, 07:21:27
Post #24





Grupa: Zarejestrowani
Postów: 116
Pomógł: 33
Dołączył: 8.09.2014

Ostrzeżenie: (0%)
-----


Cytat(Pyton_000 @ 25.09.2018, 17:58:11 ) *
Nie ma takiej sytuacji że nie da się tego opisać jednolitym typem danych. IMO kwestia znalezienia rozwiązania.


a co myslicie o czymś takim? okreslony typ ewentulnie null, czy lepszym rozwiazaniem są exceptiony?

  1. public function nazwa(?JakiśTypObiektu $obiekt): ?string
  2. {}
Go to the top of the page
+Quote Post
Pyton_000
post 27.09.2018, 07:34:34
Post #25





Grupa: Zarejestrowani
Postów: 8 068
Pomógł: 1414
Dołączył: 26.10.2005

Ostrzeżenie: (0%)
-----


Null jest dość specyficzny. Ale taki prototyp funkcji nic w sumie nie mówi. Wszystko zależy od tego jak zaprojektujesz. Często tak, Exception załatwia sprawę, a czasami nie. Więc kontekst jest ważny smile.gif

Taki prototyp często jest używany w Entity gdzie początkowy stan obiektu zwraca null na wszystkim niemal. Więc o ile coś + null jest w miaaarę powiedzmy ok, o tyle int+string+object+.... już nie...
Go to the top of the page
+Quote Post
athabus
post 7.10.2018, 14:55:56
Post #26





Grupa: Zarejestrowani
Postów: 898
Pomógł: 48
Dołączył: 2.11.2005
Skąd: Poznań

Ostrzeżenie: (0%)
-----


Cytat(Pyton_000 @ 25.09.2018, 17:58:11 ) *
Nie ma takiej sytuacji że nie da się tego opisać jednolitym typem danych. IMO kwestia znalezienia rozwiązania.

Ale uważasz, że zawsze jest sens walczyć o silne typowanie? PHP to jest język dynamiczny i KIEDY MA TO SENS warto korzystać z możliwości, które daje. O ile jestem zazwyczaj przeciwnikiem funkcji zwracających wszystkie możliwe typy danych, to czasami na to po prostu sens - np. wspomniana konfiguracja, która może przechowywać zarówno typy proste jak i obiekty. To bardzo generyczny obiekt i MZ nie ma sensu dla idei walczyć o typowanie. Oczywiście jeśli się mylę, to chętnie poznam argumenty i jakieś sensowne podejście do tego tematu w PHP.

Zaciekawił mnie kolejny wątek - czyli null (+ wartości domyślne, z którymi się poniekąd wiąże). Co do zasady jestem zwolennikiem, że funkcja nie powinna zwracać null, gdy jest to możliwe. Sztandarowy przykład - wolę zwrócić pusta tablicę niż null. Oczywiście znów nie zawsze jest sens o to walczyć i w praktyce mimo wszystko często stosuję null (zamiast np. stosować null object), ale zawsze 2 razy się zastanawiam, czy nie da się tego rozwiązać lepiej.
Exceptiony MZ zazwyczaj nie są dobrym wyjściem - Exception jak sama nazwa wskazuje powinien obrazować zjawisko wyjątkowe, a np. brak odczytanych rezultatów z bazy zazwyczaj nie jest zjawiskiem wyjątkowym - np. brak produktów w sklepie w danej kategorii. Oczywiście może takim być - np. loguje się użytkownik i nagle się okazuje, że nie ma tabeli z jego ACL'ami, a logika aplikacji zakłada, że każdy użytkownik ma tam jakieś wpisy - wtedy oczywiście Exception jest ok.

Ostatnio też miałem dość ciekawą rozmowę na temat domyślnych wartości argumentów w funkcjach. Do tej pory stosowałem je na potęgę z 2 głupich powodów:
- mniej pisania w kodzie klienckim
- w czasie refactoringu, gdy dochodził parametr stosowałem wartość domyślną aby nie trzeba modyfikować kodu klienckiego

Rozmowa otworzyła mi oczy, że głupio robiłem. Po pierwsze kod kliencki musi wiedzieć co chce zrobić i im mniej tam przerzucania odpowiedzialności na "inteligencję" swoich klas/funkcji tym lepiej, bo pomaga to zapobiegać efektom ubocznym. Przeróbka koda klienckiego przy refactoringu dzisiaj też jest prosta, więc nie jest to argument za stosowaniem wartości domyślnych. Przede wszystkim jednak ciekawym doświadczeniem było zaprzestanie używania wartości domyślnych w swoim kodzie. Po 2-3 dniach okazało się, że w 95% przypadków można pozbyć się tego brzydactwa.

Dlatego ogólnie na dzisiaj moja opinia jest taka - null / wartości domyślne powinno się stosować ale z umiarem. Zawsze się warto zastanowić czy robimy to z wygody, czy z realnej potrzeby.

Ogólnie muszę przyznać, że dużo w moim kodzie poprawiło stosowanie się do zasady YAGNI i polubienie się z refactoringiem. Wiele problemów typu domyślne wartości parametrów często się same rozwiązują, bo np. zakładamy, że dzisiaj co prawda parametr będzie zawsze taki sam (i dlatego dajemy u default value) ALE KIEDYŚ to się zmieni. W praktyce okazuje się, że w 9 na 10 sytuacji to się nigdy już nie zmieni, albo funkcję przepiszemy jescze 3 razy zanim się zmieni i zostajemy z parametrem, który w ogóle nie jest do niczego potrzebny.
Go to the top of the page
+Quote Post

2 Stron V  < 1 2
Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 28.03.2024 - 18:39