Refaktoruje ostatnio bardzo dużo słabego kodu w pracy i w trakcie usuwania duplikacji zacząłem się zastanawiać nad pewną kwestią. Załóżmy, że wydzielam sobie kod pewnego panelu GUI. Panel jest używany w wielu miejscach i jest generalnie identyczny, ale różni się:
- labelkami
- tooltipami
- akcjami jak ktoś cośtam kliknie na przykład
Gdyby tych parametrów było mało i gdyby nie było tam "akcji" to pewnie bez zastanowienia wrzucałbym je przez konstruktor. Liczbę parametrów zawsze można ograniczyć jakimś DTO ale to taki sobie pomysł bo to DTO nigdzie nie byłoby używane a jedynie tworzone w miejscu tworzenia panelu z parametrów znanych w chwili kompilacji. Więc dość słabo. Dodatkowo "akcje" trzeba by wrzucać jako jakieś lambdy albo funktory.
Dodatkowo część tych parametrów może być zostawiona jako domyślna, co mocno komplikuje opcje z konstruktorem, bo albo mamy mother of all constructors
a potem kupę nulli jako parametry albo mamy milion konstruktorów (mało możliwe bo niektóre parametry są tego samego typu ;) ).
W związku z tym pomyślałem że można to zrobić z zupełnie innej strony. Zrobić klasę abstrakcyjną z metodami w stylu getXYZTooltip()
a wymagane akcje zrobić jako metody abstrakcyjne. Wtedy tworząc obiekt musimy zaimplementować wymagane metody i ewentualnie przeładować te gdzie nie chcemy używać opcji domyślnych. Tylko że to rozwiązanie wydaje mi się trochę dziwne, bo jednak tworzymy nową klasę (choćby i anonimową) podczas gdy w rzeczywistości te klasy różnią się właściwie tylko parametrami (szczególnie jeśli uznamy lambdy za parametry).
Co o tym myślicie?
@somekind @Koziołek @Krolik @niezdecydowany @karolinaa @msm @winerfresh @stryku @Patryk27 @katelx @WhiteLightning @datdata @spartanPAGE @Wizzie @Azarien @Satirev @MarekR22 @Afish @panryz @Wibowit @azalut i więcej mi się nie chce wymieniać, ale niech się nikt nie czuje pominięty! (kolejność losowa!)