Arayüzlerde Korumalı

Neden tüm yöntemler interfaceörtük olarak bir tanım içindedir public? Neden bir protectedyönteme izin vermiyor ?

Çünkü arayüz, "sınıfın dışından görebileceğiniz şeyler" anlamına gelmelidir. Kamuya açık olmayan yöntemler eklemek mantıklı olmaz.

Sıklıkla dile getirilen neden "arayüzlerin genel API'leri tanımlaması" olmasına rağmen, bence bu aşırı bir basitleştirme. (Ve dairesel mantığın da "kokusu" var.)

Erişim değiştiricilerinin bir karışımına sahip arayüzlere sahip olmak anlamsız olmayacaktır; örneğin, kısmen genel ve kısmen arayüzle aynı paketteki diğer sınıflarla sınırlıdır. Aslında, bazı durumlarda bu çok yararlı olabilir, IMO.

Aslında, bir arayüzün üyelerini örtük olarak herkese açık hale getirmenin arkasındaki mantığın parçası , Java dilini daha basit hale getirmesi olduğunu düşünüyorum :

• Örtük olarak genel arayüz üyeleri, programcıların uğraşması için daha kolaydır. Yöntem erişim değiştiricilerinin görünüşte rastgele seçildiği kodu (sınıfları) kaç kez gördünüz? Pek çok "sıradan" programcı, Java soyutlama sınırlarının en iyi nasıl yönetileceğini anlamakta güçlük çekiyor ¹ . Arayüzlere genel / korumalı / özel paket eklemek, işleri onlar için daha da zorlaştırır.

• Örtük olarak genel arabirim üyeleri, dil belirtimini basitleştirir ... ve dolayısıyla Java derleyici yazarları ve Yansıma API'lerini uygulayanlar için görevi basitleştirir.

"Arayüzlerin genel API'leri tanımladığı" düşüncesi, muhtemelen basitleştirici dil tasarım kararının bir sonucudur (veya karakteristiğidir) ... tam tersi değil. Fakat gerçekte, Java tasarımcılarının zihinlerinde muhtemelen iki düşünce çizgisi paralel olarak gelişti.

Her halükarda, JDK-8179193'teki RFE'ye verilen resmi yanıt , Java tasarım ekibinin , arabirimlere izin vermenin çok az gerçek fayda sağlayacak şekilde karmaşıklık eklediğine ² karar verdiğini açıkça ortaya koymaktadır protected. Kudos için @skomisa için kanıt bulma .

RFE'deki kanıt sorunu çözüyor. Bunun eklenmemesinin resmi nedeni budur.

^{1 - Tabii ki, en iyi programcılar bu konularda zorluk çekmezler ve daha zengin bir erişim kontrol özellikleri paletini memnuniyetle karşılayabilir. Ancak, kodları bakımı için başka birine verildiğinde ne olur?}

^{2 - Kararlarına veya beyan ettikleri gerekçeye katılmayabilirsiniz, ancak bu tartışmalıdır.}

Java 8'de varsayılan yöntemlerin tanıtılmasıyla bu sorunun yeniden açıldığını söylemeliyim. Şu anda üzerinde çalıştığım proje, bir arayüzün temel doğasına benzer şekilde, niyetin uygulamadan soyutlanmasıdır.

Kodumu "varsayılan korumalı" bir yöntemle büyük ölçüde basitleştirebileceğim birkaç durum vardır. Arayüzler hala Java 7 mantığına bağlı kaldığından, bunun gerçekten çalışmadığı ortaya çıktı. Normal korumalı bir yöntem, yukarıda belirtilen nedenlerden ötürü özellikle mantıklı değildir; ancak varsayılan bir genel yöntem, muhtemelen değişmeyecek ve korumalı bir yöntemle sağlanabilecek düşük seviyeli bir kaynak gerektiriyorsa, bana öyle geliyor ki, "varsayılan korumalı" çalışmaya sahip olmak yalnızca daha temiz kod sağlamakla kalmaz, aynı zamanda gelecekteki kullanıcıları kazara suistimaller.

(Bu trajik bir şekilde, kodumu başka türlü gereksiz özetlerle aşırı karmaşık hale getirmem gerektiği gerçeğini değiştirmez; ancak Oracle'a bir özellik isteği eklemeyi düşünüyorum.)

Çünkü arayüzler genel API'leri tanımlar. Korunan her şey, bir arayüze ait olmayan dahili bir ayrıntıdır.

Soyut sınıfları korumalı soyut yöntemlerle kullanabilirsiniz, ancak arabirimler genel yöntemler ve genel statik son alanlarla sınırlıdır.

Belki de bir arayüz olduğu için , yani müşterilere ne yapamayacaklarını söylemek yerine örneklerle neler yapabileceklerini söylemek için var.

Ben kuvvetle arayüzleri korumalı yöntemleri izin vermelidir hissediyorum; arayüzlerin tüm dünyadaki herkes tarafından görülebilir olması gerektiğini kim söyledi? "Sıradan" (okuma: beceriksiz) programcıların kafasını karıştırabileceğine gelince: OOP'nin çoğu, nesneleri, sınıfları, paketleri vb. çok daha büyük bir problem. Java edildi inşa şeyin türü için.

Buradaki birkaç cevap, arayüz yöntemlerinin neden korunamayacağını açıklamak için döngüsel akıl yürütme kullanır: bunun nedeni, halka açık olmaları gerektiğidir, bu yüzden açıkça korunamazlar!

Bu hiçbir şeyi açıklamıyor, ancak neyse ki bir kişi , birkaç yıl önce bir JDK hatası olarak arabirimlerde korunan yöntemler için bir geliştirme talebinde bulundu ve bu konuya biraz ışık tutuyor:

Arayüzlerde korumalı yöntemler: paketler arasında paylaşın

Java'da değiştiriciler biraz sınırlı olduğundan, yöntemleri paketler arasında paylaşmanın bir yolu genel yöntemlerle sınırlıdır. Bazen bir yöntemi halka açık hale getirmek tehlikelidir, ancak uygun değiştiricilerin eksikliğinden kaynaklanması gerekir. Benim çözümüm bu sınırlamanın üstesinden geliyor.

Java dili belirtimi şu anda arabirim yöntemleri için korumalı değiştiriciye izin vermiyor. Bu olgudan faydalanabilir ve bu yeni özellik için arayüz için korumalı yöntemleri kullanabiliriz.

Bir arabirim yöntemi korumalı olarak işaretlenirse ve arabirim başka bir paketteki bir sınıf tarafından uygulanırsa, yöntemin genel olması gerekmez, ancak özel veya en azından paket korumalı da olabilir. Yöntem görünürdür, sınıf ne olursa olsun ve ek olarak arabirimin kaynak paketinde (ve alt paketlerde?) Görünür.

Bu şekilde, iyi bilinen paketler arasında belirli yöntemleri paylaşabilirdik.

Durumla kapatılan bu geliştirme isteğine verilen yanıt şudur Won't fix:

Bu öneri, bir sorunu, çok az gerçek kazanç için karmaşıklık ve özel durumlar ekleyerek çözmeye çalışır. Bu sorunu çözmenin tipik bir yolu, genel bir arabirim uygulayan özel bir sınıfa sahip olmaktır. Uygulama yöntemleri geneldir, ancak özel bir sınıf içindedir, bu nedenle özel kalırlar.

Java 9'dan başlayarak kullanılabilen bir alternatif, sınıfları ve yöntemleri herkese açık hale getirmektir, ancak genel olarak dışa aktarılmak yerine belirli "arkadaş" modüllerine nitelikli dışa aktarımı olan bir modül içinde.

Dolayısıyla, bu hata raporundan elde edilen güvenilir çıkarımlar şunlardır:

• Mevcut durum değişmeyecek; arayüzlerin protectedyöntemleri destekleme olasılığı düşüktür .
• protectedArayüzlerde yöntemleri desteklememesinin gerekçesi, " az gerçek kazanç için karmaşıklık ve özel durumlar eklemesidir ".
• Java 9'dan beri, yöntemlere paket düzeyinde erişim sağlamak için alternatif bir yaklaşım vardır. Kullanım Java Platform Modülü Sistemi (JPMS) için " 'yerine halka ihraç edilme modüllerin arkadaşı yapmak sınıflar ve kamu yöntemlerle, ancak belirli bir nitelikli ihracatı olan bir modül içinde' ".

Uygulama sınıfı, arayüzünüzde bildirilen TÜM yöntemleri uygulamak zorunda olduğundan, uygulama sınıfınız farklı bir pakette olsaydı ne olurdu?

Arayüz Açıkladığınız gibi bir şey kullanmak istiyorsanız, soyut sınıflarla veya iç içe arayüzlerle devam edin.

Arayüz değişkenleri hakkında Kod Stilinden bir alıntı , ancak yine de yöntemler için geçerlidir:

Arayüz değişkenleri dolaylı olarak halka açıktır çünkü arayüzler, Java programcıları tarafından kendi uygulamalarında referans ve uygulama için tamamen erişilebilir olan bir Uygulama Programlama Arayüzü (API) sağlamayı amaçlamaktadır. Java paketlerinde kendi arayüzlerinden farklı bir arayüz kullanılabileceğinden, genel görünürlük program kodunun değişkene erişebilmesini sağlar.

Dahili alt protectedarayüzleri bildirmek iyi bir uygulamadır, ancak teknik olarak Java'daki bir arayüzde olduğu gibi dahili yöntemlerinizi açıklayamazsınız .

Tabii ki, dahili kullanım için ortak arayüzü genişleten başka bir arayüz oluşturabilirsiniz:

package yourpackage;

public interface PublicInterface {

    public void doThing1();

    public void doThing2();

    public void doThing3();

}

package yourpackage;

interface InternalInterface extends PublicInterface {

    void doAnyInternalThing1();

    void doAnyInternalThing2();

}

InternalInterfaceArabirimi paketin içinde kullanabilirsiniz , ancak aşağıdakilerin herhangi bir alt türünü kabul etmelisiniz PublicInterface(genel yöntemlerde):

package yourpackage;

public class SomeClass {

    public void someMethod(PublicInterface param) {
        if (param instanceof InternalInterface) {
            // run the optimized code
        } else {
            // run the general code
        }
    }

}

Paket dışı kullanıcılar sorunsuz kullanabilirler PublicInterface.

Genellikle programcılar benzer durumlarda soyut sınıflar oluşturur. Ancak bu durumda çoklu mirasın faydalarını kaybediyoruz.

Bunun mantıklı olacağı tek senaryo, görünürlüğü aynı paketle sınırlandırmak istediğiniz zamandır. Ürününün diğer tüm kullanımları protectedgeçerli değildir. Özellikle, protectedyöntemler genellikle nesiller için daha düşük seviyeli uygulamaların bazı ayrıntılarına erişim sağlamak için kullanılır. Ancak, ortaya çıkarılacak daha düşük seviyeli bir uygulama olmadığından, bunu bir arayüzde beyan etmek bir anlam ifade etmiyor.

Ve hatta paket senaryosu bile arayüzlerin gerçekte ne olduğu değildir.

Muhtemelen istediğinizi elde etmek için, biri dahili kullanım için, diğeri genel API'de ifşa ettiğiniz iki arayüze ihtiyacınız var. (Muhtemelen dahili olanla, ancak kamusal olanı genişletmesi gerekmiyor.) Veya, diğerlerinin de belirttiği gibi, soyut bir üst sınıf.

Korumalı yöntemlere her zaman alt sınıf tarafından erişilebilir, ancak alt sınıf temel sınıfı genişletirse.

Arayüz durumunda, alt sınıf asla arayüzü genişletmez. Arayüzü uygular.

Korumalı yöntemlere uygulama ile değil, genişletme yoluyla erişilebilir .

Arayüzler, yöntemleri dış dünyaya göstermek içindir . Dolayısıyla bu yöntemler doğası gereği halka açıktır. Bununla birlikte, aynı sınıf ailesi içinde soyutlamayı tanıtmak istiyorsanız , arayüzünüz ile uygulama sınıfı arasında başka bir soyutlama seviyesi, yani soyut bir sınıf oluşturmakla mümkündür. Aşağıda bir örnek gösterilmiştir.

public interface MyInterface {
    public void publicMethod(); // needs to be public
}

public abstract class MyAbstractClass implements MyInterface {
    @Override
    public void publicMethod() {
        protectedMethod(); // you can call protected method here
        // do other stuff
    }
    protected abstract void protectedMethod(); // can be protected
}

public class MyClass extends MyAbstractClass {
    @Override
    protected void protectedMethod() {
        // implement protected method here, without exposing it as public
    }
}