Nasza baza kodów jest stara i nowi programiści, tacy jak ja, szybko uczą się robić to tak, jak robi się to dla zachowania jednolitości. Myśląc, że musimy gdzieś zacząć, wziąłem na siebie refaktoryzację klasy posiadacza danych jako takiej:
- Usunąłem metody ustawiające i utworzyłem wszystkie pola
final(przyjmuję „finaljest dobry” aksjomatycznie). Setery były używane tylko w konstruktorze, jak się okazuje, więc nie miało to żadnych skutków ubocznych. - Wprowadzono klasę Builder
Klasa Builder była konieczna, ponieważ konstruktor (który spowodował przede wszystkim refaktoryzację) obejmuje około 3 wiersze kodu. Ma wiele parametrów.
Na szczęście mój kolega z zespołu pracował nad innym modułem i potrzebował seterów, ponieważ wymagane przez niego wartości stały się dostępne w różnych punktach przepływu. Tak więc kod wyglądał następująco:
public void foo(Bar bar){
//do stuff
bar.setA(stuff);
//do more stuff
bar.setB(moreStuff);
}
Argumentowałem, że powinien zamiast tego użyć konstruktora, ponieważ pozbycie się seterów pozwala polom pozostać niezmiennymi (wcześniej słyszeli, jak mówiłem o niezmienności), a także dlatego, że konstruktory pozwalają na tworzenie obiektów transakcyjnych. Naszkicowałem następujący pseudokod:
public void foo(Bar bar){
try{
bar.setA(a);
//enter exception-throwing stuff
bar.setB(b);
}catch(){}
}
Jeśli ten wyjątek barzostanie uruchomiony , będą miały uszkodzone dane, których można by uniknąć za pomocą konstruktora:
public Bar foo(){
Builder builder=new Builder();
try{
builder.setA(a);
//dangerous stuff;
builder.setB(b);
//more dangerous stuff
builder.setC(c);
return builder.build();
}catch(){}
return null;
}
Moi koledzy z drużyny odparli, że omawiany wyjątek nigdy nie zostanie uruchomiony, co jest wystarczające dla tego konkretnego obszaru kodu, ale wierzę, że brakuje lasu dla drzewa.
Kompromis polegał na przywróceniu starego rozwiązania, a mianowicie użyciu konstruktora bez parametrów i ustawieniu wszystkiego za pomocą seterów zgodnie z potrzebami. Uzasadnieniem było to, że to rozwiązanie jest zgodne z zasadą KISS, którą kopalnia narusza.
Jestem nowy w tej firmie (mniej niż 6 miesięcy) i jestem w pełni świadomy, że ją straciłem. Mam pytania:
- Czy istnieje inny argument za używaniem Konstruktorów zamiast „starego sposobu”?
- Czy zaproponowana przeze mnie zmiana naprawdę jest tego warta?
ale naprawdę,
- Czy masz jakieś wskazówki, jak lepiej przedstawiać takie argumenty, opowiadając się za próbą czegoś nowego?
setA?