Neden bir arabirimdeki tüm alanlar örtük olarak statik ve nihaidir?

Sadece bir Arayüzde tanımlanan tüm alanların neden örtük olarak staticve olduğunu anlamaya çalışıyorum final. Alanları tutma fikri staticbana mantıklı geliyor çünkü bir arayüzün nesnelerine sahip olamıyorsunuz ama neden final(örtük olarak)?

Java tasarımcıları bir arayüz alanları yapmakla gitmesinin herhangi biri bilir staticve final?

Bir arayüzün davranışı veya durumu olamaz çünkü sadece bir etkileşim sözleşmesi belirtmesi amaçlanmıştır, uygulama ayrıntısı yoktur. Yöntem / yapıcı gövdelerine veya statik / örnek başlatan bloklara izin verilmeyerek 'davranış yok' uygulanır. "Durum yok" yalnızca statik son alanlara izin verilerek uygulanır. Bu nedenle, sınıfın bir durumu (statik durum) olabilir, ancak örnek durumu arabirim tarafından çıkarılmaz.

BTW: Java'da bir sabit, statik bir son alanla tanımlanır (ve geleneksel olarak ad UPPER_CASE_AND_UNDERSCORES kullanır).

Olma nedeni final

Nihai olarak tanımlanmamışlarsa, herhangi bir uygulama alanların değerini değiştirebilir. Daha sonra uygulamanın bir parçası olurlar. Arayüz, herhangi bir uygulama içermeyen saf bir özelliktir.

Olma nedeni static

Statik iseler, ne nesneye ne de nesnenin çalışma zamanı türüne değil, arayüze aittirler.

Burada parlatılan birkaç nokta var:

Bir arayüzdeki alanların örtük olarak statik nihai olması, bunların derleme zamanı sabitleri veya hatta değişmez olmaları gerektiği anlamına gelmez. Örneğin tanımlayabilirsiniz

interface I {
  String TOKEN = SomeOtherClass.heavyComputation();
  JButton BAD_IDEA = new JButton("hello");
}

(Bunu bir ek açıklama tanımının içinde yapmanın javac'ın kafasını karıştırabileceğine dikkat edin , yukarıdakilerin aslında statik bir başlatıcıda derlendiği gerçeğiyle bağlantılı olarak.)

Ayrıca, bu kısıtlamanın nedeni teknik olmaktan çok stilistiktir ve birçok insan rahatlatıldığını görmek ister .

Alanlar, soyut olamazlar (yöntemler gibi) statik olmalıdır. Soyut olamayacakları için, uygulayıcılar alanların farklı uygulamalarını mantıksal olarak sağlayamayacaklardır.

Alanların son olması gerektiğini düşünüyorum, çünkü alanlara birçok farklı uygulayıcı tarafından erişilebilmesi değiştirilebilir olmalarına izin veriyor (senkronizasyon olarak) sorunlu olabilir. Ayrıca yeniden uygulanmasını önlemek için (gizli).

Benim düşüncem.

Alanların son derece kısıtlayıcı olması gerekliliğini ve Java dili tasarımcılarının bir hatası olduğunu düşünüyorum. Arayüz tipindeki bir nesne üzerinde işlemler gerçekleştirmek için gerekli olan uygulamada sabitleri ayarlamanız gereken zamanlar vardır, örneğin ağaç işleme. Uygulama sınıfında bir kod yolu seçmek bir kludge'dir. Kullandığım geçici çözüm, bir arabirim işlevi tanımlamak ve bir değişmez değer döndürerek onu uygulamaktır:

public interface iMine {
    String __ImplementationConstant();
    ...
}

public class AClass implements iMine {
    public String __ImplementationConstant(){
        return "AClass value for the Implementation Constant";
    }
    ...
}

public class BClass implements iMine {
    public String __ImplementationConstant(){
        return "BClass value for the Implementation Constant";
    }
    ...
}

Bununla birlikte, bu sözdizimini kullanmak daha basit, daha net ve anormal uygulamaya daha az eğilimli olacaktır:

public interface iMine {
    String __ImplementationConstant;
    ...
}

public class AClass implements iMine {
    public static String __ImplementationConstant =
        "AClass value for the Implementation Constant";
    ...
}

public class BClass implements iMine {
    public static String __ImplementationConstant =
        "BClass value for the Implementation Constant";
    ...
}

Şartname, sözleşmeler ... Alan erişimi için makine talimatı, nesne adresi artı alan ofsetini kullanır. Sınıflar birçok arabirimi uygulayabildiğinden, bu arabirimi genişleten tüm sınıflarda aynı ofsete sahip nihai olmayan arabirim alanını yapmanın bir yolu yoktur. Bu nedenle, alan erişimi için farklı bir mekanizma uygulanmalıdır: bir artı sanal alan tablosu türü (sanal yöntem tablosunun analogu) yerine iki bellek erişimi (alan ofsetini al, alan değerini al). Sanırım onlar sadece mevcut şeyler (yöntemler) aracılığıyla kolayca simüle edilebilen işlevsellik için jvm'yi karmaşıklaştırmak istemediler.

Ölçeklendirmede, arayüzlerde alanlar olabilir, ancak bunlar yukarıda açıkladığım gibi (yöntem olarak) dahili olarak uygulanmaktadır.

static:

Olan herhangi bir şey (değişken ya da metodu) staticJava olarak getirilebilir Classname.variablenameya Classname.methodnameda doğrudan. Sadece nesne adını kullanarak çağırmak zorunlu değildir.

Arayüzde, nesneler bildirilemez ve staticnesne adına ihtiyaç duymadan sadece sınıf adı aracılığıyla değişkenleri çağırmayı mümkün kılar.

final:

Alt sınıflarında geçersiz kılınamayacağı için bir değişken için sabit bir değer sağlamaya yardımcı olur.