• ing. açıklayıcı not, ek açıklama.
    genelde çoğul olarak kullanılır.
    (bkz: annotate) (bkz: annotasyon)
    (bkz: c plus plus annotations)
  • jee'de çok büyük yeri olan ufak açıklayıcılar.
    (bkz: @webservice)
    (bkz: @stateless)
    (bkz: @stateful)
    (bkz: @ejb)
    (bkz: @resource)
  • programlamada reflection'ın can dostu. yirim.
  • diğer dillerdeki karşılığını merak ettiğim can dostum, nefret ettiğim xml'lerin yanına koyan..
  • java'dakinin .net muadili attribute'tür.
  • daha zekice tasarlanmisi icin (bkz: decorator)
  • öncelikle (bkz: reflection)
    özellikle (bkz: #15640449)

    annotation, java'da reflection'ın neden can dostudur, kısa bir örnekle açıklayayım:

    şöyle bir sınıf olsun:
    public class a{
    public static void x() {
    system.out.println("x");
    }
    public static void y() {
    system.out.println("y");
    }
    }

    ismi verilen bir metodu çalıştıran metodu şu şekilde yazabiliriz (reflection'ın kapsamına giriyor):
    public static void calistir(string metot_adi) {
    a.class.getmethod(metot_adi).invoke(null);
    }

    peki bütün metotların çalıştırılmasını istemiyorsam? ya da her metod için "bunu şu role sahip olanlar çalıştırabilsin" demek istiyorsam? bunun için bir sürü şey yapılabilir. örneğin "private tanımlanan metotlar dışardan çalıştırılmaz" denebilir, ya da metotlara ön ek* konabilir (mesela junit'de eskiden bir metodun test edilebilir olduğunu göstermek için adının test ile başlaması gerekiyordu, testx, testy gibi).

    peki bunun yerine elimde bir şey olsa da ben bu metotları işaretleyebilsem ne güzel olur, değil mi? annotation'ın sağladığı şey de bu, işaretleme. örneğin çalıştırılabilir metotları işaretleyebilmek için "yardir" isminde annotation yazıp istediğim metodun başına ekliyorum:

    @yardir
    public static void x() {...

    calistir'i da şöyle düzeltiyorum:
    method m = a.class.getmethod(metot_adi);
    if (m.getannotation(yardir.class) != null)
    m.invoke(null);
    else
    system.out.println(metot_adi + " yardirilamaz");

    ekler:
    1) retentionpolicy:
    annotation tanımlanırken retentionpolicy'si belirlenir. 3 değeri olabilir:
    source: annotation class dosyasına taşınmaz. örneğin @override böyledir, compile'dan sonra gereksiz olacağı için taşınmaz.
    class: class dosyasına taşınır, fakat reflection ile erişilemez. class dosyalarında işlem yapılacaksa iş görür yani.
    runtime: reflection için bu kullanılır.

    2) target:
    annotation'ın nerelerde kullanılabileceğini belirtir. örneğin bizim @yardir sadece metotlarda kullanılabilir olmalı, parametrede/class'da vs. saçma olur.

    3) değerler:
    annotation içinde değer verilmesi sağlanabilir. kimlerin yardırabileceğini belirtebileceğimiz bir annotation:

    @retention(retentionpolicy.runtime) //bu bana runtime'da lazim olacak
    @target(elementtype.method) //bu annotation sadece metotlar icin kullanilabilir
    public @interface yardirabilir { //annotation adi
    public string kim() default "herkes"; //kim adinda, string turunde bir oznitelik olsun.
    //programci kim'e bir deger vermezse degeri "herkes" olsun.
    //not: default deger belirlenmek zorunda degildir.
    //ama belirlenmezse programci mutlaka bir deger vermek zorunda kalir
    //not2: ne default deger, ne de programcinin kullanirken verecegi deger null olamaz.
    //not3: birden fazla degerden olusacak bir oznitelik tanimlanacaksa, ayri bir annotation olarak tanimlanir,
    //burda tur olarak o annotation belirtilir
    }

    artık çalıştırılabilir metotlar şöyle işaretlenecek:
    @yardirabilir(kim="admin")
    public static void x() {...

    ya da
    @yardirabilir // x'e default değer verdiğimiz için "kim" boş da bırakılabilir. boş bırakılırsa değeri "herkes" olur.
    public static void x() {...

    sonra, calistir metodu:
    method m = a.class.getmethod(method_adi);
    yardirabilir y = m.getannotation(yardirabilir.class);

    if (y == null)
    system.out.println("yardirilamaz")
    else {
    string kim_yardirabilir = y.kim();
    if (kim_yardirabilir.equals(adamin_rolu))
    m.invoke(null);
    else
    system.out.println("sen yardiramazsin");
    }

    şimdi bu mu güzel, metot isminden birşeyler anlamaya çalışmak mı güzel, yoksa xml okumak mı güzel? 3. kez söylüyorum, yirim.
  • geliştirici insanının xml tu kaka diyip bağrına bastığı, öte yandan sıkıntılarıyla beraber gelen hede:

    - derlenebilirliği/doğruluğu-tutarlılığı runtime öncesi tamamen kontrol edilebilir şeyler değiller
    - bir sınıftan birşeyler türetmek mümkün ama temel sınıftaki annotation'ı silip atmak diye birşey yok maalesef.
    - test edilemez/test kapsamı temizinden tespit edilemez işleri yapmak için kullanabilirsiniz (bkz: lombok)
    - spring ve jee gibi ortamlarda annotation için sınıfları tarama diye birşey var, böylelikle herşey herşeye hop bağlanıveriyor.yeniler okusun diye birkaç sınıflık bir tutorial yazıyorsanız herşey çok yönetilebilir ama uğraştığınız kod belli bir ölçünün üzerine çıktıysa ve "belli yerleri değil heryeri tara, işini tam yap" diyen acar takım arkadaşlarınız varsa ne neye ne zaman bağlanmaya çalışıyor diye arayıp uğraşır durusunuz.
    - java'da bir nesneyi bir yerde yaratıp n yere sürükleyebilirsiniz ama o nesnenin içine koyabileceğiniz annotation türü pratikte sınırlı. tek annotation kaynağı tutorial'ını okuduğunuz o kütüphane ise herşey çok güzel. ama jpa, jackson, xml, spring gak guk birsürü şeyin annotation'ını aynı sınıfa yazın ve yan masadaki arkadaşınıza gösterin, yüz ifadesini inceleyin.

    neyse, bunun uzun uzun yazılmışı da var, tek dertli ben değilmişim: https://blog.softwaremill.com/…tations-4b2fb170ed67
  • autocad'te annotation'ın karşılığı tam olarak "çizim dışı öğe"dir. autocad'te bazı ifadelerin sözlük çevirisi yapılmamalıdır. program mantığı içerisinde kavranacak ifadelerdir bunlar.

    üretilen çizgiler ve şekiller dışındaki her şey (yazı, ölçü, gösterim okları, tablo, blok eleman, vs.) çizime kendi kurallarına göre ayrıca eklenebilen, kendi ayarı olan öğelerdir. işte bunlar şerit menü (bkz: ribbon) üzerinde annotation başlığı altında size sunulur.

    ayrıca annotation ifadesi associative ile hiç mi hiç karıştırılmamalıdır. piyasadaki nice kitapta bu hayati hatayı görebilirsiniz. (associative "ilişkili nesne" anlamında kullanılır ve annotation ile birebir alakası yoktur.)

    o yarım yamalak ingilizcenizle harfleri benziyor diye beyninizin size oynadığı oyunla yanlış yapıp doğru yaptığını sanarak bilmeyene öğrettiğini zannetmek, kendini biliyor zannetmek... hiç komik değil.
  • tam olarak türkçe'ye çevrilememiş kelimelerden biri.
hesabın var mı? giriş yap