Bir arayüz neden başka bir arayüzü uygulayamaz?


104

Demek istediğim ... dir:

interface B {...}

interface A extends B {...} // allowed  

interface A implements B {...} // not allowed

Ben googled ve buldum bu :

implementsbir arayüzün yöntemleri için bir uygulamanın tanımlanmasını belirtir. Ancak arayüzlerin uygulaması yoktur, bu yüzden bu mümkün değildir.

Bununla birlikte, arabirim% 100 soyut bir sınıftır ve soyut bir sınıf, yöntemlerini uygulamadan arabirimleri (% 100 soyut sınıf) uygulayabilir. "Arayüz" olarak tanımlanırken sorun nedir?

Detaylarda,

interface A {
    void methodA();
}

abstract class B implements A {} // we may not implement methodA() but allowed

class C extends B {
   void methodA(){}
} 

interface B implements A {} // not allowed. 
//however, interface B = %100 abstract class B

Yanıtlar:


110

implementsuygulama anlamına gelir, ne zaman interfacesadece uygulama için interfacedeğil beyan etmesi gerekir .

Bir% 100 abstract classişlevsel olarak bir eşdeğerdir, interfaceancak isterseniz uygulamaya da sahip olabilir (bu durumda% 100 kalmayacaktır abstract), dolayısıyla JVM'nin bakış açısına göre bunlar farklı şeylerdir.

Ayrıca,% 100 soyut bir sınıftaki üye değişkeni herhangi bir erişim niteleyicisine sahip olabilir, burada bir arayüzde örtük olarak bulunurlar public static final.


8
Java 8'den itibaren, Arayüzler varsayılan yöntemlere sahip olabilir ve bu bakımdan onları Soyut Sınıflara çok daha benzer hale getirir.
forresthopkinsa

4
Son cümle için teşekkürler!
Tao Zhang

24

implementsyöntemler için bir davranışın tanımlanacağı anlamına gelir abstract(soyut sınıflar hariç), uygulamayı siz tanımlarsınız.

extends bir davranışın miras alındığı anlamına gelir.

Arayüzlerle, bir arayüzün diğeriyle aynı davranışa sahip olması gerektiğini söylemek mümkündür, gerçek bir uygulama bile yoktur. Bu nedenle, onu extendsuygulamak yerine başka bir arayüze arayüz oluşturmak daha mantıklıdır .


Bir yan nota göre, bir abstractsınıf abstractyöntemleri tanımlayabilse bile (bir arayüzün mantıklı yolu), bunun yine de bir sınıf olduğunu ve yine de miras alınması (genişletilmesi) ve uygulanmaması gerektiğini unutmayın.


4

Kavramsal olarak iki "alan" sınıfı ve arabirimi vardır. Bu alanların içinde her zaman genişletiyorsunuz, yalnızca bir sınıf bir tür "sınırı geçen" bir arabirim uygular. Yani temelde arayüzler için "genişler" sınıfların davranışını yansıtır. En azından arkasındaki mantığın bu olduğunu düşünüyorum. Görünüşe göre herkes bu tür bir mantığa katılmıyor (bunu biraz kendi kendime yapıyorum) ve aslında iki farklı anahtar kelimeye sahip olmak için teknik bir neden yok.


"Y, X'i genişletir" ve mühürlenmemişse, "Y" yi genişleten başka bir "Z" türüne sahip olmak mümkündür. X bir arayüz veya bir sınıf olsun, bu doğru olacaktır. Ancak "W, X'i uygularsa", "V'nin W'yi gerçekleştirmesi" mümkün değildir. "Extends" ın "zincirleme" ve "uygulama" olabileceği gerçeği, farklı anahtar kelimelere sahip olmak için iyi bir neden gibi görünemez.
supercat

2

Ancak, arabirim% 100 soyut bir sınıftır ve soyut sınıf, yöntemlerini uygulamadan arabirimi (% 100 soyut sınıf) uygulayabilir. "Arayüz" olarak tanımlanırken sorun nedir?

Bu sadece bir kongre meselesidir. Java dilinin yazarları, bu ilişkiyi tanımlamanın en iyi yolunun "genişler" olduğuna karar verdiler, bu yüzden hepimiz bunu kullanırız.

Genel olarak, bir arayüz "% 100 soyut bir sınıf" olsa da, onlar hakkında bu şekilde düşünmüyoruz. Genellikle arayüzleri türetilecek bir sınıftan ziyade belirli anahtar yöntemleri uygulama vaadi olarak düşünürüz. Bu yüzden arayüzler için sınıflardan farklı bir dil kullanma eğilimindeyiz.

Diğerlerinin de belirttiği gibi, "genişletme" yi "uygulamalar" dan seçmenin iyi nedenleri vardır.


Evet efendim. Bu bir gelenek meselesi. Pek çok insan, Sun'ın orijinal Java dili kısıtlamalarını, sadece kişisel bir bakış açısıyla, mantıksal olarak gerekçelendirmeye çalışır . Derleyici "uygular" arayüzleri eklemiş olsaydı, sanırım aynı kişiler de bunu haklı çıkaracaktı. :-)
Little Santi

1

Umarım bu, üniversitem sırasında oops'ta (çekirdek java) öğrendiklerime biraz yardımcı olur.

Uygulamalar, bir arayüzün yöntemleri için bir uygulama tanımlamayı belirtir. Ancak arayüzlerin uygulaması yoktur, bu yüzden bu mümkün değildir. Ancak bir arabirim başka bir arabirimi genişletebilir, bu da daha fazla yöntem ekleyebileceği ve türünü devralabileceği anlamına gelir.

İşte aşağıda bir örnek, bu benim anlayışım ve oops'ta öğrendiklerim.

interface ParentInterface{  
        void myMethod();  
}  

interface SubInterface extends ParentInterface{  
        void anotherMethod();  
}  

ve bir şeyi aklınızda bulundurun bir arayüz yalnızca başka bir arayüzü genişletebilir ve eğer bir sınıfta onun işlevini tanımlamak istiyorsanız, o zaman sadece uygulanan bir arayüz, örneğin aşağıda

public interface Dog
{
    public boolean Barks();

    public boolean isGoldenRetriever();
}

Şimdi, bir sınıf bu arayüzü uygulayacak olsaydı, şöyle görünürdü:

public class SomeClass implements Dog
{
    public boolean Barks{
    // method definition here

    }

    public boolean isGoldenRetriever{
    // method definition here
    }
}

ve eğer soyut bir sınıfın tanımla ve bildirmek için soyut bir işlevi varsa ve bu işlevi tanımlamak istiyorsanız veya bu işlevi uygula diyebilirsiniz, o zaman bu sınıfı genişletmeyi varsayarsınız çünkü soyut sınıf yalnızca genişletilebilir. İşte aşağıdaki örnek.

public abstract class MyAbstractClass {

    public abstract void abstractMethod();
}

İşte MyAbstractClass'ın örnek bir alt sınıfı:

public class MySubClass extends MyAbstractClass {

    public void abstractMethod() {
        System.out.println("My method implementation");
    }
}

0

Arayüz, herhangi bir işlevsellik sağlamayan bir soyutlama gibidir. Bu nedenle, diğer soyutlamaları veya arayüzleri 'uygulamaz', ancak genişletir.


-6

Arayüz, herhangi bir nesne yaratamayan soyut bir yöntem içeren sınıftır. Arayüz nesneyi oluşturamadığından ve saf bir sınıf olmadığından, onu uygulamaya değmez.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.