Właśnie dostałem komentarz recenzji, że mój statyczny import metody nie był dobrym pomysłem. Import statyczny był metodą z klasy DA, która zawiera głównie metody statyczne. Tak więc w środku logiki biznesowej miałem aktywność da, która najwyraźniej wydawała się należeć do obecnej klasy:
import static some.package.DA.*;
class BusinessObject {
void someMethod() {
....
save(this);
}
}
Recenzentowi nie zależało na tym, żebym zmienił kod i nie zrobiłem, ale w pewnym sensie się z nim zgadzam. Jednym z powodów braku importu statycznego było mylące miejsce, w którym metoda została zdefiniowana, nie znajdowała się ona w bieżącej klasie ani w żadnej nadklasie, więc zidentyfikowanie jej definicji zajęło trochę czasu (internetowy system recenzji nie ma klikalnego linki takie jak IDE :-) Nie sądzę, żeby to miało znaczenie, statyczne importy są wciąż całkiem nowe i wkrótce wszyscy przyzwyczaimy się do ich lokalizowania.
Ale innym powodem, z którym się zgadzam, jest to, że niekwalifikowane wywołanie metody wydaje się należeć do bieżącego obiektu i nie powinno przeskakiwać kontekstów. Ale gdyby tak naprawdę należało, rozszerzenie tej superklasy miałoby sens.
Tak więc, gdy ma ona sensu statycznych metod importu? Kiedy to zrobiłeś? Czy podobał Ci się wygląd niekwalifikowanych połączeń?
EDYCJA: Popularna opinia wydaje się być taka, że metody statycznego importu, jeśli nikt nie pomyli ich z metodami bieżącej klasy. Na przykład metody z java.lang.Math i java.awt.Color. Ale jeśli abs i getAlpha nie są niejednoznaczne, nie rozumiem, dlaczego readEmployee jest. Podobnie jak w przypadku wielu wyborów programistycznych, myślę, że jest to kwestia osobistych preferencji.
Dziękuję za odpowiedź, zamykam pytanie.
import static
taka, funkcja tostatic import