Java'da neden statik bir iç içe arabirim kullanılır?

Ben sadece bizim kod tabanı statik bir iç içe arabirim bulduk.

class Foo {
    public static interface Bar {
        /* snip */
    }
    /* snip */
}

Bunu daha önce hiç görmedim. Orijinal geliştiriciye erişilemiyor. Bu yüzden SO sormak zorunda:

Statik bir arayüzün ardındaki anlamlar nelerdir? Kaldırırsam ne değişecekti static? Biri bunu neden yapar ki?

Yukarıdaki örnekteki statik anahtar kelime gereksizdir (iç içe bir arabirim otomatik olarak "statik" tir) ve anlambilimi etkilemeden kaldırılabilir; Kaldırılmasını tavsiye ederim. Aynı şey arabirim yöntemlerinde "genel" ve arabirim alanlarında "genel final" için de geçerlidir - değiştiriciler gereksizdir ve sadece kaynak koduna karmaşa ekler.

Her iki durumda da, geliştirici sadece Foo.Bar adında bir arabirim bildiriyor. Foo'ya erişemeyen kodun Foo.Bar'a da erişemeyeceği dışında, ek sınıfla başka bir ilişki yoktur. (Kaynak kodundan - bayt kodu veya yansıma Foo paket özel olsa bile Foo.Bar'a erişebilir!)

Yeni bir üst düzey ad oluşturmamanız için, yalnızca dış sınıftan kullanılmasını beklerseniz bu şekilde iç içe bir arabirim oluşturmak kabul edilebilir bir stildir. Örneğin:

public class Foo {
    public interface Bar {
        void callback();
    }
    public static void registerCallback(Bar bar) {...}
}
// ...elsewhere...
Foo.registerCallback(new Foo.Bar() {
    public void callback() {...}
});

Soru cevaplandı, ancak iç içe bir arabirim kullanmanın iyi bir nedeni, işlevinin doğrudan içinde bulunduğu sınıfla ilgili olup olmadığıdır. Bunun iyi bir örneği a Listener. Bir sınıfınız varsa Foove diğer sınıfların olayları dinleyebilmesini istiyorsanız FooListener, tamam adında bir arabirim bildirebilirsiniz, ancak tamam, ancak iç içe bir arabirim bildirmek ve bu diğer sınıfların uygulanmasını sağlamak daha açık olacaktır Foo.Listener( yuvalanmış bir sınıf Foo.Eventbununla birlikte kötü değildir).

Üye arabirimleri dolaylı olarak statiktir. Örneğinizdeki statik değiştirici, kodun anlamını değiştirmeden kaldırılabilir. Ayrıca bkz. Java Dil Spesifikasyonu 8.5.1. Statik Üye Tipi Beyanları

Bir iç arabirime erişilebilmesi için statik olması gerekir. Arabirim sınıfın örnekleriyle değil, sınıfın kendisiyle ilişkilendirilir, dolayısıyla şu şekilde erişilebilir Foo.Bar:

public class Baz implements Foo.Bar {
   ...
}

Çoğu durumda, bu statik bir iç sınıftan farklı değildir.

Jesse'nin cevabı yakın, ama iç arayüzün neden faydalı olabileceğini göstermek için daha iyi bir kod olduğunu düşünüyorum. Okumaya başlamadan önce aşağıdaki koda bakın. İç arayüzün neden faydalı olduğunu bulabilir misiniz? Cevap, DoSomethingAlready sınıfı A ve C'yi uygulayan herhangi bir sınıfla başlatılabilir ; sadece beton sınıfı Zoo değil. Tabii ki, AC içsel olmasa bile elde edilebilir, ancak daha uzun isimleri (sadece A ve C değil) birleştirmeyi ve bunu diğer kombinasyonlar için (örneğin, A ve B, C ve B, vb.) Yaptığınızı ve kolayca işlerin nasıl kontrolden çıktığını görün. Kaynak ağacınızı gözden geçiren kişilerin yalnızca bir sınıfta anlamlı olan arayüzler tarafından boğulacağından bahsetmiyoruz bile. iç arabirim , özel türlerin inşa edilmesini sağlar ve kapsüllemelerini geliştirir .

class ConcreteA implements A {
 :
}

class ConcreteB implements B {
 :
}

class ConcreteC implements C {
 :
}

class Zoo implements A, C {
 :
}

class DoSomethingAlready {
  interface AC extends A, C { }

  private final AC ac;

  DoSomethingAlready(AC ac) {
    this.ac = ac;
  }
}

Sorunuza doğrudan cevap vermek için Map.Entry'ye bakınız.

Map.Entry

ayrıca bu yararlı olabilir

Statik Yuvalanmış Arayüzler blogu Girişi

Genellikle statik iç sınıflar görüyorum. Statik iç sınıflar, statik olmayan sınıfların yapabileceği kapsayıcı sınıflara başvuramaz. Bazı paket çarpışmalarına girmediğiniz sürece (zaten Foo ile aynı pakette Bar adında bir arayüz var) Sanırım bu dosyayı kendi dosyası yapardım. Foo ve Bar arasındaki mantıksal bağlantıyı uygulamak da bir tasarım kararı olabilir. Belki de yazar Bar'ın sadece Foo ile birlikte kullanılmasını istedi (statik bir iç arayüz bunu zorlamayacak, sadece mantıklı bir bağlantı)

Sınıf Foo'yu Foo arayüzüne dönüştürürseniz, yukarıdaki örnekteki "public" anahtar kelimesi de gereksiz olacaktır, çünkü

başka bir arayüzde tanımlanan arayüz dolaylı olarak halka açık statik olacaktır .

1998'de Philip Wadler statik arayüzler ile statik olmayan arayüzler arasında bir fark önermiştir.

Görebildiğim kadarıyla, bir arabirimi statik olmayan hale getirmedeki tek fark, artık statik olmayan iç sınıfları içerebilmesidir; bu nedenle değişiklik mevcut Java programlarını geçersiz hale getirmez.

Örneğin , bir yandan “diliniz ne kadar ifade edebilir” ifadesi, diğer yandan “kendi dilinizde temsil etmeye çalıştığınız terimler” ifadesi arasındaki uyumsuzluk olan İfade Problemine bir çözüm önerdi. .

Statik ve statik olmayan yuvalanmış arabirimler arasındaki farkın bir örneği, örnek kodunda görülebilir :

// This code does NOT compile
class LangF<This extends LangF<This>> {
    interface Visitor<R> {
        public R forNum(int n);
    }

    interface Exp {
        // since Exp is non-static, it can refer to the type bound to This
        public <R> R visit(This.Visitor<R> v);
    }
}

Onun önerisi asla Java 1.5.0'da yapılmadı. Bu nedenle, diğer tüm cevaplar doğrudur: statik ve statik olmayan iç içe arabirimler arasında bir fark yoktur.

Java'da statik arabirim / sınıf, arabirimin / sınıfın üst düzey bir sınıf gibi kullanılmasına izin verir, yani diğer sınıflar tarafından bildirilebilir. Böylece şunları yapabilirsiniz:

class Bob
{
  void FuncA ()
  {
    Foo.Bar foobar;
  }
}

Statik olmadan, yukarıdaki derleme başarısız olur. Bunun avantajı, sadece arayüzü bildirmek için yeni bir kaynak dosyasına ihtiyacınız olmamasıdır. Ayrıca Foo.Bar yazmanız gerektiğinden Bar arayüzünü görsel olarak Foo sınıfıyla ilişkilendirir ve Foo sınıfının Foo.Bar örnekleri ile bir şey yaptığını ima eder.

Java'daki sınıf türlerinin açıklaması .

Statik, paketin (projenin) herhangi bir sınıf bölümünün bir işaretçi kullanmadan erişebileceği anlamına gelir. Bu duruma bağlı olarak yararlı veya engelleyici olabilir.

"Statik" yöntemlerin yararlı örneklerine Math sınıfı verilebilir. Math'daki tüm yöntemler statiktir. Bu, yoldan çıkmak, yeni bir örnek yapmak, değişkenleri bildirmek ve daha da fazla değişkene depolamak zorunda olmadığınız anlamına gelir, sadece verilerinizi girebilir ve sonuç alabilirsiniz.

Statik her zaman işe yaramaz. Örneğin büyük / küçük harf karşılaştırması yapıyorsanız, verileri birkaç farklı şekilde depolamak isteyebilirsiniz. Aynı imzalarla üç statik yöntem oluşturamazsınız. Statik olmayan 3 farklı örneğe ihtiyacınız var ve statik ise, veriler girişle birlikte değişmeyecektir.

Statik yöntemler, bir kerelik geri dönüşler ve hızlı hesaplamalar veya kolay elde edilen veriler için iyidir.