Metoda zignorowana, niezaakceptowana

Question

Niektóre klasy Java muszą mieć właściwości prywatne z publicznym programem pobierającym i ustawiającym, aby działały poprawnie. Na przykład potrzebne są komponenty bean JSF i jednostki JPA. Gdyby nie te biblioteki, prawdopodobnie istnieją pewne właściwości, które nie powinny mieć żadnych pobierających i zdecydowanie nie ustawiać. Również puste konstruktory są często zniechęcane do użycia przez niestandardowy kod. Na przykład:

@Entity 
public class MyEntity implements Serializable { 

    @Id 
    @GeneratedValue(strategy = GenerationType.AUTO) 
    private Long id; 

    public MyEntity() {} 

    public Long getId() { 
     return this.id; 
    } 

    public void setId(Long id) { 
     this.id = id; 
    } 
} 

W tej klasie metoda setId nigdy nie powinna być wywoływana przez ręczny kod. Ta metoda nie jest jednak przestarzała, więc adnotacja @Deprecated byłaby niepoprawna.

Czy jest inny sposób niż @Deprecated, aby powiedzieć, że metoda nie powinna być używana?

Answer 1

Jednostki JPA nie potrzebują publicznych programów pobierających i ustawiających. Wartości ustawia się za pomocą odbicia (przynajmniej podczas korzystania z EclipseLink lub Hibernate, z których prawdopodobnie korzystasz).

W tym konkretnym przykładzie można po prostu zostawić setera, zrobiłem z niego zwyczaj i nigdy nie miałem z tym problemu. Uwaga: Trzymaj się konwencji nazewnictwa Java, jeśli chodzi o właściwości i pobierające/ustawiające. Niektóre biblioteki/frameworki (błędnie imo) zależą od tego.

Co do globalnej koncepcji pytania, jestem zaskoczony, że nie widzę sugestii, która zawiera dokumentację. Dokumentacja jest, jest i prawdopodobnie zawsze będzie Twoją najlepszą komunikacją dla użytkowników Twojego kodu.

/** 
* WARNING! DO NOT USE THIS UNLESS YOU ARE GOD! 
* This will probably break stuff unless... 
* .... 
*/ 
public void doEvilHackishThings() 
{ 
    // Stuff happens here. 
} 

Jeśli dokumentujesz swój kod poprawnie, programiści wiedzą, kiedy najprawdopodobniej coś zepsują. Upewnij się, że nie stosujesz kodu voodoo itp. Dobra dokumentacja opisuje szczegółowo, co robi i jak to robi. Żaden programista przy zdrowych zmysłach nie dotknie przykładowej metody bez zrozumienia, dlaczego jest ona zła.

Answer 2

Można ukryć obiekty pobierające i ustawiające za pomocą interfejsu, który jest wspierany przez tę konkretną klasę. To również zachęciłoby Tell, nie pytaj, ponieważ nie ma żadnych pobierających, których można użyć w interfejsie. Wykorzystanie konstruktora może być również ukryte w fabrykach.