Polimorfiz polimorfizmem ale interface'y interface'ami. Szału dostaję jak mam poprawiać kod w którym są tuziny interface'ów. Interface z interface'ami a i w środku jeszcze interface'y, gdzie kod nigdy nie miał i nie będzie miał wielu różnych klas implementujących te interface'y i się kończy na relacji jeden interface - jedna klasa.
Moim zdaniem nie ma w tym nic złego. Może jest to jakieś złamanie YAGNI, ale też nie do końca, bo błąd tak naprawdę popełnia ten, kto z tych interfejsów nie korzysta.
Do tego jeszcze IOC dochodzi i przy dziesiątkach plików w projekcie szukaj sobie odpowiedniej klasy, której nazwa gdzieś w stringu w pliku konfiguracyjnym jest zapisana.
Konfiguracja IoC w plikach? Ale po co? :|
Rozumiem, że to przydaje się to gdy ktoś unit testy robi, tylko po co to, skoro tych unit testów nigdy nie było?
Skoro nie było testów, to co to za programista?
A potem szlag człowieka trafia, jak zamiast nacisnąć F12 i przejść do definicji klasy musi się w jakieś (ctrl + f)'y bawić.
No, trzeba przytrzymać dodatkowy klawisz... Od braku Vima ludziom się w głowach przewraca. ;P
Dziedziczenia są ok jeśli rozszerzacie istniejącą klasę, acz ostatnio spotkałem się też z przypadkiem, gdzie każda klasa dziedziczyła po klasie, która dziedziczyła z innej klasy, gdzie ostatecznie każda metoda z klasy środkowej, która była używana w klasie finalnej i tak musiała być napisana od nowa. Coś jak stworzenie abstrakcyjnej klasy z bazowej klasy, która przez zamieszanie z access modifierami tylko zagmatwała w kodzie, a usunąć jej nie można było, bo w wielu miejscach kodu były wywołania na klasie środkowej metod z klasy bazowej na instancji klasy w trzeciej hierarchii dziedziczenia.
O ile prościej byłoby, gdyby to sensownie zaprojektować na małych interfejsach. :)
W Visualu inteli widocznie nie jest takie inteligentne i z ctrl+space nie widzę dużej różnicy w liście wyników wpisując nazwę klasy, a inferface'u poza dodatkową literką na przedzie - z reguły wystarczy 3-4 litery by mieć większość elementów, które szukamy, a przy ostanio używanych wystarcza z reguły jedna.
Wydaje mi się, że @Shalom pisał o tym, że operując na zmiennej typu interfejsowego masz dostępnych mniej metod niż dla zmiennej typu klasy.
IInterfejs x = new Klasa();
Klasa y = new Klasa();
x. // mniej metod niż dla y.
Przy programowaniu w Visualu nie tylko ja się z tymi problemami spotkałem, acz i od kilku programistów już słyszałem, że się idzie zgubić w takim kodzie, gdzie za dużo jest interface'ów które praktycznie do niczego nie służą.
W każdym dużym kodzie idzie się zgubić. W klasach statycznych na 20k linii kodu i metodach tworzonych metodą copy-paste również. I moim zdaniem bardziej niż w kodzie, w którym odpowiedzialności są podzielone na wiele małych interfejsów.
Ogólnie masz rację - niepotrzebne interfejsy są niepotrzebne. Ale świadomy programista, który używa IoC i testów jednostkowych, tych interfejsów potrzebuje.