używanie nowopoznanego słowa kluczowego zupełnie bez sensu

W ostatniej pracy dla janusza spotkałam się w kodzie PHP z użyciem słowa kluczowego trait
Nie z użyciem traitu o którym w dokumentacji PHP jest napisane że pozwala na code reuse i jest odpowiednikiem znanego z C++ wielobazowego dziedziczenia.Wtedy byłby zdefiniowany trait, w tracie funkcje, które są potrzebne w różnych klasach, a których nie można odziedziczyć po wspólnym przodku, a następnie w każdej z nich use NaszTrait; I miałoby to sens. Piszący kod "innowator" zrobił inaczej, traktując traity chyba jako możliwość podzielenia kodu jednej klasy na kilka plików, coś co kiedyś robiło się za pomocą niepolecanego sposobu include . W każdym razie te traity , które tam się znajdowały były ściśle powiązane z logiką klasy która ich używała, nie było sensu ich wykorzystywać gdziekolwiek powtórnie.
Sztuka dla sztuki bym powiedziała, ale zarówno piszący to geniusz jak i nadzorujący niewyje* junior mogli (nie)zgodnie z prawdą twierdzić że w projekcie używali traitów
Co ciekawe wcale to nie jest bardzo nowa właściwość PHP, ale chyba mało popularna
Podobnie było z opisywanym kiedyś przeze mnie tu na forum przypadkiem użycia wyjątków w c# do sterowania normalnym przebiegiem programu wyjątki kompletnie bez sensu
o co chodzi z tym podejsciem? to nawet nie jest overengeeniering. To jest głupota
Zaczynam podejrzewać że rzeczoni juniorzy widzą gdzieś przykład. Np w dokumentacji do PHP. Przykład ma zobrazować najprostsze użycie danej rzeczy, więc jest pokazane:

• definicja traitu
• definicja klasy go używającej

tego co jest napisane powyżej i poniżej już nie przeczyta, wystarczy że ma przykład i myśli że już zgłębił temat. Czyżby trend który należałoby nazwać example driven programming?

Miang napisał(a):

Piszący kod "innowator" zrobił inaczej, traktując traity chyba jako możliwość podzielenia kodu jednej klasy na kilka plików, coś co kiedyś robiło się za pomocą niepolecanego sposobu include . W każdym razie te traity , które tam się znajdowały były ściśle powiązane z logiką klasy która ich używała, nie było sensu ich wykorzystywać gdziekolwiek powtórnie.

wg: https://www.php.net/manual/en/language.oop5.traits.php

Traits are a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance by enabling a developer to reuse sets of methods freely in several independent classes living in different class hierarchies.

Przy czym Ty uczepilas sie kurczowo:

... by enabling a developer to reuse sets of methods freely in several independent classes ...

kluczowe jest tu slowo by enabling czyli umozliwia. Widzisz tam gdzies slowo exclusively?
Z grubsza rzecz biorac traity utworzono w zalozeniu jako substytutu wielodziedziczenia, ale co w tym zlego ze ktos znalazl dla nich inne zastosowanie, bardzo zblizone do tego co jest napisane poniezej:

A Trait is similar to a class, but only intended to group functionality in a fine-grained and consistent way.

Zalozmy ze z jakiegos powodu (powtarzam "zalozmy, ze z jakiegos powodu") musisz utworzyc grupe mutatorow danych, ktorych zadaniem jest spiecie jedna klasa kilku procesow, np hydratacji, konwersji, formatowania etc jakiegos zestawu danych, z tym ze w kazdym przypadku hydratacja, konwersja i formatowanie odbywa sie inaczej.
Zalozmy ze jeden z takich mutatorow bylby 900 llinijkowym potworkiem.

Zamiast takiego 900 linijkowego potworka mozesz:

1. wstrzyknac klase hydratora, konwertera i formatera
2. podpiac traity hydratora, konwertera i formatera.

Na jakiej podstawie twierdzisz ze mozliwosci uzycia opcji nr 2. jest niedopuszczalna?

Ja widze dwie podstawowe korzysci takiego podejscia:

1. separacji funkcjonalnej kodu,
2. a w przypadku dependency injection, brak koniecznosci deklaracji explicit zaleznosci definiowanych interfejsami.

Reasumujac, gdzie jest napisane ze tak nie mozna?

To ze w docsach nie jest napisane wprost ze tak mozna, to zbyt slaby argument, wlasciwe zaden argument.

Pokaż mały kawałek kodu, który pokazuje co cię boli. Dyskusja bez szczegółów nie ma sensu

o co chodzi z tym podejsciem? to nawet nie jest overengeeniering. To jest głupota

Często jest tak, że ktoś bez ukształtowanego gustu programistycznego chłonie wszystko przyjmując przekaz za prawdę objawioną, bo to dobra strategia nauk dla początkującychi. Skoro jakiś mechanizm istnieje to trzeba go użyć, bo inaczej by nie istniał. Dopiero z czasem przychodzi doświadczenie i możliwość krytycznej oceny danego rozwiązania

Ja się w sumie zgadzam z @Miang, że to bez sensu.

Może to bez sensu, a może nie. Nie znam rzeczonego kodu, planów co do przyszłych zmian, ale jedną z możliwości jakie widzę, to jest to po prostu krok przygotowawczy (pogrupowanie funkcjonalności) przed przyszłymi zmianami.

yarel napisał(a):

Może to bez sensu, a może nie. Nie znam rzeczonego kodu, planów co do przyszłych zmian, ale jedną z możliwości jakie widzę, to jest to po prostu krok przygotowawczy (pogrupowanie funkcjonalności) przed przyszłymi zmianami.

True, ale gdyby ktoś chciał wydzielać wspólne fragmenty pod reuse, albo grupować kod pod separation of concerns, to znacznie lepiej to zrobić klasami i kompozycją IMHO.

Riddle napisał(a):

yarel napisał(a):

Może to bez sensu, a może nie. Nie znam rzeczonego kodu, planów co do przyszłych zmian, ale jedną z możliwości jakie widzę, to jest to po prostu krok przygotowawczy (pogrupowanie funkcjonalności) przed przyszłymi zmianami.

True, ale gdyby ktoś chciał wydzielać wspólne fragmenty pod reuse, albo grupować kod pod separation of concerns, to znacznie lepiej to zrobić klasami i kompozycją IMHO.

Nie znam PHP i bazuję na szybko wyszukanym opisie mechanizmu It is not possible to instantiate a Trait on its own. It is an addition to traditional inheritance and enables horizontal composition of behavior; Wydaje mi się, że nie kłóci się to z późniejszym przejściem na klasy i wygląda na mniej inwazyjne, co w przypadku znacznych zmian może być zaletą. Może ten kod jest mały i te traity są pozbawione sensu, a może ogromny kod i po prostu traity są małym krokiem do lepszego projektu.

Miang napisał(a):

o co chodzi z tym podejsciem? to nawet nie jest overengeeniering. To jest głupota

Wcale nie. Brzmi jak zaimplementowanie namespacingu od tylnej strony. Nieszablonowe podejścia to nie głupota a innowacyjność.

Ogólnie Trait - cecha, ma za zadanie wprowadzić cechę do obiektu.
Plusy - reużywalność, DRY
Minusy - reużywalność, czyli zmieniając trait zmieniany coś we wszystkich klasach i niektórzy mają tendencję do wpychania tam rzeczy, które we wszystkich klasach nie są używane. Kolizje nazw. W starszych wersjach PHP kolizje widoczności metod. Dużo cięższe testowanie (IMO oczywiście).

Nie znam kodu. Gdyby chociaż była opisana podstawowa funkcjonalność rzecznych klas i cech oraz ich rozwój. Czyli czy był to ośmiotysięcznik i idziemy w redukcję czy jakaś wizja idącą w złą stronę.
Ogólnie bym nie demonizował. Ktoś miał wizję, żeby to tak a nie Inaczej napisać. Z opisu nic nie wynika oprócz narzekania.

jurek1980 napisał(a):

Ogólnie Trait - cecha, ma za zadanie wprowadzić cechę do obiektu.
Plusy - reużywalność, DRY
Minusy - reużywalność, czyli zmieniając trait zmieniany coś we wszystkich klasach i niektórzy mają tendencję do wpychania tam rzeczy, które we wszystkich klasach nie są używane. Kolizje nazw. W starszych wersjach PHP kolizje widoczności metod. Dużo cięższe testowanie (IMO oczywiście).

+/- hybrydyzacja - obiekt implementujący dwa wykluczające się traity. W naturzy zwana wigorem mieszańców.