New vs of, czyli o tym jak tworzyć kolekcje
W czasie dyskusji pod jednym z poprzednich wpisów, bodajże na wykopie, pojawiło się pytanie dlaczego w jednym z listingów używałem new ArrayList(), a na innych guavowego Lists.newArrayList. Cóż… wszystko jest kwestią wygody. Czasami wygodniej jest mi utworzyć listę za pomocą guavy. Kiedy indziej tworzę po prostu obiekt z użyciem new. Jednak na poziomie projektu można wymóc pewną konwencję.
Zalety
Główną zaletą jest spójność tworzonego kodu. Wszędzie mamy taką samą konwencję. Pozwala to na narzucenie określonego standardu. Kolejna sprawa to zasada nie używania new. W takim podejściu przerzucamy pełną odpowiedzialność za tworzenie zależności do kontenera DI. Jest to oczywiście ekstremalne podejście do problemu, ale pozwala nam na ćwiczenie się w tworzeniu odpornego kodu.
Kolejna sprawa to czytelność. Obie formy zarówno metoda fabrykująca jak i konstruktor, jeżeli tylko są używane spójnie w całym projekcie, to podnoszą czytelność kodu. Pozwalają na wyrobienie w głowie pewnych schematów w rodzaju „Jeżeli tu mam newArrayList, to zapewne już później nie będę do niej nic dodawać” albo „O new ArrayList, czyli zaraz będziemy dodawać”.
Wady
Jeżeli pojawia się problem to jest on systemowy. Bez łamania konwencji w jednym punkcie nie możemy go naprawić. Aklimatyzacja nowych osób. Czasami tego typu regułki są wkurzające. Kiedyś pracowałem w projekcie gdzie zakazane było używanie importów statycznych. Jednocześnie masowo wykorzystywano metody statyczne z klas wewnętrznych. Bolało.
Innym problemem jest sama implementacja kolekcji w Javie. Nie są one niezmienne, co powoduje, że trzeba się nagimnastykować by taką utworzyć. Nawet jak już utworzymy kolekcję niezmienną, to nadal nie jest ona kowariantna, tak jak w kotlinie. W efekcie tracimy kilka przydatnych elementów.
Podsumowanie
W ramach ćwiczenia warto napisać sobie projekt bez używania new. Pomóc w tym może używanie odpowiednich metod fabrykujących. Z drugiej strony warto pozostawić sobie swobodę, ale też wypracować własną strategię tak by osoba czytająca kod rozumiała co oznacza użycie tej czy innej konstrukcji dla kolejnych kroków.