Java soyut arayüzü

Bir örnek düşünün (Java'da derlenen)

public abstract interface Interface {
    public void interfacing();
    public abstract boolean interfacing(boolean really);
}

Neden bir arayüzün "bildiri" şeklinde özetlenmesi gerekir? Soyut bir arayüzle uygulanan başka kurallar var mı?

Son olarak: abstractEskiyse neden Java'ya dahil edilir? Soyut arayüz için bir geçmiş var mı?

Neden bir arayüzün "bildiri" şeklinde özetlenmesi gerekir?

Değil.

public abstract interface Interface {
       \___.__/
           |
           '----> Neither this...

    public void interfacing();
    public abstract boolean interfacing(boolean really);
           \___.__/
               |
               '----> nor this, are necessary.
}

Arayüzler ve yöntemleri dolaylı olarak abstractve değiştiricinin eklenmesi fark yaratmıyor.

Soyut bir arayüzle uygulanan başka kurallar var mı?

Hayır, aynı kurallar geçerlidir. Yöntem, herhangi bir (somut) uygulayıcı sınıf tarafından uygulanmalıdır.

Soyut kullanılmıyorsa neden Java'ya dahil edilir? Soyut arayüz için bir geçmiş var mı?

İlginç soru. JLS'nin ilk baskısını kazdım ve orada bile "Bu değiştirici eski ve yeni Java programlarında kullanılmamalıdır" diyor .

Tamam, daha fazla kazma ... Çok sayıda kopuk bağlantıya çarptıktan sonra, orijinal Oak 0.2 Spesifikasyonunun (veya "manuel") bir kopyasını bulmayı başardım . Söylemeliyim ki oldukça ilginç bir okuma ve toplamda sadece 38 sayfa! :-)

Bölüm 5, Arayüzler altında, aşağıdaki örneği sağlar:

public interface Storing {
    void freezeDry(Stream s) = 0;
    void reconstitute(Stream s) = 0;
}

Ve marjda şöyle diyor

Gelecekte, arabirimlerdeki yöntemlerin bildirilmesinin "= 0" kısmı ortadan kalkabilir.

Anahtar kelime ile =0değiştirildiği varsayılarak abstract, bunun abstractbir noktada arayüz yöntemleri için zorunlu olduğundan şüpheleniyorum !

İlgili makale: Java: Soyut arayüzler ve soyut arayüz yöntemleri

publicArayüz yöntemlerinde olduğu gibi isteğe bağlı değildir .

Bu konudaki JLS'ye bakın:

http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html

9.1.1.1 Soyut Arayüzler Her arayüz dolaylı olarak soyuttur. Bu değiştirici kullanılmıyor ve yeni programlarda kullanılmamalıdır.

Ve

9.4 Soyut Metot Beyanları

[...]

Java platformunun eski sürümleriyle uyumluluk için, bir stil olarak, arabirimlerde bildirilen yöntemler için soyut değiştiriciyi yedek olarak belirtmesine izin verilir, ancak önerilmez.

Arayüz yöntemleri için genel değiştiriciyi yedek olarak belirtmesine izin verilir, ancak bir stil meselesi olarak kesinlikle önerilmez.

Arayüz özetini bildirmek gerekli değildir.

Tıpkı tüm bu yöntemleri herkese açıklamak (arayüz zaten herkese açıksa) veya soyut (zaten arayüzde oldukları) gereksizdir.

Yine de kimse seni durdurmuyor.

Açıkça ifade edebileceğiniz, ancak şunları yapmanız gerekmeyen diğer şeyler:

• Bir kurucunun ilk satırında super () öğesini çağırın
• extends Object
• kalıtsal arayüzleri uygulamak

Soyut bir arayüzle uygulanan başka kurallar var mı?

Bir arayüz zaten "soyut". Bu anahtar kelimeyi tekrar uygulamak kesinlikle fark etmez.

İlkbaharda akademik olmayan bir anlamı olduğunu unutmayın. Soyut arabirim geliştiricinin bunu kullanmaması için bir uyarıdır @Autowired. Umarım bahar / tutulma @Autowiredbu özelliğe bakar ve bunun kullanımı hakkında uyarır / başarısız olur.

Gerçek bir örnek: @Repository'ye @Transnational altında hizmet proxy'si aynı temel yöntemleri kullanmalıdır, ancak bu soyut arabirimi nedeniyle farklı arabirimler kullanmalıdırlar @Autowired. (Ben bu XXXSpec arayüzünü çağırıyorum)

Her arayüz dolaylı olarak soyuttur.
Bu değiştirici kullanılmıyor ve yeni programlarda kullanılmamalıdır.

[Java Dil Özelliği - 9.1.1.1 abstractArayüzler]

Ayrıca, arabirim üyesi yöntemlerinin dolaylı olduğunu unutmayın public abstract.
[Java Dil Özelliği - 9.2 Arabirim Üyeleri]

Bu değiştiriciler neden üstü kapalı? Burada yararlı olacak başka bir değiştirici ( 'değiştirici yok ' -modifier bile yoktur ) yoktur , bu yüzden açıkça yazmanız gerekmez.

Gerekli değil. Bu dilin tuhaflığı.

Arayüzdeki tüm yöntemler soyut olduğu için arayüzler varsayılan olarak soyut olduğu için gerekli değildir.

Soyut bir Arayüz en azından teoride herkesin söylediği kadar gereksiz değildir.

Bir Arayüz, tıpkı bir Sınıf gibi genişletilebilir. Uygulamanız için bir Arayüz hiyerarşisi tasarlarsanız, bir 'Temel' Arayüzünüz olabilir, diğer Arayüzleri genişletirsiniz, ancak kendi içinde bir Nesne olarak istemezsiniz.

Misal:

public abstract interface MyBaseInterface {
    public String getName();
}

public interface MyBoat extends MyBaseInterface {
    public String getMastSize();
}

public interface MyDog extends MyBaseInterface {
    public long tinsOfFoodPerDay();
}

Bir Sınıfın MyBaseInterface öğesini uygulamasını istemezsiniz, yalnızca diğer ikisi MMyDog ve MyBoat'tır, ancak her iki arabirim de MyBaseInterface arabirimini paylaşır, bu nedenle bir 'name' özelliği vardır.

Biraz akademik olduğunu biliyorum, ama bazılarının ilginç bulabileceğini düşündüm. :-)

Bu durumda, arayüzün uygulayıcılarına kendi başına uygulanacak şekilde tasarlanmamış olması gerçekten sadece bir 'işaret'. Bir derleyiciyi işaret etmeliyim (en azından denediğim güneş / ora 1.6) soyut bir arayüz uygulayan bir sınıfı derler.

'Soyut Arayüz' Lexical bir yapıdır: http://en.wikipedia.org/wiki/Lexical_analysis .

Derleyici tarafından gereklidir, ayrıca yazabilirsiniz interface.

Dilin Lexical yapısına çok fazla girmeyin, çünkü derleme işlemi sırasında veya bazı geriye dönük uyumluluk için özel durumlar olarak adlandırılan bazı derleme belirsizliğini çözmek için oraya koyabilirlerdi, temel Lexical yapısına odaklanmaya çalışın.

`Arayüzün özü, uygulaması değişebilen bazı soyut kavramları (fikir / düşünce / üst düzey düşünme vb.) Yakalamaktır ... yani, çoklu uygulama olabilir.

Arayüz, yakaladığı veya temsil ettiği Nesnenin özelliklerini temsil eden saf bir soyut veri türüdür.

Özellikler boşlukla veya zamanla temsil edilebilir. Alanla temsil edildiğinde (bellek depolama), beton sınıfınızın o alanda veya zamanla çalışacak bir alan ve yöntem / yöntem uygulayacağı anlamına gelir, bu da özelliği uygulama görevinin tamamen hesaplamalı olduğu anlamına gelir (daha fazla işlemci saati gerektirir) böylece özellik uygulaması için yer ve zaman arasında bir değiş tokuşunuz olur.

Eğer somut sınıfınız tüm özellikleri uygulamazsa, yine soyutlaşır, çünkü düşünce veya fikrinizin veya soyutluğunuzun bir uygulamasına sahip olursunuz, ancak tamamlanmamışsa, onu abstractsınıfına göre belirtirsiniz .

Somut bir sınıf, XYZ sınıfını yakalamaya çalıştığınız soyutluğu tam olarak yakalayacak bir sınıf / sınıflar kümesi olacaktır.

Yani Desen

Interface--->Abstract class/Abstract classes(depends)-->Concrete class