Evalml: Permitir componentes que no sean elementos secundarios "hoja" en la jerarquía de clases.

Opciones:
1.) Haga que TargetImputer utilice SimpleImputer.
2.) No defina el componente TargetImputer, sino que aplique SimpleImputer al objetivo.
3.) Eliminar _get_subclasses () a favor de la lista estática de componentes. (privilegiado)
4.) Haga que _get_subclasses () sea más inteligente.

Siguiente paso: programe una discusión para decidir cómo hacer esto.

Mi opinión es que no deberíamos cambiar nada a menos que queramos que la herencia de clases no base sea un patrón más común en nuestro código base. Actualmente no hacemos eso, por lo que la construcción de un sistema que permita eso me parece de baja prioridad.

Este problema no está bloqueando el imputador de destino o cualquier trabajo a corto plazo que tengamos por delante y el sistema actual para identificar subclases "funciona". Si realmente queremos 3, entonces esa es otra historia jeje y estaría dispuesto a escuchar argumentos a favor, pero no creo que sea necesario hacerlo.

Y si quisiéramos aprovechar SimpleImputer en TargetImputer en el futuro, podemos usar la composición sobre la herencia, que creo que es a lo que se refiere la opción 1.

De acuerdo con @freddyaboulton aquí, también vale la pena señalar que definimos _get_subclasses() en primer lugar porque hacer un seguimiento de una lista estática de componentes era un poco tedioso / frustrante ya que estábamos agregando más y más componentes. Si optamos por 3, podría tener más sentido mantener _get_subclasses() pero también mantener una lista de "excepciones" como el caso SimpleImputer / TargetImputer, para que estén incluidos, pero otros componentes como Transformer todavía están excluidos.

También está de acuerdo con la idea de alguna técnica de composición si eso hace el trabajo.

@ angela97lin ¿Crees que podemos cerrar esto? Creo que estamos de acuerdo en que no necesitamos hacer cambios en _get_subclasses para permitir el desarrollo de TargetImputer / otros componentes.