To tak nie działa. Ja wiem, że kiedy zna się wszystkie te elementy OOP to wszystko wygląda jak klasa bazowa.
Widocznie za mało elementów OOP znam, skoro nie zauważam takich objawów u siebie.
Abstrakcję wydzielamy tylko w momencie kiedy jest to niezbędne, to znaczy: inne części kodu polegają na tych abstrakcjach.
To taka trochę rekurencyjna definicja. :) Gdy wydzielisz abstrakcję, stanie się ona niezbędna, bo bez niej nie będzie działała reszta kodu. Gdy nie wydzielisz abstrakcji, to nie jest ona niezbędna, więc nie ma sensu jej nigdy wydzielać. :P
Dziedziczenie to jest konieczność, a nie zachcianka. Niepotrzebna abstrakcja zwiększa złożoność kodu i sprawia, że staje się mniej rozbudowywalny i utrzymywalny. Nigdy nie powinno się podchodzić do tematu na zasadzie: "te klasy mają takie same właściwości więc wydzielę interfejs/klasę bazową". Dziedziczenie to jest raczej coś czego chcemy unikać i stosujemy tylko wtedy kiedy jest taka potrzeba.
To w dużej mierze racja, tylko ja np. wciąż nie wiem, co tu tak naprawdę jest potrzebne, więc tworzenia hierarchii klas bym nie skreślał.
No i abstrakcja to nie są klasy bazowe/interfejsy, to nie ma ze sobą wiele wspólnego.
Dopiero kiedy w trakcie pisania kolejnych części kodu zajdzie taka potrzeba wydziel abstrakcję do interfejsu/klasy bazowej. Nie zwiększaj sobie złożoności kodu już na samym początku.
Istnienie klas nie zwiększa złożoności. Istnienie ifów owszem.
To jest mój twór - webapka do trackowania statystyk graczy na bieżąco.
Zagrywki ma wprowadzać użytkownik (najpewniej będą przychodzić jsonem, zazwyczaj w paczkach po kilka stanowiących jedną, większą akcję - np. nietrafiony rzut A -> zbiórka B). Przy wprowadzaniu to właściwie nic ciekawego się nie dzieje - tylko przerobić i wrzucić do bazy. (edit: wyniki "na bieżąco" to front sobie sam powinien dać radę obsłużyć)
Ok, czyli jeśli mówimy o DTO wpadającym do jakiegoś API, to zrobiłbym to jedną klasą z polem informującym o tym, co to za typ zagrywki. Na bazie tego pola można zrobić walidację wejścia i sprawdzić, czy wszystkie potrzebne rzeczy zostały przysłane z zewnątrz (a także, czy nie zostały przysłane żadne niepotrzebne).
Hierarchii tu się i tak nie da zrobić, bo na podstawie samych tylko ustawionych właściwości nie można określić typu klasy.
Pytanie, czy ten jeden DTO może być przetwarzany dalej w aplikacji, czy należy go najpierw przetworzyć w jakąś hierarchę klas. Na to pytanie nie da się odpowiedzieć nie znając szczegółów przetwarzania. Im bardziej ma to być tylko proste zapisanie do bazy, tym bardziej można zostawić DTO. Im więcej ma być logiki, tym więcej zysku będzie ze zróżnicowania na klasy... Prawodpodobnie.