Klątwa buchaja
Jednym z podstawowych pojęć związanych z programowaniem obiektowym jest dziedziczenie. Wydzielenie szczegółów implementacji do klas potomnych pozwala na wielokrotne wykorzystanie tego samego fragmentu kodu do różnych zadań.
Jednak z czasem hierarchia dziedziczenia rozrasta się w wielopoziomowe drzewo pełne buchajów. Przykładem mogą być komponenty interfejsu użytkownika i hierarchia: komponent→kontrolka→przycisk→przycisk z gradientem→przycisk z niebieskim gradientem… Takie podejście do kwestii dziedziczenia spowoduje powstanie całego stada klas rozpłodowych.
Czy zatem należy unikać dziedziczenia? Nie do końca – dwu- góra trójpoziomowe dziedziczenie jest czasem niezbędne. Jednak należałoby się zastanowić nad różnymi aspektami obiektu.
Na przykład czym innym jest wygląd przycisku, a czym innym jego działanie. Na pewnym etapie dojdziemy do wniosku, że chcielibyśmy dynamicznie zmieniać wygląd komponentów, co dużo łatwiej będzie uzyskać poprzez oddzielenie klas kontrolek od klas odpowiedzialnych za ich renderowanie (analogiczne mechanizmy zostały zaimplementowane w bibliotece Java Swing).
Podobne podziały odpowiedzialności obiektów można znaleźć w księgowości, gdzie każdy dokument musi zostać zaksięgowany, ale faktura to co innego niż przelew. Czy zatem faktura powinna dziedziczyć po abstrakcyjnym dokumencie? Według mnie, lepszym rozwiązaniem byłoby zastosowanie jednego dokumentu księgowego oraz kilku strategii dla formularza dokumentu czy też schematu księgowania.
Widzę jeden wniosek płynący z powyższych przemyśleń – najlepszym sposobem uniknięcia namnażania się klas w postępie geometrycznym jest wybór obiektów o możliwie najmniejszej i najbardziej wyspecjalizowanej funkcjonalności. Gdy drzewo dziedziczenia osiąga trzy poziomy, najprawdopodobniej oznacza to, że odpowiedzialność klasy staje się zbyt szeroka i należy z pomocą technik refaktoryzacji dokonać jej podziału.
