Code smellsy ;-) protected i abstract

Im dłużej piszę w Java'ie i okolicach tym bardziej przekonuję się, że abstract i protected to code smellsy ;-)

Gdy widzę protected to macha ono do mnie wielką czerwoną flagą.
Głębsze spojrzenie często wskazuje, że dev potrzebował dostępu do czegoś prywatnego.
Jeśli protected oznaczone jest pole w klasie to prawie zawsze mamy ten przypadek.

Prawie zawsze przy chwili spojrzenia na klasę okazuje się, że to protected nie jest potrzebne, że jest sposobem na przykrycie jakiejś większej wtopy w projekcie API.

Podobnie jest z abstract.
Jak widzę to często jest użyte "żeby nie pisać 2 razy tego samego kodu"...
Dziedziczenie jednak nie jest po to by nie duplikować kodu.
Tak unikanie duplikacji kodu jest jednym z zysków dziedziczenia, ale nie jest celem dziedziczenia.

Jak się żenimy to dostajemy teściową, raczej nie żenimy się po to by zyskać teściową.

Zwykle okazuje się w końcu, że można by uniknąć w ogóle dziedziczenia i użyć kompozycji.

Drugim częstym przypadkiem z abstract jest zwykłe przekombinowanie i pisanie na przyszłość.
Autor uznał, że za jakiś czas przyda się możliwość stworzenia jeszcze jednego potomka i od razu zrobił klasę abstrakcyjną.
I znów to nie tak, najpierw kod powinien być w 1 klasie, dopiero gdy pojawia się potrzeba stworzenia nowej "obok" to ma sens rozważenie hierarchii.


Podobne posty^beta
Patrzajcie w kod a znajdziecie ;)
Code review - najfajniejszy kawałek procesu ;-)
protected - powinni tego zakazać...
Paradoks Java'y - domyślny poziom widoczności jest stosowany najrzadziej ;-)
Branche i Scrum to taki security blanket dla programistów