¿Es “Parent x = new Child ();” en lugar de “Child x = new Child ();” una mala práctica si podemos usar el último?

Por ejemplo, había visto algunos códigos que crean un fragmento como este:

Fragment myFragment=new MyFragment();

que declara una variable como Fragment en lugar de MyFragment, que MyFragment es una clase secundaria de Fragment. No estoy satisfecho con esta línea de códigos porque creo que este código debería ser:

MyFragment myFragment=new MyFragment();

que es más específico, ¿es eso cierto?

O en generalización de la pregunta, ¿es una mala práctica usar:

Parent x=new Child();

en lugar de

Child x=new Child();

si podemos cambiar el primero en el último sin error de compilación?

Depende del contexto, pero diría que debe declarar el tipo más abstracto posible. De esa manera, su código será lo más general posible y no dependerá de detalles irrelevantes.

Un ejemplo sería tener un LinkedListy del ArrayListcual ambos descienden List. Si el código funcionaría igualmente bien con cualquier tipo de lista, entonces no hay razón para restringirlo arbitrariamente a una de las subclases.

La respuesta de JacquesB es correcta, aunque un poco abstracta. Permítanme enfatizar algunos aspectos más claramente:

En su fragmento de código, utiliza explícitamente la newpalabra clave, y tal vez le gustaría continuar con otros pasos de inicialización que probablemente sean específicos para el tipo concreto: entonces debe declarar la variable con ese tipo concreto concreto.

La situación es diferente cuando obtienes ese artículo de otro lugar, por ejemplo IFragment fragment = SomeFactory.GiveMeFragments(...);. Aquí, la fábrica normalmente debería devolver el tipo más abstracto posible, y el código descendente no debería depender de los detalles de implementación.

Hay potencialmente diferencias de rendimiento.

Si la clase derivada está sellada, el compilador puede en línea y optimizar o eliminar lo que de otro modo serían llamadas virtuales. Por lo tanto, puede haber una diferencia de rendimiento significativa.

Ejemplo: ToStringes una llamada virtual, pero Stringestá sellada. On String, ToStringes un no-op, por lo que si declara objectque es una llamada virtual, si declara un, Stringel compilador sabe que ninguna clase derivada ha anulado el método porque la clase está sellada, por lo que es un no-op. Consideraciones similares se aplican a ArrayListfrente LinkedList.

Por lo tanto, si conoce el tipo concreto del objeto (y no hay ninguna razón de encapsulación para ocultarlo), debe declararlo como ese tipo. Como acaba de crear el objeto, conoce el tipo concreto.

La diferencia clave es el nivel de acceso requerido. Y toda buena respuesta sobre la abstracción involucra animales, o eso me han dicho.

Supongamos que tiene algunos animales, Cat Birdy Dog. Ahora, estos animales tienen unos comportamientos comunes - move(), eat()y speak(). Todos comen de manera diferente y hablan de manera diferente, pero si necesito que mi animal coma o hable, realmente no me importa cómo lo hacen.

Pero a veces lo hago. Nunca he tenido un gato guardián o un pájaro guardián, pero tengo un perro guardián. Entonces, cuando alguien irrumpe en mi casa, no puedo confiar en hablar para ahuyentar al intruso. Realmente necesito que mi perro ladre, esto es diferente a su habla, lo cual es solo un engaño.

Entonces, en el código que requiere un intruso, realmente necesito hacer Dog fido = getDog(); fido.barkMenancingly();

Pero la mayoría de las veces, felizmente puedo hacer que cualquier animal haga trucos donde teje, miau o tuitee para recibir golosinas. Animal pet = getAnimal(); pet.speak();

Para ser más concreto, ArrayList tiene algunos métodos que Listno. En particular, trimToSize(). Ahora, en el 99% de los casos, no nos importa esto. El Listes lo suficientemente grande para que casi nunca nos preocupamos. Pero hay momentos en que lo es. Ocasionalmente, debemos solicitar específicamente ArrayListque se ejecute trimToSize()y que su matriz de respaldo sea más pequeña.

Tenga en cuenta que esto no tiene que hacerse en la construcción, podría hacerse a través de un método de devolución o incluso un yeso si estamos absolutamente seguros.

En general, debes usar

var x = new Child(); // C#

o

auto x = new Child(); // C++

para variables locales a menos que haya una buena razón para que la variable tenga un tipo diferente al que se inicializa.

(Aquí estoy ignorando el hecho de que el código C ++ probablemente debería estar usando un puntero inteligente. Hay casos en los que no hay y sin más de una línea que realmente no puedo conocer).

La idea general aquí es con lenguajes que admiten la detección automática de tipos de variables, su uso hace que el código sea más fácil de leer y hace lo correcto (es decir, el sistema de tipos del compilador puede optimizar lo más posible y cambiar la inicialización para que sea un nuevo el tipo funciona igual si se hubiera utilizado la mayoría de los resúmenes).

Bueno porque es fácil de entender y fácil de modificar este código:

var x = new Child(); 
x.DoSomething();

Bueno porque comunica intención:

Parent x = new Child(); 
x.DoSomething(); 

Ok, porque es común y fácil de entender:

Child x = new Child(); 
x.DoSomething(); 

La única opción que es realmente mala es usarla Parentsi solo Childtiene un método DoSomething(). Es malo porque comunica intenciones erróneamente:

Parent x = new Child(); 
(x as Child).DoSomething(); // DON'T DO THIS! IF YOU WANT x AS CHILD, STORE x AS CHILD

Ahora elaboremos un poco más sobre el caso, la pregunta específicamente se refiere a:

Parent x = new Child(); 
x.DoSomething(); 

Formateemos esto de manera diferente, haciendo que la segunda mitad sea una llamada de función:

WhichType x = new Child(); 
FunctionCall(x);

void FunctionCall(WhichType x)
    x.DoSomething(); 

Esto se puede acortar a:

FunctionCall(new Child());

void FunctionCall(WhichType x)
    x.DoSomething();

Aquí, supongo que es ampliamente aceptado que WhichTypedebería ser el tipo más básico / abstracto que permite que la función funcione (a menos que haya problemas de rendimiento). En este caso, el tipo apropiado sería Parent, o algo se Parentderiva de.

Esta línea de razonamiento explica por qué usar el tipo Parentes una buena opción, pero no entra en el clima, las otras opciones son malas (no lo son).

tl; dr : es preferible utilizarChildoverParenten el ámbito local. No solo ayuda con la legibilidad, sino que también es necesario garantizar que la resolución del método sobrecargado funcione correctamente y ayuda a permitir una compilación eficiente.

En el ámbito local,

Parent obj = new Child();  // Works
Child  obj = new Child();  // Better
var    obj = new Child();  // Best

Conceptualmente, se trata de mantener la mayor cantidad de información posible. Si bajamos a Parent, esencialmente estamos eliminando información de tipo que podría haber sido útil.

Retener la información de tipo completa tiene cuatro ventajas principales:

1. Proporciona más información al compilador.
2. Proporciona más información al lector.
3. Código más limpio y estandarizado.
4. Hace que la lógica del programa sea más mutable.

Ventaja 1: más información para el compilador

El tipo aparente se usa en la resolución de métodos sobrecargados y en la optimización.

Ejemplo: resolución de método sobrecargado

main()
{
    Parent parent = new Child();
    foo(parent);

    Child  child  = new Child();
    foo(child);
}
foo(Parent arg) { /* ... */ }  // More general
foo(Child  arg) { /* ... */ }  // Case-specific optimizations

En el ejemplo anterior, ambas foo()llamadas funcionan , pero en un caso, obtenemos la mejor resolución del método sobrecargado.

Ejemplo: optimización del compilador

main()
{
    Parent parent = new Child();
    var x = parent.Foo();

    Child  child  = new Child();
    var y = child .Foo();
}
class Parent
{
    virtual         int Foo() { return 1; }
}
class Child : Parent
{
    sealed override int Foo() { return 2; }
}

En el ejemplo anterior, ambas .Foo()llamadas finalmente llaman al mismo overridemétodo que devuelve 2. Simplemente, en el primer caso, hay una búsqueda de método virtual para encontrar el método correcto; esta búsqueda de método virtual no es necesaria en el segundo caso, ya que la de ese método sealed.

Gracias a @Ben, quien proporcionó un ejemplo similar en su respuesta .

Ventaja 2: más información para el lector

Conocer el tipo exacto, es decir Child, proporciona más información a quien lea el código, lo que facilita ver lo que está haciendo el programa.

Claro, tal vez no importa que el código real, ya que ambos parent.Foo();, y child.Foo();tiene sentido, pero para alguien ver el código por primera vez, más información es simplemente útil.

Además, dependiendo de su entorno de desarrollo, el IDE puede ser capaz de proporcionar información sobre herramientas más útiles y metadatos acerca Childde Parent.

Ventaja 3: código más limpio y estandarizado

La mayoría de los ejemplos de código C # que he visto últimamente usan var, que es básicamente una forma abreviada de Child.

Parent obj = new Child();  // Sub-optimal
Child  obj = new Child();  // Optimal, but anti-pattern syntax
var    obj = new Child();  // Optimal, clean, patterned syntax "everyone" uses now

Ver una vardeclaración de no declaración simplemente se ve mal; si hay una razón situacional para ello, increíble, pero de lo contrario parece antipatrón.

// Clean:
var foo1 = new Person();
var foo2 = new Job();
var foo3 = new Residence();

// Staggered:
Person foo1 = new Person();
Job foo2 = new Job();
Residence foo3 = new Residence();   

Ventaja 4: lógica de programa más mutable para la creación de prototipos

Las tres primeras ventajas fueron las grandes; este es mucho más situacional.

Aún así, para las personas que usan código como otros usan Excel, estamos cambiando constantemente nuestro código. Tal vez no es necesario llamar a un método único para Childen esta versión del código, pero que podríamos reutilizar o reelaborar el código más tarde.

La ventaja de un sistema de tipo fuerte es que nos proporciona ciertos metadatos sobre la lógica de nuestro programa, lo que hace que las posibilidades sean más evidentes. Esto es increíblemente útil en la creación de prototipos, por lo que es mejor mantenerlo donde sea posible.

Resumen

El uso Parentdesordenado de la resolución del método sobrecargado, inhibe algunas optimizaciones del compilador, elimina la información del lector y hace que el código sea más feo.

Usar vares realmente el camino a seguir. Es rápido, limpio, está diseñado y ayuda al compilador y al IDE a hacer su trabajo correctamente.

Importante : Esta respuesta es sobreParentvs.Childen el ámbito local de un método. El problema deParentvs.Childes muy diferente para los tipos de retorno, argumentos y campos de clase.

Dado parentType foo = new childType1();, el código se limitará al uso de métodos de tipo primario foo, pero podrá almacenarse en foouna referencia a cualquier objeto cuyo tipo se derive de, no parentsolo instancias de childType1. Si la nueva childType1instancia es lo único a lo fooque alguna vez tendrá una referencia, entonces puede ser mejor declarar fooel tipo como childType1. Por otro lado, si es fooposible que necesite contener referencias a otros tipos, tenerlo declarado como parentTypelo hará posible.

Sugiero usar

Child x = new Child();

en lugar de

Parent x = new Child();

Este último pierde información mientras que el primero no.

Puedes hacer todo con el primero que puedes hacer con el segundo pero no al revés.

Para elaborar más el puntero, tengamos múltiples niveles de herencia.

Base-> DerivedL1->DerivedL2

Y desea inicializar el resultado de new DerivedL2()una variable. Usar un tipo base te deja la opción de usar Baseo DerivedL1.

Puedes usar

Base x = new DerivedL2();

o

DerivedL1 x = new DerivedL2();

No veo ninguna forma lógica de preferir uno sobre el otro.

Si utiliza

DerivedL2 x = new DerivedL2();

No hay nada que discutir.

Sugeriría siempre devolver o almacenar variables como el tipo más específico, pero aceptando parámetros como los tipos más amplios.

P.ej

<K, V> LinkedHashMap<K, V> keyValuePairsToMap(List<K> keys, List<V> values) {
   //...
}

Los parámetros son List<T>, un tipo muy general. ArrayList<T>, LinkedList<T>y otros podrían ser aceptados por este método.

Es importante destacar que el tipo de retorno es LinkedHashMap<K, V> , no Map<K, V>. Si alguien quiere asignar el resultado de este método a a Map<K, V>, puede hacerlo. Comunica claramente que este resultado es más que un simple mapa, sino un mapa con un orden definido.

Supongamos que este método devuelto Map<K, V>. Si la persona que llama quería un LinkedHashMap<K, V>, tendrían que hacer una verificación de tipo, conversión y manejo de errores, lo cual es realmente engorroso.