adnotacje na poziomie klasy w porównaniu do interfejsów

Question

Przyglądam się kodowi, w którym adnotacje na poziomie klasy są używane do "dodawania" właściwości do niektórych klas, a później za pomocą odbicia te właściwości są dostępne i używane.

Moje pytanie: Kiedy należy użyć adnotacji, aby dodać nowe pola do klasy, zamiast korzystać z interfejsu. Jakie są tego zalety i wady?

Answer 1

Nie wiem, że adnotacje zastąpiłyby interfejs, ale mogę zobaczyć jego urok. Wszystko zależy jednak od implementacji.

Adnotacje udostępniają metadane w celu dalszego opisywania kodu, który konsument (w większości przypadków) interpretuje w środowisku wykonawczym za pomocą refleksów. Za pomocą interfejsu ta umowa implementacji jest jasno określona.

Można mieć:

interface CrudDao<T> { 
    Serializable create(T t); 
    T read(Serializable id); 
    void update(T t); 
    void delete(T t); 
} 

Byłoby to kłopotliwe do realizacji zamówienia, a prawdopodobnie ponieść jakieś metody łańcuchowych.

Zamiast tego można zrobić coś takiego:

class SomeDao { 

    @Create 
    long create(SomeEntity e) { // code } 

    @Read 
    SomeEntity read(long id) { // code } 

    @Update 
    void update(SomeEntity e) { // code } 

    @Delete 
    void delete(SomeEntity e) { // code } 
} 

wadą jest to, że byłoby kłopotliwe w użyciu:

class CrudFactory { 
    long create(Class clazz, Object obj) { 
     // loop through methods 
     // find method with @Create 
     // call method 
    }  
} 

Adnotacje w tym przykładzie byłoby przesadą większość czasu, IMO . Jest coś do powiedzenia na temat jasno zdefiniowanego, dobrze udokumentowanego kontraktu.