it-swarm-tr.com

Java'nın @Override ek açıklamasını ne zaman ve neden kullanıyorsunuz?

Java'nın @Override ek açıklamasını kullanmak için en iyi yöntemler nelerdir ve neden?

Her geçersiz kılınan yöntemi, @Override ek açıklamasıyla işaretlemeniz önemsiz gibi görünüyor. @Override 'u ve diğerlerinin de @Override' u kullanmaması gereken bazı programlama durumları var mı?

498
Alex B

İki avantaj için bir yöntemi geçersiz kıldığınızda her zaman kullanın. Bunu yaptığınız zaman, gerçekten düşündüğünüzde bir yöntemi geçersiz kıldığınızdan emin olmak için derleyici kontrolünden yararlanabilirsiniz. Bu yolla, bir yöntem adını yanlış hecelemeyle ilgili yanlış bir hata yaparsanız veya parametreleri doğru şekilde eşleştirmezseniz, yöntemin sizin sandığınız gibi geçersiz kılmadığı konusunda uyarılırsınız. İkincisi, kodunuzun anlaşılmasını kolaylaştırır, çünkü yöntemlerin üzerine yazıldığında daha açıktır.

Ek olarak, Java 1.6'da, bir yöntemin aynı faydalar için bir arabirim uyguladığı zamanları işaretlemek için kullanabilirsiniz. Ayrı bir ek not almanın daha iyi olacağını düşünüyorum (@Implements gibi), fakat hiç yoktan iyidir.

515
Dave L.

Derleme zamanı hatırlatması olarak, yöntemin amacının bir ana yöntemi geçersiz kılmak olduğunu en faydalı olduğunu düşünüyorum. Örnek olarak:

protected boolean displaySensitiveInformation() {
  return false;
}

Genellikle, temel sınıftaki bir yöntemi geçersiz kılan yukarıdaki yöntem gibi bir şey görürsünüz. Bu, bu sınıfın önemli bir uygulama detayıdır - hassas bilgilerin görüntülenmesini istemiyoruz.

Bu yöntemin ebeveyn sınıfında olarak değiştirildiğini varsayalım.

protected boolean displaySensitiveInformation(Context context) {
  return true;
}

Bu değişiklik, derleme zamanı hatalarına veya uyarılarına neden olmaz - ancak alt sınıfın amaçlanan davranışını tamamen değiştirir.

Sorunuzu cevaplamak için: bir üst sınıfta aynı imzalı bir yöntemin olmaması bir hata olduğunu gösteriyorsa @Override ek açıklamasını kullanmalısınız.

110
jon

Burada çok güzel cevaplar var, bakalım başka bir yol önereyim.

Kodlama yaparken fazladan bir şey yok. @Override yazmanız hiçbir şeye mal olmaz, ancak bir yöntem adını yanlış yazdıysanız veya imzayı biraz yanlış yazdıysanız tasarruflar çok büyük olabilir.

Bunu şu şekilde düşünün: Buraya gidip bu yazıyı yazdığınızda, hayatınızın geri kalanında @ override yazarak harcayacağınızdan daha fazla zaman kullandınız; ancak önlediği bir hata size zaman kazandırabilir.

Java, düzenleme/derleme zamanında herhangi bir hata yapmadığınızdan emin olmak için elinden geleni yapıyor; bu, kapsamlı testlerin dışında herhangi bir şekilde önlenebilir olmayan bir hata sınıfını çözmenin tamamen ücretsiz bir yoludur.

Kullanıcı bir yöntemi geçersiz kılmak istediğinde, gerçekte yaptığını sağlamak için Java'da daha iyi bir mekanizma bulabilir misiniz?

Bir başka temiz etki, ek açıklama sağlamazsanız, derleme sırasında sizi bir ana yöntemi geçersiz kıldığınızdan (sizi yapma niyetinde değilseniz önemli olabilecek bir şey) derlemeniz konusunda uyaracağıdır.

46
Bill K

Ben her zaman etiketi kullanırım. Yapabileceğim küçük hataları yakalamak için basit bir derleme zamanı bayrağı.

tostring() yerine toString() gibi şeyleri yakalayacaktır.

Küçük şeyler büyük projelerde yardımcı olur.

22
jjnguy

@Override ek açıklamasını kullanmak, genel bir programlama hatasına karşı derleme zamanı koruması olarak işlev görür. Süper sınıf yöntemini geçersiz kılmadığınız bir yönteme ek açıklama eklerseniz derleme hatası verir.

Bunun yararlı olduğu en yaygın durum, temel sınıftaki bir yöntemi farklı bir parametre listesine sahip olacak şekilde değiştirirken ortaya çıkmasıdır. Üst sınıf yöntemini geçersiz kılmak için kullanılan bir alt sınıftaki yöntem, artık değiştirilen yöntem imzası nedeniyle bunu yapmaz. Bu bazen, özellikle karmaşık kalıtım yapılarıyla uğraşırken garip ve beklenmedik davranışlara neden olabilir. @Override ek açıklaması buna karşı koruma sağlar.

18
toluju

Derleyici kontrolünden yararlanmak için daima Geçersiz kılma notunu kullanmalısınız. Ancak, Java Compiler 1.5'in arayüz yöntemlerini geçersiz kılarken bu açıklamaya izin vermeyeceğini unutmayın. Sınıf yöntemlerini (soyut ya da değil) geçersiz kılmak için kullanabilirsiniz.

Eclipse gibi bazı IDE'ler, Java 1.6 çalışma zamanı veya daha üstü ile yapılandırılmış olsalar bile, Java 1.5 ile uyumludurlar ve yukarıda açıklandığı gibi @override kullanımına izin vermezler. Bu davranışı önlemek için aşağıdakilere gitmelisiniz: Proje Özellikleri -> Java Derleyici -> “Projeye Özgü Ayarları Etkinleştir” -> Kontrol Et “Derleyici Uyum Seviyesi” = 6.0 veya daha üstünü seçin.

Tabanı bir arayüz veya sınıf ise, bu açıklamayı her zaman bağımsız olarak bir yöntemi geçersiz kıldığım zaman kullanmayı seviyorum.

Bu, bir olay işleyiciyi geçersiz kıldığınızı düşündüğünüz ve daha sonra hiçbir şey olmadığını gördüğünüz gibi, tipik hatalardan kaçınmanıza yardımcı olur. Bazı UI bileşenlerine bir olay dinleyicisi eklemek istediğinizi düşünün:

someUIComponent.addMouseListener(new MouseAdapter(){
  public void mouseEntered() {
     ...do something...
  }
});

Yukarıdaki kod derlenir ve çalıştırılır, ancak fareyi bazı UNIComponent içinde hareket ettirirseniz, “bir şeyler yapın” kodu çalışacağını not eder, çünkü aslında temel yöntemi mouseEntered(MouseEvent ev) geçersiz kılmazsınız. Sadece yeni bir parametresiz yöntem mouseEntered() oluşturun. Bu kodun yerine, eğer @Override ek açıklamasını kullandıysanız, bir derleme hatası gördünüz ve olay işleyicinizin neden çalışmadığını düşünerek zaman kaybetmediniz.

14
user174340

Geçersiz kılma olarak tasarlanan her yöntem ve bir arabirimin uygulaması olarak tasarlanan her yöntem için Java 6+ kullanmak en iyisidir.

İlk olarak, derleme zamanında "hashcode()" yerine "hashCode()" gibi yanlış yazımlar yakalar. Asıl neden, kodunuzun hiç çağrılmadığı durumlarda, yönteminizin sonucunun kodunuzla neden eşleşmediğini hata ayıklamak şaşırtıcı olabilir.

Ayrıca, bir üst sınıf bir yöntem imzasını değiştirirse, eski imzanın geçersiz kılmaları "ölü" olabilir, kafa karıştırıcı ölü kod olarak geride bırakılabilir. @Override ek açıklaması, bu yetimleri yeni imzayla eşleşecek şekilde değiştirilebilecek şekilde tanımlamanıza yardımcı olur.

8
erickson

@Override on interface uygulaması , Java'da "bir arabirimi geçersiz kılma" diye bir şey olmadığından tutarsız.

@Override on interface uygulaması işe yaramaz çünkü uygulamada derlemenin yine de yakalayamayacağı herhangi bir hata yakalamaz. Uygulayıcıların geçersiz kılma işleminin aslında bir şey yaptığı tek bir uzak senaryo var: Bir arayüz uygularsanız ve REMOVES arayüzünü kullanırsanız, derleme zamanında kullanılmayan uygulamaları kaldırmanız gerektiği bildirilecektir. Arayüzün yeni sürümünün YENİ veya DEĞİŞTİRİLMİŞ metotları varsa, yeni şeyleri uygulamadığınız için zaten derleme hatası alacağınıza dikkat edin.

@ Arayüz uygulayıcılarının aşırı uyarılmasına 1.6'da asla izin verilmemeliydi ve Eclipse ek notları varsayılan davranış olarak otomatik olarak eklemeyi seçerek ne yazık ki, çok sayıda karışık kaynak dosyası elde ettik. 1.6 kodunu okurken, eğer bir yöntem gerçekten üst sınıftaki bir yöntemi geçersiz kılarsa veya sadece bir arabirim uygularsa, @Override ek açıklamasından göremezsiniz.

Bir üst sınıftaki bir yöntemi gerçekten geçersiz kılan zaman @Override kullanmak iyidir.

8
Rune

Yaptığı diğer bir şey de, ebeveyn sınıfının davranışını değiştirdiği kodu okurken daha belirgin hale getirmesidir. Hata ayıklamada yardımcı olabilir.

Ayrıca, Joshua Block'un Etkin Java kitabında (2. baskı), 36. madde, açıklamanın faydaları hakkında daha fazla ayrıntı vermektedir.

7
Diastrophism

@Averride arayüzleri gerçekten faydalıdır, çünkü arayüzü değiştirirseniz uyarılar alırsınız.

7
Asgeir S. Nilsen

Kendinizi geçersiz kılan (soyut olmayan) yöntemleri çok sık bulursanız, muhtemelen tasarımınıza bakmak istersiniz. Derleyicinin hatayı yakalayamayacağı zaman çok kullanışlıdır. Örneğin, yaptığım ThreadLocal'daki initValue () öğesini geçersiz kılmaya çalışıyor.

Arabirim yöntemlerini (1.6+ özellik) uygularken @Override kullanmak benim için biraz zor görünüyor. Bazıları geçersiz kılan ve bazıları olmayan birçok yönteminiz varsa, bu muhtemelen kötü bir tasarım (ve editörünüz muhtemelen hangisini bilmiyorsanız gösterir).

7

Bir arayüz yöntemi uygularken @Override kullanmak kesinlikle mantıklı değil. Bu durumda onu kullanmanın bir avantajı yok - derleyici zaten hatanızı yakalayacaktır, bu yüzden sadece gereksiz karmaşa.

6
Steve R.

Bir yöntem başka bir yöntemi geçersiz kıldığında veya bir yöntem arabirimde bir imza uygular.

@Override ek açıklaması size bir şeyi geçersiz kıldığınızı garanti eder. Ek açıklama olmadan, yanlış yazım veya parametre türlerinde ve sayısında bir fark riski vardır.

6
Greg Mattes
  • Yalnızca yöntem bildirimlerinde kullanılır.
  • Açıklamalı yöntem bildiriminin, üst türdeki bildirimi geçersiz kıldığını belirtir.

Tutarlı kullanılırsa, sizi büyük çapta zararlı böceklerden korur.

Bu hataları önlemek için @Override ek açıklamasını kullanın: (Hatayı aşağıdaki kodda bulun :)

public class Bigram {
    private final char first;
    private final char second;
    public Bigram(char first, char second) {
        this.first  = first;
        this.second = second;
    }
    public boolean equals(Bigram b) {
        return b.first == first && b.second == second;
    }
    public int hashCode() {
        return 31 * first + second;
    }

    public static void main(String[] args) {
        Set<Bigram> s = new HashSet<Bigram>();
        for (int i = 0; i < 10; i++)
            for (char ch = 'a'; ch <= 'z'; ch++)
                s.add(new Bigram(ch, ch));
        System.out.println(s.size());
    }
}

kaynak: Etkili Java

5
jai

Her zaman kullanırım. Bir yıl içinde kodu tekrar ziyaret ettiğimde neler olup bittiğini hızlı bir şekilde bulmak için kullanabileceğim ve ilk kez ne düşündüğümü unuttuğum daha fazla bilgi.

5
Hank Gay

Her yerde kullanırım. Markalama metotları konusunda, Eclipse'in benim için yapmasına izin verdim, bu yüzden ek bir çaba göstermiyor.

Sürekli yeniden yapılanma konusunda dindarım .... bu yüzden her şeyi daha sorunsuz hale getirmek için kullanacağım.

5
willCode4Beer

En iyi yönelim her zaman onu kullanmaktır (veya IDE sizin için doldursun)

@Girişin yararı, hiyerarşi içinde bildirilmeyen üst sınıflardaki değişiklikleri tespit etmektir. Onsuz, bir yöntem imzasını değiştirebilir ve geçersiz kılmaları değiştirmeyi unutabilirsiniz, @Override ile derleyici sizin için yakalar.

Bu tür bir güvenlik ağının olması her zaman iyidir.

5
David Pierre

Geçersiz Kılma'yı kullanırken dikkatli olun, çünkü daha sonra starUML'de ters mühendislik yapamazsınız; uml'yi ilk yap.

3
Horatiu Jeflea

Buradaki bilgelik değişiyor gibi görünüyor. Bugün IntelliJ IDEA 9 'u yükledim ve " eksik @Override muayenesi "' in artık sadece soyut yöntemler değil, aynı zamanda arayüz yöntemleri de uyguladığını fark ettim. İşverenimin kod tabanında ve kendi projelerimde uzun zamandır eski uygulamalı soyut yöntemler için @Override kullanma alışkanlığım oldu. Ancak, alışkanlığı yeniden düşünerek, her iki durumda da ek açıklamaları kullanmanın yararı açıklığa kavuşuyor. Daha ayrıntılı olmasına rağmen, arabirim yöntemi adının değiştiği/türetilmiş bir sınıfta uygulama yönteminden ötürü, arabirim yöntemi adının değiştiği kırılgan temel sınıf soruna (C++ ile ilgili örnekler kadar değil) karşı koruma sağlar.

Tabii ki, bu senaryo çoğunlukla abartma; türetilmiş sınıf artık derlenmeyecek, şimdi yeniden adlandırılmış arabirim yönteminin bir uygulamasından yoksun olacak ve bugün bir tane büyük olasılıkla topluca tüm kod tabanını ele almak için bir Rename Method refactoring işlemini kullanacaktır.

IDEA'nın incelemesinin uygulanan arayüz yöntemlerini görmezden gelecek şekilde yapılandırılmadığı göz önüne alındığında, bugün hem alışkanlığımı hem de ekibimin kod inceleme kriterlerini değiştireceğim.

2
seh

Not @Override, geliştiricinin ana sınıfta veya arabirimde doğru yöntemi geçersiz kılacak olup olmadığını kontrol etmeye yardımcı olmak için kullanılır. Üstün yöntemlerin adı değiştiğinde, derleyici bu durumu bildirebilir; bu yalnızca üst ve alt sınıfla tutarlılığı sağlamak içindir.

BTW, alt sınıfta @Override ek açıklamasını açıklamadıysak, ancak bazı süper yöntemleri geçersiz kılarsak, işlev @Override ile aynı şekilde çalışabilir. Ancak, bu yöntem, geliştiricinin yöntemi değiştirildiğinde geliştiriciye bildirilemez. Geliştiricinin amacını bilmediği için - süpers metodunu geçersiz kılar mı yoksa yeni bir metot tanımlar mı?

Dolayısıyla Polimorfizmden yararlanmak için bu yöntemi geçersiz kılmak istediğimizde, yöntemin üzerine @ Overver eklemek daha iyidir.

2
lzlstyle

Bir yöntemin geçersiz kılındığını tanımlamak için mümkün olduğu kadar kullanıyorum. Scala programlama diline bakarsanız, bunların bir geçersiz kılma anahtar kelimesi de vardır. Kullanışlı buluyorum.

1
Berlin Brown

ne zaman izin verilse @override kodlamanın en iyi yol olduğunu düşünüyorum. kodlama için yardımcı olur. ancak, ecipse Helios için, sdk 5 veya 6 ya da, uygulanan arayüz yöntemleri için @override ek açıklamasına izin verilmiştir. Galileo’ya gelince, ya 5 ya da 6, @override ek açıklığına izin verilmez.

0
lwpro2

Benim için @ Overver bana yöntemin imzasının doğru olmasını sağlıyor. Ek açıklamayı eklerseniz ve yöntem doğru yazılmamışsa, derleyici bir şeylerin yanlış olduğunu bildirmekten şikayet eder.

0
Dale

Basit - üst sınıfınızda bulunan bir yöntemi geçersiz kılmak istediğinizde, doğru geçersiz kılmak için @Override notunu kullanın. Doğru şekilde geçersiz kılmazsanız, derleyici sizi uyaracaktır.

0
Sree

Derleyicinin geçersiz kıldığınız yöntem adını yanlış yazdığınız zaman (derleyici) yakalamanızı sağlar.

0
JeeBee

Geçersiz kılma notu, derleyiciden yararlanmak için, gerçekten bir sınıftan bir yöntemi geçersiz kılmakta olup olmadığınızı kontrol etmek için kullanılır. Bir yöntem adının yanlış yazılmasının yanlış olması, parametrelerin doğru şekilde eşleşmemesi gibi bir hata yapıp yapmadığınızı bildirmek için kullanılır.

0
Siva

Ek açıklamalar, Derleyici'ye kodla ilgili meta veriler sağlar ve herhangi bir temel sınıf yöntemini geçersiz kıldığımızda miras durumunda, ek açıklama @Override kullanılır. Sadece derleyiciye geçersiz kıldığınız yöntemi söyler. Yöntemin doğru imzasını izlememek veya yöntem adına yanlış yazılmasını önlemek gibi yapabileceğimiz bazı yaygın hataları önleyebilir. Bu nedenle @ Overver ek açıklamasını kullanmak iyi bir uygulamadır.

0
gprathour