URL shortener - Symfony 4. |
URL shortener - Symfony 4. |
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 Ten post edytował athabus 24.09.2018, 19:25:16 |
|
|
25.09.2018, 10:36:37
Post
#22
|
|
Grupa: Moderatorzy Postów: 36 519 Pomógł: 6308 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 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 |
|
|
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.
|
|
|
27.09.2018, 07:21:27
Post
#24
|
|
Grupa: Zarejestrowani Postów: 116 Pomógł: 33 Dołączył: 8.09.2014 Ostrzeżenie: (0%) |
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?
|
|
|
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
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... |
|
|
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%) |
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. |
|
|
Wersja Lo-Fi | Aktualny czas: 26.09.2024 - 18:29 |