Java - Arayüz uygulamasında yöntem adı çakışması

Her ikisi de amaçları açısından oldukça farklı, ancak aynı yöntem imzasına sahip iki arabirimim varsa, hem arabirime hizmet eden tek bir yöntem yazmaya hem de yöntemde bazı kıvrımlı mantık yazmaya zorlanmadan bir sınıfı nasıl uygulayabilirim? Çağrının hangi tür nesne için yapıldığını kontrol eden ve uygun kodu çağıran uygulama?

C # 'da, bu, açık arabirim uygulaması olarak adlandırılan şeyle aşılır. Java'da eşdeğer bir yol var mı?

Hayır, aynı yöntemi Java'da bir sınıfta iki farklı şekilde uygulamanın bir yolu yoktur.

Bu birçok kafa karıştırıcı duruma yol açabilir, bu yüzden Java buna izin vermedi.

interface ISomething {
    void doSomething();
}

interface ISomething2 {
    void doSomething();
}

class Impl implements ISomething, ISomething2 {
   void doSomething() {} // There can only be one implementation of this method.
}

Yapabileceğiniz şey, her biri farklı bir arabirim uygulayan iki sınıftan bir sınıf oluşturmaktır. O zaman bu sınıf, her iki arayüzün davranışına sahip olacaktır.

class CompositeClass {
    ISomething class1;
    ISomething2 class2;
    void doSomething1(){class1.doSomething();}
    void doSomething2(){class2.doSomething();}
}

Bunu Java'da çözmenin gerçek bir yolu yok. İç sınıfları geçici çözüm olarak kullanabilirsiniz:

interface Alfa { void m(); }
interface Beta { void m(); }
class AlfaBeta implements Alfa {
    private int value;
    public void m() { ++value; } // Alfa.m()
    public Beta asBeta() {
        return new Beta(){
            public void m() { --value; } // Beta.m()
        };
    }
}

Ondan atmalarını için izin vermemekle birlikte AlfaBetaiçin Beta, downcasts genellikle kötülük vardır ve bir o beklenebilir eğer Alfaörneği genellikle vardır Betasen isterler de yönünü ve nedense (genellikle optimizasyon geçerlidir nedenidir) dönüştürmek için Beta, size bir alt arayüzü yapabilir Alfaile Beta asBeta()onun içinde.

Bu sorunla karşılaşıyorsanız, bunun nedeni büyük olasılıkla temsilci kullanmanız gereken yerde kalıtımı kullanmanızdır . Aynı temel veri modeli için benzer de olsa iki farklı arabirim sağlamanız gerekiyorsa, bir görünüm kullanmalısınız sağlamanız gerekiyorsa, başka bir arabirimi kullanarak verilere ucuza erişim sağlamak kullanmalısınız.

İkinci durumda yönelik somut bir örnek vermek gerekirse, her iki uygulamak istediğinizi varsayalım Collectionve MyCollection(devralan olmadığı Collectionve uyumsuz bir arayüze sahip). Aynı temel verileri kullanan ve hafif bir uygulama sağlayan a Collection getCollectionView()ve MyCollection getMyCollectionView()işlevleri sağlayabilirsiniz .CollectionMyCollection

İlk durum için ... farz edin ki gerçekten bir tamsayı dizisi ve bir dizi dizge istiyorsunuz. Bunun yerine hem devralmak List<Integer>ve List<String>, sen bir tür üyesi olmalıdır List<Integer>ve türde başka üyesi List<String>ve hem devralır ziyade denemede daha bu üyeler bakın. Yalnızca tam sayıların bir listesine ihtiyacınız olsa bile, bu durumda miras yerine kompozisyon / yetkilendirmeyi kullanmak daha iyidir.

"Klasik" Java problemi Android geliştirmemi de etkiliyor ...
Nedeni basit görünüyor:
Daha fazla çerçeve / kitaplık kullanmanız gerek, daha kolay işler kontrolden çıkabilir ...

Benim durumumda bir BootStrapperApp sınıfım var android.app.Application'dan miras alınır ,
oysa aynı sınıf, entegre olmak için bir MVVM çerçevesinin Platform arayüzünü de uygulamalıdır . Her iki arabirim tarafından bildirilen ve farklı bağlamlarda farklı uygulamalara sahip olması gereken getString () yönteminde
yöntem çakışması meydana geldi .
Çözüm (çirkin..IMO), tüm Platformu uygulamak için bir iç sınıf kullanıyoryöntemler, sadece küçük bir yöntem imza çakışması nedeniyle ... bazı durumlarda, bu tür ödünç alınan yöntem hiç kullanılmaz (ancak büyük tasarım anlamlarını etkiler).
C # tarzı açık bağlam / ad alanı göstergesinin yardımcı olduğunu kabul ediyorum.

Aklıma gelen tek çözüm, birden fazla arayüz yerleştirmek istediğiniz nesneye yönlendirme nesneleri kullanmaktır.

Ör: uygulamak için 2 arayüzünüz olduğunu varsayalım

public interface Framework1Interface {

    void method(Object o);
}

ve

public interface Framework2Interface {
    void method(Object o);
}

bunları iki Facador nesnesine dahil edebilirsiniz:

public class Facador1 implements Framework1Interface {

    private final ObjectToUse reference;

    public static Framework1Interface Create(ObjectToUse ref) {
        return new Facador1(ref);
    }

    private Facador1(ObjectToUse refObject) {
        this.reference = refObject;
    }

    @Override
    public boolean equals(Object obj) {
        if (obj instanceof Framework1Interface) {
            return this == obj;
        } else if (obj instanceof ObjectToUse) {
            return reference == obj;
        }
        return super.equals(obj);
    }

    @Override
    public void method(Object o) {
        reference.methodForFrameWork1(o);
    }
}

ve

public class Facador2 implements Framework2Interface {

    private final ObjectToUse reference;

    public static Framework2Interface Create(ObjectToUse ref) {
        return new Facador2(ref);
    }

    private Facador2(ObjectToUse refObject) {
        this.reference = refObject;
    }

    @Override
    public boolean equals(Object obj) {
        if (obj instanceof Framework2Interface) {
            return this == obj;
        } else if (obj instanceof ObjectToUse) {
            return reference == obj;
        }
        return super.equals(obj);
    }

    @Override
    public void method(Object o) {
        reference.methodForFrameWork2(o);
    }
}

Sonunda istediğin ders şöyle olmalı

public class ObjectToUse {

    private Framework1Interface facFramework1Interface;
    private Framework2Interface facFramework2Interface;

    public ObjectToUse() {
    }

    public Framework1Interface getAsFramework1Interface() {
        if (facFramework1Interface == null) {
            facFramework1Interface = Facador1.Create(this);
        }
        return facFramework1Interface;
    }

    public Framework2Interface getAsFramework2Interface() {
        if (facFramework2Interface == null) {
            facFramework2Interface = Facador2.Create(this);
        }
        return facFramework2Interface;
    }

    public void methodForFrameWork1(Object o) {
    }

    public void methodForFrameWork2(Object o) {
    }
}

artık sınıfınızı "göstermek" için getAs * yöntemlerini kullanabilirsiniz

Bunların çalışmasını sağlamak için bir Adaptör modeli kullanabilirsiniz. Her arayüz için iki adaptör oluşturun ve bunu kullanın. Sorunu çözmeli.

Söz konusu kodun tamamı üzerinde tam kontrole sahip olduğunuzda ve bunu önceden uygulayabildiğinizde, her şey yolunda. Şimdi birçok yerde bir yöntemle kullanılan mevcut bir genel sınıfınız olduğunu hayal edin

public class MyClass{

    private String name;

    MyClass(String name){
        this.name = name;
    }

    public String getName(){
        return name;
    }
}

Şimdi bunu, sınıfların aynı zamanda bir getName () yöntemine sahip olan WBPInterface ... uygulamasını gerektiren kullanıma hazır WizzBangProcessor'a aktarmanız gerekir, ancak somut uygulamanız yerine, bu arabirim yöntemin bir türün adını döndürmesini bekler. of Wizz Bang Processing.

C # 'da bir trvial olurdu

public class MyClass : WBPInterface{

    private String name;

    String WBPInterface.getName(){
        return "MyWizzBangProcessor";
    }

    MyClass(String name){
        this.name = name;
    }

    public String getName(){
        return name;
    }
}

Java Tough'da, bir arabirimden diğerine dönüştürmeniz gereken mevcut konuşlandırılmış kod tabanındaki her noktayı tanımlamanız gerekecek. Elbette WizzBangProcessor şirketi getWizzBangProcessName () kullanmalıydı, ancak onlar da geliştiriciler. Kendi bağlamında getName iyiydi. Aslında, Java dışında, diğer OO tabanlı dillerin çoğu bunu destekler. Java, tüm arabirimleri aynı NAME yöntemiyle uygulanmaya zorlamada nadirdir.

Diğer dillerin çoğunda, "bu uygulanan arayüzde bu yöntemin imzasıyla eşleşen bu sınıftaki bu yöntem, uygulanmasıdır" diyen bir talimat almaktan çok mutlu olan bir derleyiciye sahiptir. Sonuçta, arayüzleri tanımlamanın tüm amacı, tanımın uygulamadan soyutlanmasına izin vermektir. (Beni Java Arayüzlerinde varsayılan yöntemlere sahip olmaya bile başlatmayın, varsayılanı geçersiz kılmayı bırakın ... çünkü tabii ki, bir yol arabası için tasarlanan her bileşen uçan bir arabaya çarpıp sadece çalışabilmelidir - hey ikisi de araba ... eminim ki, uydu navigasyonunuzun varsayılan işlevselliği, varsayılan perde ve yuvarlanma girişlerinden etkilenmeyecektir, çünkü arabalar sadece yalpalama!