Java-erasure bei generischen überlastung (nicht überschreiben)

Habe ich FinanceRequests und CommisionTransactions in meiner Domäne.
Wenn ich eine Liste von FinanceRequests jeder FinanceRequest konnte, enthalten mehrere CommisionTransactions werden müssen zurückgefordert werden. Dont worry, wie genau das geschehen ist.

Die Klasse unten (ganz unten), macht mich das Gefühl, alles verschwommen und warm, da seine succint und verwendet vorhandenen code hübsch. Ein problem Type erasure.

public void clawBack(Collection<FinanceRequest> financeRequestList)  
public void clawBack(Collection<CommissionTrns> commissionTrnsList)

Beide haben die gleiche Signatur, die nach dem löschen, ie:

Collection<FinanceRequest> --> Collection<Object>  
Collection<CommissionTrns> --> Collection<Object>

Also eclipse complainst, dass:
Methode Rückforderung(Sammlung) hat die gleiche erasure Rückforderung(Sammlung) als eine weitere Methode in der Art CommissionFacade

Anregungen zu restrukturieren, so dass es noch eine elegante Lösung, macht guten code reuse?

public class CommissionFacade
{
    /********FINANCE REQUESTS****************/
    public void clawBack(FinanceRequest financeRequest)
    {
        Collection<CommissionTrns> commTrnsList = financeRequest.getCommissionTrnsList();           
        this.clawBack(commTrnsList);
    }

    public void clawBack(Collection<FinanceRequest> financeRequestList)
    {
        for(FinanceRequest finReq : financeRequestList) 
        {
            this.clawBack(finReq);
        }           
    }

    /********COMMISSION TRANSACTIOS****************/
    public void clawBack(CommissionTrns commissionTrns)
    {
        //Do clawback for single CommissionTrns         
    }

    public void clawBack(Collection<CommissionTrns> commissionTrnsList)
    {
        for(CommissionTrns commTrn : commissionTrnsList) 
        {
            this.clawBack(commTrn);
        }
    }

}

InformationsquelleAutor n4rzul | 2011-08-26

13

Benennen Sie entweder die Methoden oder die Verwendung Polymorphismus: eine Schnittstelle, und dann entweder die Rückforderung code in die Objekte selbst, oder verwenden Sie doppelte-Versand (je nach Ihrem design-Paradigma und Geschmack).

Code in Objekten, die wäre:
```
public interface Clawbackable{
    void clawBack()
}


public class CommissionFacade
{

    public <T extends Clawbackable> void clawBack(Collection<T> objects)
    {
        for(T object: objects) 
        {
            object.clawBack();
        }           
    }
}

public class CommissionTrns implements Clawbackable {

    public void clawback(){
       //do clawback for commissions
    }
}

public class FinanceRequest implements Clawbackable {

    public void clawBack(){
      //do clwaback for FinanceRequest
    }

}
```
Ich bevorzuge diesen Ansatz, da bin ich der überzeugung Ihrer domain enthalten sollte, Ihre Logik; aber ich bin mir nicht bewusst, Ihre genauen Wünsche, so lasse ich es bis zu Ihnen.

Mit einem double dispatch, würde man die "ClawbackHandler" auf die Rückforderung Methode und der handler rufen Sie die entsprechende Methode je nach Typ.

Ich mag diese approace zu und erklären sich einverstanden, dass die Logik sollte in der Domäne. Mein Beispiel fühlt sich einfach zu sehr wie ein Helfer oder utils-Klasse, würde ich vorzuziehen vermeiden.
Dank Joeri, ist dies eine elegante Lösung.

InformationsquelleAutor Joeri Hendrickx
4

Ich denke, dass Ihre beste Möglichkeit ist einfach den Namen der Methode anders.
```
public void clawBackFinReqs(Collection<FinanceRequest> financeRequestList) {

}

public void clawBackComTrans(Collection<CommissionTrns> commissionTrnsList) {

}
```
In der Tat, es ist nicht allzu schlimm, da Sie nicht nichts extra, dass die gleichen Namen auf.

Beachten Sie, dass die JVM wird nicht entscheiden, welche Methode zum Aufruf zur Laufzeit. Im Gegensatz zu virtuellen Methoden /Verfahren überschreiben Auflösung von überladenen Methoden fertig sind zur compile-Zeit. Die Java-Tutorials auf die Methode überladen selbst weist darauf hin, dass "Überladenen Methoden sollten nur sparsam verwendet werden...".

Geben Sie diese Lösung, als ob es war eine Art Kompromiss, aber ich denke, es ist unerlässlich, dass die Methoden umbenannt werden. Eigentlich die überladenen Methoden, mit dem einzigen argument muss ebenfalls umbenannt werden. Der code ist sehr unklar, jetzt mit denen von überladenen Methoden.
Ich Stimme mit dem, was Sie sagen.
Sorge um einen Kommentar zu hinterlassen?
Ist diese Antwort nicht ganz zufriedenstellend IMHO, vor allem der Hinweis auf Java-Tutorials, die besagt, dass eine Überlastung macht den code weniger lesbar ist, ist sehr subjektiv. Das problem ist, dass oft die Umsetzung Schnittstelle ist freigegeben. Nehmen Sie zum Beispiel eine einfache Benutzeroberfläche: MyType bieten(Klasse<MyType> Typ) Typ fungiert als Diskriminator. Wenn Sie nicht die Möglichkeit haben, zu diskriminieren "allgemein" geben, sind wir gezwungen, zu benennen, aber unabhängige Schnittstellen können unterschiedliche Namen für den gleichen Zweck, die Belastungen der Implementierung unnötig.
Ein Beispiel HIERFÜR ist die Verwendung von boost::mpl::identity<T> in c++ zu unterscheiden, basierend auf der Art, die Vereinfachung der Wahl der Funktionsnamen und ermöglicht gemeinsame Umsetzung.

InformationsquelleAutor aioobe

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.