java generics overloading type-erasure

Borrado de Java con sobrecarga genérica(sin anular)



generics overloading (2)

Tengo FinanceRequests y CommisionTransactions en mi dominio. Si tengo una lista de las Solicitudes de Finanzas, cada Solicitud de Finanzas podría contener múltiples Transacciones de Comisiones que deben ser recuperadas. No te preocupes exactamente cómo se hace eso.

La siguiente clase (muy abajo) me hace sentir borrosa y cálida desde su sucesión y reutiliza el código existente muy bien. Un problema Tipo de borrado.

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

Ambos tienen la misma firma después del borrado, es decir:

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

Así que eclipse se queja de que:
El método clawBack (Colección) tiene el mismo clawBack de eliminación (Colección) que otro método en el tipo CommissionFacade

¿Alguna sugerencia para reestructurar esto para que siga siendo una solución elegante que hace que un buen código se reutilice?

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); } } }


Cambie el nombre de los métodos o utilice el polimorfismo: use una interfaz y luego coloque el código de recuperación en los propios objetos, o use el envío doble (según su paradigma de diseño y gusto).

Con código en objetos que serían:

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 } }

Prefiero este enfoque, ya que creo que su dominio debe contener su lógica; pero no estoy completamente consciente de tus deseos exactos, así que te lo dejaré a ti.

Con un envío doble, pasaría "ClawbackHandler" al método clawback, y en el controlador, llame al método apropiado dependiendo del tipo.


Creo que tu mejor opción es simplemente nombrar el método de manera diferente.

public void clawBackFinReqs(Collection<FinanceRequest> financeRequestList) { } public void clawBackComTrans(Collection<CommissionTrns> commissionTrnsList) { }

De hecho, no está tan mal, ya que no se obtiene nada extra por tener el mismo nombre en ellos.

Tenga en cuenta que la JVM no decidirá a qué método llamar en tiempo de ejecución. A diferencia de los métodos virtuales, la resolución de los métodos sobrecargados se realiza en tiempo de compilación. Los Tutoriales de Java sobre la sobrecarga de métodos incluso señalan que "los métodos sobrecargados deben usarse con moderación ..." .