Keep it clean. Public enemy No. 1

Czy wiesz, czemu domyślny zakres widoczności w Javie to package-private? Bo projektanci uznali, że to będzie najpopularniejszy zakres. Tylko czy faktycznie najczęściej się z nim spotykasz? Badania Adama Tornhilla pokazują, że nie. Programiści w Javie rozpoznają właściwie tylko private i public, przez co są szczególnie kiepscy w budowaniu elementów “średniej wielkości”. A to sprawia, że nasze projekty trudno ogarnąć w głowie. Trudno o nich sensownie myśleć. Zamiast enkapsulacji mamy splątanie. Ludzie potrafią nawet rejestrować każdą możliwą klasę w kontenerze IoC, bo kompletnie nie rozumieją enkapsulacji na poziomie pakietu.

A dziedziczenie? James Gosling w 2001 roku, zapytany co zrobiłby inaczej, gdyby mógł stworzyć Javę od nowa, powiedział, że prawdopodobnie usunąłby dziedziczenie klas. Jest rok 2016: mamy lambdy, metody domyślne w interfejsach, AOP i inne sztuczki, a mimo to deweloperzy wciąż wolą po prostu dorzucić do kodu kolejną klasę abstrakcyjną. Super będzie się w tym odnaleźć, kiedy trafisz na siedem kręgów piekieł podczas czytania.

Okej, może nie jest aż TAK źle, ale dużo lepiej też nie jest. Problem w tym, że wszyscy startujemy od tutoriali, które dla zwięzłości idą na skróty. I nie zwracamy uwagi na te małe problemy, dopóki nie walną nas z całej siły.

Zobaczmy więc, jak trochę poprawić sytuację: używając Domain-Driven Design, zakresu package-private, sensownej struktury pakietów, CQRS w mikroserwisach, a na koniec - architektury heksagonalnej. Bo paradoksalnie jest to łatwiejsze niż robienie tego “bez”. W pakiecie prawdziwe przykłady z projektów.