Java Arayüzünde İsteğe Bağlı Yöntemler

Anladığım kadarıyla, java'da bir arabirim uygularsanız, bu arabirimde belirtilen yöntemler, söz konusu arabirimi uygulayan alt sınıflar tarafından kullanılmalıdır.

Koleksiyon arayüzü gibi bazı arayüzlerde isteğe bağlı olarak yorumlanan yöntemler olduğunu fark ettim, ancak bu tam olarak ne anlama geliyor? Arayüzde belirtilen tüm yöntemlerin gerekli olacağını düşündüğüm için beni biraz attı?

Buradaki cevaplarda çok fazla kafa karışıklığı var gibi görünüyor.

Java dili, bir arabirimdeki her yöntemin o arabirimin her uygulaması tarafından uygulanmasını gerektirir. Dönemi. Bu kuralın istisnası yoktur. "Koleksiyonlar bir istisnadır" demek, burada gerçekte neler olup bittiğine dair çok belirsiz bir anlayışa işaret eder.

Bir arayüze uymanın iki tür düzeyi olduğunu anlamak önemlidir:

1. Java dilinin neyi kontrol edebileceği. Bu hemen hemen şu sonuca varıyor: Yöntemlerin her biri için bazı uygulamalar var mı?

2. Aslında sözleşmeyi yerine getirmek. Yani, uygulama arayüzdeki dokümantasyonun yapması gerektiğini söylediği şeyi yapıyor mu?

   İyi yazılmış arayüzler, uygulamalardan tam olarak ne beklendiğini açıklayan belgeleri içerecektir. Derleyiciniz bunu sizin için kontrol edemez. Belgeleri okumanız ve dediklerini yapmanız gerekir. Sözleşmenin söylediği şeyi yapmazsanız, derleyici söz konusu olduğu sürece arayüzün bir uygulamasına sahip olacaksınız , ancak bu hatalı / geçersiz bir uygulama olacaktır.

Joshua Bloch, Koleksiyonlar API'sini tasarlarken, koleksiyonların farklı varyantlarını (ör. Okunabilir, yazılabilir, rastgele erişim, vb.) Ayırt etmek için çok ince taneli arayüzlere sahip olmak yerine yalnızca çok kaba arayüzlere sahip olacağına karar verdi. Collection, List, Setve Map, ve sonra "isteğe bağlı" gibi belirli işlemleri belgelemek. Bu, ince taneli arayüzlerden kaynaklanacak kombinasyon patlamasını önlemek içindi. Gönderen Java Koleksiyonları API Tasarım SSS :

Sorunu kanlı ayrıntılarıyla açıklamak için, değiştirilebilirlik kavramını Hiyerarşiye eklemek istediğinizi varsayalım. Dört yeni arabirime ihtiyacınız var: ModifiableCollection, ModifiableSet, ModifiableList ve ModifiableMap. Önceden basit bir hiyerarşi olan şey, şimdi dağınık bir heterarşidir. Ayrıca, değiştirilemeyen Koleksiyonlarla kullanmak için kaldırma işlemini içermeyen yeni bir Yineleyici arayüzüne ihtiyacınız vardır. Şimdi UnsupportedOperationException'ı ortadan kaldırabilir misiniz? Ne yazık ki değil.

Dizileri düşünün. List işlemlerinin çoğunu uygularlar, ancak kaldırıp eklemezler. Bunlar "sabit boyutlu" Listelerdir. Hiyerarşide bu kavramı yakalamak istiyorsanız, iki yeni arayüz eklemeniz gerekir: VariableSizeList ve VariableSizeMap. VariableSizeCollection ve VariableSizeSet'i eklemeniz gerekmez, çünkü bunlar ModifiableCollection ve ModifiableSet ile aynı olacaktır, ancak tutarlılık adına bunları yine de eklemeyi seçebilirsiniz. Ayrıca, değiştirilemez Liste ile birlikte gitmek için ekleme ve kaldırma işlemlerini desteklemeyen yeni bir ListIterator çeşidine ihtiyacınız vardır. Şimdi, orijinal dördümüz yerine on veya on iki arayüze ek olarak iki yeni yineleyici arayüzümüz var. Tamam mıyız? Hayır.

Günlükleri dikkate alın (hata günlükleri, denetim günlükleri ve kurtarılabilir veri nesneleri için günlükler gibi). Bunlar, kaldırma ve ayarlama (değiştirme) dışındaki tüm Liste işlemlerini destekleyen, yalnızca eklenebilir doğal dizilerdir. Yeni bir çekirdek arayüz ve yeni bir yineleyici gerektirirler.

Değiştirilemez koleksiyonların aksine değişmez Koleksiyonlar ne olacak? (yani, müşteri tarafından değiştirilemeyen VE başka bir nedenle asla değişmeyen koleksiyonlar). Birçoğu bunun en önemli ayrım olduğunu savunuyor, çünkü birden fazla iş parçacığının bir koleksiyona senkronizasyona gerek kalmadan aynı anda erişmesine izin veriyor. Bu desteğin tür hiyerarşisine eklenmesi, dört arabirim daha gerektirir.

Şimdi yirmi kadar arayüz ve beş yineleyiciyiz ve pratikte hala arayüzlerin hiçbirine tam olarak uymayan koleksiyonların olduğu kesindir. Örneğin, Map tarafından döndürülen koleksiyon görünümleri, yalnızca silinebilen doğal koleksiyonlardır. Ayrıca, belirli öğeleri değerlerine göre reddedecek koleksiyonlar da vardır, bu nedenle çalışma zamanı istisnalarını hala ortadan kaldırmadık.

Her şey söylendiğinde ve yapıldığında, bir çalışma zamanı istisnası atabilecek çok küçük bir çekirdek arabirim seti sağlayarak tüm sorunu ortadan kaldırmanın sağlam bir mühendislik uzlaşması olduğunu hissettik.

Koleksiyonlar API'sindeki yöntemler "isteğe bağlı işlemler" olarak belgelendiğinde, bu, yalnızca yöntem uygulamasını uygulamada bırakabileceğiniz anlamına gelmez veya boş bir yöntem gövdesi kullanabileceğiniz anlamına gelmez (bir şey için, çoğu bir sonuç döndürmeleri gerekir). Daha ziyade, geçerli bir uygulama seçeneğinin (sözleşmeye hala uygun olan) bir UnsupportedOperationException.

UnsupportedOperationExceptionBir olduğundan , RuntimeExceptionderleyici söz konusu olduğunda, herhangi bir yöntem uygulamasından atabileceğinizi unutmayın . Örneğin, bir uygulamasından atabilirsiniz Collection.size(). Bununla birlikte, böyle bir uygulama sözleşmeyi ihlal eder, çünkü belgeleri Collection.size()buna izin verildiğini söylememektedir.

Bir kenara: Java'nın Koleksiyonlar API'si tarafından kullanılan yaklaşım biraz tartışmalı (ancak muhtemelen ilk sunulduğu zamandan daha az). Mükemmel bir dünyada, arayüzler olur değil opsiyonel operasyonları var, ve ince taneli arayüzleri yerine kullanılacaktır. Sorun, Java'nın çıkarsanan yapısal türleri veya kesişim türlerini desteklememesidir, bu nedenle işleri "doğru şekilde" yapmaya çalışmak, koleksiyonlar söz konusu olduğunda son derece hantal hale gelir.

Bir arayüz için uygulama (soyut olmayan) sınıfını derlemek için - tüm yöntemler uygulanmalıdır.

Bununla birlikte , uygulamasının basit bir istisna atışı olduğunu düşünürsek ( Collectionarayüzdeki bazı yöntemler gibi ), Collectionbu durumda arayüz istisnadır, normal durum değil. Genellikle , sınıfın uygulanması tüm yöntemleri uygulamalıdır (ve uygulayacaktır).

Koleksiyondaki "isteğe bağlı", uygulama sınıfının onu (yukarıdaki terminolojiye göre) "uygulaması" gerekmediği ve yalnızca fırlatacağı anlamına gelir NotSupportedException.

İyi bir örnek add()- değişmez koleksiyonlar için yöntem - beton, fırlatmaktan başka hiçbir şey yapmayan bir yöntem uygulayacaktır.NotSupportedException

Durumunda ise Collectionbunun dağınık kalıtım ağaçları önlemek için yapılır, bu programcılar mutsuz yapacaktır - ama için en durumlarda, bu paradigma tavsiye edilmez ve mümkünse kaçınılmalıdır.

Güncelleme:

Java 8'den itibaren, varsayılan bir yöntem tanıtıldı.

Bu, bir arayüzün, uygulaması dahil bir yöntemi tanımlayabileceği anlamına gelir.
Bu, yeni işlevselliğe ihtiyaç duymayan kod parçaları için geriye dönük uyumluluğu desteklemeye devam ederken, arayüzlere işlevsellik eklemeye izin vermek için eklenmiştir.

Yöntemin, onu bildiren tüm sınıflar tarafından, ancak arabirimin tanımını kullanarak uygulandığına dikkat edin.

Java'daki bir arayüz sadece sınıfları uygulama sözleşmesini ilan eder. Bu arayüzde tüm yöntemler olmalıdır uygulanacak, ancak uygulama sınıfları yani., Boş, onları Uygulanmayan ayrılabilirsiniz. Yapmacık bir örnek olarak,

interface Foo {
  void doSomething();
  void doSomethingElse();
}

class MyClass implements Foo {
  public void doSomething() {
     /* All of my code goes here */
  }

  public void doSomethingElse() {
    // I leave this unimplemented
  }
}

Şimdi doSomethingElse(), alt sınıflarımın uygulaması için ücretsiz bırakarak, uygulanmamış bıraktım . Bu isteğe bağlıdır.

class SubClass extends MyClass {
    @Override
    public void doSomethingElse() {
      // Here's my implementation. 
    }
}

Ancak, Koleksiyon arayüzlerinden bahsediyorsanız, diğerlerinin de söylediği gibi, bunlar bir istisnadır. Bazı yöntemler uygulanmadan bırakılırsa ve siz bunları çağırırsanız, UnsupportedOperationExceptionistisnalar atabilirler .

Koleksiyon arayüzündeki isteğe bağlı yöntemler, yöntemin uygulanmasının bir istisna atmasına izin verildiği, ancak yine de uygulanması gerektiği anlamına gelir. Dokümanlarda belirtildiği gibi :

Bazı koleksiyon uygulamalarının, içerebilecekleri öğeler üzerinde kısıtlamaları vardır. Örneğin, bazı uygulamalar boş öğeleri yasaklar ve bazılarının öğelerinin türlerinde kısıtlamaları vardır. Uygun olmayan bir öğe eklemeye çalışmak, denetlenmemiş bir istisna atar, genellikle NullPointerException veya ClassCastException. Uygun olmayan bir öğenin varlığını sorgulamaya çalışmak bir istisna oluşturabilir veya basitçe yanlış döndürebilir; bazı uygulamalar önceki davranışı sergileyecek ve bazıları ikincisini sergileyecektir. Daha genel olarak, tamamlanması uygun olmayan bir öğenin koleksiyona eklenmesiyle sonuçlanmayacak olan uygun olmayan bir öğe üzerinde bir işlem yapmaya çalışmak, uygulama seçeneğine bağlı olarak bir istisna atabilir veya başarılı olabilir. Bu tür istisnalar "isteğe bağlı" olarak işaretlenmiştir

Kodun derlenmesi için tüm yöntemlerin uygulanması gerekir ( defaultJava 8+ uygulamalarına sahip olanlar dışında ), ancak uygulamanın işlevsel olarak yararlı hiçbir şey yapması gerekmez. Özellikle, o:

• Boş olabilir (boş bir yöntem.)
• Sadece bir UnsupportedOperationException(veya benzeri) atabilir

İkinci yaklaşım genellikle toplama sınıflarında alınır - tüm yöntemler hala uygulanır, ancak bazıları çalışma zamanında çağrılırsa bir istisna atabilir.

Aslında SurfaceView.Callback2'den ilham alıyorum. Bence bu resmi yol

public class Foo {
    public interface Callback {
        public void requiredMethod1();
        public void requiredMethod2();
    }

    public interface CallbackExtended extends Callback {
        public void optionalMethod1();
        public void optionalMethod2();
    }

    private Callback mCallback;
}

Sınıfınızın isteğe bağlı yöntemleri uygulaması gerekmiyorsa, yalnızca "Geri Çağırma uygular". Sınıfınızın isteğe bağlı yöntemler uygulaması gerekiyorsa, yalnızca "CallbackExtended'i uygular".

Bok İngiliz için özür dilerim.

Java 8 ve sonraki sürümlerde, bu sorunun cevabı hala geçerlidir, ancak şimdi daha ayrıntılıdır.

İlk olarak, kabul edilen cevaptaki şu ifadeler doğru kalır:

• arabirimler, bir sözleşmedeki örtük davranışlarını belirtmek içindir (geçerli sayılmaları için sınıfları uygulayanların uyması gereken davranış kuralları beyanı)
• sözleşme (kurallar) ile uygulama (kuralların programlı kodlaması) arasında bir ayrım vardır
• arayüzde belirtilen yöntemler HER ZAMAN uygulanmalıdır ZORUNLU (bir noktada)

Peki, Java 8'de yeni olan nüans nedir? "İsteğe Bağlı Yöntemler" den bahsederken , aşağıdakilerden herhangi biri artık uygundur:

1. Uygulanması sözleşmeye bağlı olarak isteğe bağlı olan bir yöntem

"Üçüncü ifade", soyut arayüz yöntemlerinin her zaman uygulanması gerektiğini ve bunun Java 8+ için geçerli olduğunu söyler. Bununla birlikte, Java Koleksiyonları Çerçevesinde olduğu gibi, bazı soyut arayüz yöntemlerini sözleşmede "isteğe bağlı" olarak tanımlamak mümkündür.

Bu durumda, arayüzü uygulayan yazar, yöntemi uygulamamayı seçebilir. Bununla birlikte, derleyici bir uygulama konusunda ısrarcı olacaktır ve bu nedenle yazar, bu kodu belirli uygulama sınıfında gerekmeyen isteğe bağlı yöntemler için kullanır:

public SomeReturnType optionalInterfaceMethodA(...) {
    throw new UnsupportedOperationException();
}

Java 7 ve önceki sürümlerde, bu gerçekten var olan tek tür "isteğe bağlı yöntem" idi, yani, uygulanmadığı takdirde bir UnsupportedOperationException atan bir yöntemdi. Bu davranış zorunlu olarak arayüz sözleşmesi tarafından belirtilir (örn. Java Collections Framework'ün isteğe bağlı arayüz yöntemleri).

2. Yeniden uygulanması isteğe bağlı olan varsayılan bir yöntem

Java 8, varsayılan yöntemler kavramını tanıttı . Bunlar, uygulaması arayüz tanımının kendisi tarafından sağlanabilen ve sağlanan yöntemlerdir. Genelde, yalnızca yöntem gövdesi diğer arabirim yöntemleri (yani, "ilkeller") kullanılarak yazılabildiğinde ve this"sınıfı bu arabirimi uygulayan bu nesne" anlamına gelebildiğinde varsayılan yöntemler sağlamak mümkündür .

Varsayılan bir yöntem, arabirimin sözleşmesini yerine getirmelidir (tıpkı diğer arabirim yöntemlerinin uygulanması gerektiği gibi). Bu nedenle, bir uygulama sınıfında arabirim yönteminin bir uygulamasını belirtmek yazarın takdirine kalmıştır (davranış amacına uygun olduğu sürece).

Bu yeni ortamda, Java Collections Framework şu şekilde yeniden yazılabilir:

public interface List<E> {
    :
    :
    default public boolean add(E element) {
        throw new UnsupportedOperationException();
    }
    :
    :
}

Bu şekilde, "isteğe bağlı" yöntem add(), uygulama sınıfı kendi başına hiçbir yeni davranış sağlamazsa bir UnsupportedOperationException varsayılan davranışına sahiptir, bu tam olarak olmasını isteyeceğiniz şeydir ve List sözleşmesiyle uyumludur. Bir yazar, List uygulamasına yeni öğelerin eklenmesine izin vermeyen bir sınıf yazıyorsa add(), varsayılan davranış tam olarak gerekli olduğu için uygulanması isteğe bağlıdır.

Bu durumda, yukarıdaki "üçüncü ifade" hala geçerlidir, çünkü yöntem arayüzün kendisinde uygulanmıştır.

3. OptionalSonuç döndüren bir yöntem

Son yeni tür isteğe bağlı yöntem, basitçe bir Optional. OptionalSınıf ile uğraşan bir kararlılıkla daha nesne yönelimli yol sağlar nullsonuçları.

Yeni Java Streams API ile kodlama yaparken yaygın olarak görülen tür gibi akıcı bir programlama stilinde, herhangi bir noktada boş bir sonuç, programın bir NullPointerException ile çökmesine neden olur. OptionalSınıf kazasında istemci kodu neden olmadan akıcı stili sağlayan bir şekilde müşteri koduna boş sonuçlarını döndürmek için bir mekanizma sağlar.

Tüm koleksiyon uygulamaları için bir üst sınıf olan grepCode'da AbstractCollection.java kodunun üzerinden geçersek, isteğe bağlı yöntemlerin anlamını anlamamıza yardımcı olacaktır. AbstractCollection sınıfındaki add (e) yönteminin kodu. toplama arayüzüne göre toplama (e) yöntemi isteğe bağlıdır

public boolean  add(E e) {

        throw new UnsupportedOperationException();
    } 

İsteğe bağlı yöntem, üst sınıflarda zaten uygulandığı ve çağrı üzerine UnsupportedOperationException attığı anlamına gelir. Koleksiyonumuzu değiştirilebilir hale getirmek istiyorsak , koleksiyon arayüzünde isteğe bağlı yöntemleri geçersiz kılmalıyız .

Pekala, bu konuya değinildi ... evet .. ama düşünün, bir cevap eksik. Arayüzlerin "Varsayılan Yöntemlerinden" bahsediyorum. Örneğin, herhangi bir şeyi (yıkıcı veya başka bir şey gibi) kapatmak için bir sınıfınız olduğunu hayal edelim. Diyelim ki 3 yöntemi olmalı. Bunlara "doFirst ()", "doLast ()" ve "onClose ()" diyelim.

Bu türden herhangi bir nesnenin en azından "onClose ()" gerçekleştirmesini istediğimizi söylüyoruz, ancak diğeri isteğe bağlıdır.

Arayüzlerin "Varsayılan Yöntemleri" ni kullanarak bunu fark edebilirsiniz. Biliyorum, bu çoğu zaman bir arayüzün nedenini boşa çıkarır, ancak bir çerçeve tasarlıyorsanız, bu yararlı olabilir.

Yani bunu bu şekilde gerçekleştirmek istiyorsanız, aşağıdaki gibi görünecektir

public interface Closer {
    default void doFirst() {
        System.out.print("first ... ");
    }
    void onClose();
    default void doLast() {
        System.out.println("and finally!");
    }
}

Şimdi ne olurdu, örneğin bunu "Test" adlı bir sınıfta uygularsanız, derleyici aşağıdakiler için mükemmel bir şekilde yeterli olacaktır:

public class TestCloser implements Closer {
    @Override
    public void onClose() {
        System.out.print("closing ... ");
    }
}

Çıktı ile:

first ... closing ... and finally!

veya

public class TestCloser implements Closer {
    @Override
    public void onClose() {
        System.out.print("closing ... ");
    }

    @Override
    public void doLast() {
        System.out.println("done!");
    }
}

çıktıyla:

first ... closing ... done!

Tüm kombinasyonlar mümkündür. "Varsayılan" olan herhangi bir şey uygulanabilir, ancak uygulanmamalıdır, ancak olmayan her şey uygulanmalıdır.

Umarım şimdi cevap vermem tamamen yanlış değildir.

Herkese iyi günler!

[edit1]: Lütfen unutmayın: Bu yalnızca Java 8'de çalışır.

Geri arama arayüzünü uygulamanın bir yolunu arıyordum, bu nedenle her geri arama için her yöntemi uygulamak istemediğim için isteğe bağlı yöntemleri uygulamak gerekliydi.

Bu yüzden, bir arayüz kullanmak yerine, aşağıdaki gibi boş uygulama içeren bir sınıf kullandım:

public class MyCallBack{
    public void didResponseCameBack(String response){}
}

Ve üye değişkeni CallBack'i şu şekilde ayarlayabilirsiniz,

c.setCallBack(new MyCallBack() {
    public void didResponseCameBack(String response) {
        //your implementation here
    }
});

o zaman böyle çağırın.

if(mMyCallBack != null) {
    mMyCallBack.didResponseCameBack(response);
}

Bu şekilde, geri arama başına her yöntemi uygulama konusunda endişelenmenize gerek kalmaz, yalnızca ihtiyacınız olanları geçersiz kılarsınız.

OP'nin sorusuna cevap vermese de, Java 8'den itibaren arayüzlere varsayılan yöntemler eklemenin aslında mümkün olduğunu belirtmekte fayda var . defaultBir arabirimin yöntem imzası yerleştirilen anahtar kelime yöntemini geçersiz seçeneğine sahip bir sınıfta sonuçlanır ancak bunu gerektirmez.

Oracle'ın Java Koleksiyonları Eğitimi:

Çekirdek koleksiyon arabirimlerinin sayısını yönetilebilir durumda tutmak için, Java platformu her koleksiyon türünün her çeşidi için ayrı arabirimler sağlamaz. (Bu tür varyantlar değişmez, sabit boyutlu ve yalnızca eki içerebilir.) Bunun yerine, her arayüzdeki modifikasyon işlemleri isteğe bağlı olarak belirlenir - belirli bir uygulama tüm işlemleri desteklememeyi seçebilir. Desteklenmeyen bir işlem çağrılırsa, koleksiyon bir UnsupportedOperationExceptionoluşturur . Uygulamalar, destekledikleri isteğe bağlı işlemlerden hangisini belgelemekten sorumludur. Java platformunun genel amaçlı uygulamalarının tümü, isteğe bağlı tüm işlemleri destekler.