Bir arabirimde neden statik yöntemler bildiremiyorum?

Konu en çok anlatıyor - statik yöntemlerin bir arabirimde bildirilememesinin nedeni nedir?

public interface ITest {
    public static String test();
}

Yukarıdaki kod bana şu hatayı veriyor (en azından Eclipse'de): "ITest.test () arabirim yöntemi için geçersiz değiştirici; yalnızca genel ve soyut izin verilir".

Burada birkaç sorun var. Birincisi, statik bir yöntemi tanımlamadan bildirme konusudur. Bu arasındaki fark

public interface Foo {
  public static int bar();
}

ve

public interface Foo {
  public static int bar() {
    ...
  }
}

Birincisi Espo'nun bahsettiği nedenlerden dolayı imkansız : hangi uygulayıcı sınıfın doğru tanım olduğunu bilmiyorsunuz.

Java olabilir ikincisi izin; ve aslında, Java 8'den başlayarak, öyle!

Bir arabirimde statik bir yönteme sahip olmamanızın nedeni, Java'nın statik başvuruları çözme biçiminde yatmaktadır. Java, statik bir yöntem yürütmeye çalışırken bir sınıf örneği aramaya zahmet etmez. Bunun nedeni, statik yöntemlerin örneğe bağımlı olmaması ve dolayısıyla doğrudan sınıf dosyasından yürütülebilmesidir. Bir arabirimdeki tüm yöntemlerin soyut olduğu göz önüne alındığında, VM'nin çalıştırılabilmesi için statik yöntemin arkasındaki kodu bulmak için arabirimin belirli bir uygulamasını araması gerekir. Bu daha sonra statik yöntem çözümlemesinin nasıl çalıştığı ile çelişir ve dile tutarsızlık getirir.

Sorunuzu bir örnekle cevaplayacağım. Varsayalım, statik yöntem eklenmiş bir Math sınıfımız vardı. Bu yöntemi şöyle adlandırırsınız:

Math.add(2, 3);

Math, sınıf yerine bir arabirim olsaydı, tanımlanmış bir işlevi olamazdı. Bu nedenle, Math.add (2, 3) gibi bir şey söylemek mantıklı değil.

Nedeni tasarım ilkesinde yatmaktadır, java çoklu kalıtıma izin vermez. Birden fazla miras sorunu aşağıdaki örnekle gösterilebilir:

public class A {
   public method x() {...}
}
public class B {
   public method x() {...}
}
public class C extends A, B { ... }

Şimdi Cx () çağırırsanız ne olur? Ax () veya Bx () yürütülecek mi? Birden fazla mirasa sahip her dil bu sorunu çözmek zorundadır.

Arabirimler Java'da bir çeşit kısıtlı çoklu kalıtım sağlar. Yukarıdaki problemden kaçınmak için yöntemlerine izin verilmez. Arayüzler ve statik yöntemlerle aynı soruna bakarsak:

public interface A {
   public static method x() {...}
}
public interface B {
   public static method x() {...}
}
public class C implements A, B { ... }

Aynı sorun burada, Cx () çağırırsanız ne olur?

Statik yöntemler örnek yöntemler değildir. Örnek bir bağlam yoktur, bu yüzden onu arayüzden uygulamak çok az mantıklıdır.

Artık Java8, Arayüzdeki Statik Yöntemleri bile tanımlamamıza izin veriyor.

interface X {
    static void foo() {
       System.out.println("foo");
    }
}

class Y implements X {
    //...
}

public class Z {
   public static void main(String[] args) {
      X.foo();
      // Y.foo(); // won't compile because foo() is a Static Method of X and not Y
   }
}

Not: Varsayılan / statik anahtar kelimelerini varsayılan yöntemler ve Statik yöntemler için yapmak için açıkça kullanmazsak, Arayüzdeki yöntemler varsayılan olarak yine de genel olarak özetlenir.

Burada sorunuzun çok hoş ve özlü bir cevabı var . (Bunu açıklamak için bu kadar basit ve açık bir yol olarak beni etkiledi.)

Görünüşe göre arayüzdeki statik yöntem Java 8'de desteklenebilir , benim çözümüm sadece iç sınıfta tanımlamak.

interface Foo {
    // ...
    class fn {
        public static void func1(...) {
            // ...
        }
    }
}

Aynı teknik ek açıklamalarda da kullanılabilir:

public @interface Foo {
    String value();

    class fn {
        public static String getValue(Object obj) {
            Foo foo = obj.getClass().getAnnotation(Foo.class);
            return foo == null ? null : foo.value();
        }
    }
}

İç sınıfa her zaman Interface.fn...yerine şeklinde erişilmelidir Class.fn..., o zaman belirsiz problemden kurtulabilirsiniz.

Arabirim, türler için değil, Nesneler için geçerli olan polimorfizm için kullanılır. Bu nedenle (daha önce belirtildiği gibi), statik bir arabirim üyesine sahip olmak mantıklı değildir.

Java 8 Dünyayı değiştirmişti, arayüzde statik yöntemlere sahip olabilirsiniz, ancak sizi bunun için uygulama sağlamaya zorlar.

public interface StaticMethodInterface {
public static int testStaticMethod() {
    return 0;
}

/**
 * Illegal combination of modifiers for the interface method
 * testStaticMethod; only one of abstract, default, or static permitted
 * 
 * @param i
 * @return
 */
// public static abstract int testStaticMethod(float i);

default int testNonStaticMethod() {
    return 1;
}

/**
 * Without implementation.
 * 
 * @param i
 * @return
 */
int testNonStaticMethod(float i);

}

Değiştiricilerin geçersiz kombinasyonu: statik ve soyut

Bir sınıfın üyesi statik olarak bildirilirse, nesne oluşturmadan o sınıfla sınırlanmış sınıf adıyla kullanılabilir.

Bir sınıfın üyesi soyut olarak bildirilirse, sınıfı soyut olarak bildirmeniz ve soyut üyenin miras alınan sınıfta (Alt Sınıf) uygulanmasını sağlamanız gerekir.

Alt sınıftaki bir sınıfın soyut üyesine statik yöntem davranışını değiştireceğiniz bir uygulama sağlamanız gerekir; bu da temel sınıfla sınırlı olan ve doğru olmayan soyut olarak bildirilir.

Statik yöntemler miras alınamadığı için. Yani arayüze yerleştirmenin bir yararı yok. Arayüz temel olarak tüm abonelerinin takip etmesi gereken bir sözleşmedir. Arabirime statik bir yöntem yerleştirmek, aboneleri bunu uygulamaya zorlayacaktır. şimdi statik yöntemlerin kalıtsal olamayacağı gerçeğiyle çelişiyor.

İle Java 8 , arabirimler artık statik yöntemlere sahip olabilir.

Örneğin, Karşılaştırıcı'nın statik bir naturalOrder () yöntemi vardır.

Arayüzlerin uygulamalara sahip olmaması şartı da ortadan kaldırılmıştır. Arabirimler artık bir istisna dışında normal uygulamalar gibi "varsayılan" yöntem uygulamalarını bildirebilir: hem bir arabirimden hem varsayılan bir uygulamayı hem de bir üst sınıftan normal bir uygulamayı devralıyorsanız, üst sınıfın uygulaması her zaman öncelik kazanacaktır.

Belki bir kod örneği yardımcı olur, ben C # kullanacağım, ama birlikte takip edebilmelidir.

IPayable adında bir arayüzümüz olduğunu varsayalım

public interface IPayable
{
    public Pay(double amount);
}

Şimdi, bu arayüzü uygulayan iki somut sınıfımız var:

public class BusinessAccount : IPayable
{
    public void Pay(double amount)
    {
        //Logic
    }
}

public class CustomerAccount : IPayable
{
    public void Pay(double amount)
    {
        //Logic
    }
}

Şimdi, çeşitli hesaplardan oluşan bir koleksiyonumuz olduğunu varsayalım, bunu yapmak için IPayable türünün genel bir listesini kullanacağız

List<IPayable> accountsToPay = new List<IPayable>();
accountsToPay.add(new CustomerAccount());
accountsToPay.add(new BusinessAccount());

Şimdi, tüm bu hesaplara 50,00 $ ödemek istiyoruz:

foreach (IPayable account in accountsToPay)
{
    account.Pay(50.00);
}

Şimdi arayüzlerin inanılmaz derecede faydalı olduğunu görüyorsunuz.

Yalnızca somut nesnelerde kullanılırlar. Statik sınıflarda değil.

Statik ödeme yaptıysanız, IPayable'ın hesaplar arasında dolaşırkenToPay, BusinessAcount veya CustomerAccount'ta ödeme çağırıp çağırmayacağını anlamanın bir yolu olmazdı.