2012-03-09 8 views
6

EDITAR: Voy a dejar esto aquí como un ejemplo. Lea los comentarios para obtener más información, pero en general: ¡NO USE ESTE DISEÑO! ¡Es malo!Java - Anulación de tipo de objeto Parámetro con tipo de hormigón

busqué una respuesta desde hace un tiempo, pero no hemos podido encontrar nada dicho muy específica, no se puede porque ... o sí se puede así es como lo haces ..

Así que la pregunta es, ¿Puedo crear un método abstracto que define los parámetros de tipo de objeto y luego tener algo ponerlo en práctica con un tipo concreto de parámetro de la siguiente manera:

public abstract class ToBeOverriden { 
    public Object method1 (Object parameter); 
    public String method2 (Object parameter); 
    public void method3 (Object parameter); 
} 

y luego anularlo con esto:

public class Implementation { 
    @Override 
    public DateTime method1 (Person parameter){ 
     return new DateTime(); 
    } 

    @Override 
    public String method2 (MotorCycle parameter){ 
     return new DateTime(); 
    } 

    @Override 
    public void method3 (String parameter){ 
     return new DateTime(); 
    } 
} 

Donde Persona es un objeto creado por mí. El tipo de devolución puede ser lo que sea. Actualmente no puedo hacer esto. No me deja. Creo que esto se debe a que mi clase no extiende Object. Aunque todo se extiende Objeto ... Entonces ...

¿O debo actualizar mi conocimiento de Java? :)

EDITAR: Agregó una estructura de clase más compleja.

Gracias!

Respuesta

15

Usted tendría que utilizar Java Generics:

public abstract class ToBeOverriden<E,V> { 
    public E method (V parameter); 
} 

public class Implementation extends ToBeOverriden<DateTime,Person> { 
    @Override 
    public DateTime method (Person parameter){ 
     return new DateTime(); 
    } 
} 

Agregado:

E parámetro se puede omitir recayendo el código todavía se compilará. Sin embargo, si las diferentes implementaciones del ToBeOverriden usarán diferentes tipos de devolución, creo que es mejor retener E. Pero eso es una cuestión de gusto personal: no me gusta ver Object en ningún lugar del código.

Agregado 2:

Como acerca de su actualización en la pregunta, lo que tendría que tener un tipo genérico separado para cada método. Por ejemplo:

public abstract class ToBeOverriden<A,B,C> { 
    public Object method1 (A parameter); 
    public String method2 (B parameter); 
    public void method3 (C parameter); 
} 

Sin embargo, generalmente, cuando necesita una estructura tan horrible, su código está diseñado de manera incorrecta. En el 95% de los casos, 1 parámetro de tipo genérico es suficiente. En 4.99% casos, 2 parámetros de tipo genérico son suficientes.

+1

El * E * no es obligatorio, solo * V * es necesario. –

+0

@AmirPashazadeh Tienes razón, no pensaste en eso. Actualizado mi respuesta. – bezmax

+0

¿Qué sucede si tiene más de un tipo de parámetro/tipo de devolución? ¿Qué será E entonces? – Hannibal

0

Haces :) The spec dice:

dos métodos tienen la misma firma si tienen el mismo nombre y el argumento tipos.

usted puede fácilmente tener public Object method (Object parameter); y public Object method (Person parameter); en su lado de la clase al lado del otro, y éstos serán diferentes métodos.

Y sí, todas las clases finalmente se extienden Object.

2

Usted puede hacer lo siguiente:

public abstract class ToBeOverriden<T> { 
    public Object method (T parameter); 
} 

public class Implementation extends ToBeOVerriden<Person>{ 
    @Override 
    public DateTime method (Person parameter){ 
     return new DateTime(); 
    } 
} 

pero no se puede hacer eso sin generification, y el problema es el argumento, no el tipo de retorno. Supongamos que puede hacer eso sin generar, entonces podría mantener una referencia a su objeto de implementación con una interfaz, y podría llamar al método con cualquier objeto como argumento, no solo una Persona (que está en contra de la seguridad de tipo de Java).

Cuestiones relacionadas