Evalml: Разрешить компоненты, которые не являются «конечными» дочерними элементами в иерархии классов.

Параметры:
1.) Пусть TargetImputer использует SimpleImputer.
2.) Не определяйте компонент TargetImputer, а вместо этого примените SimpleImputer к цели.
3.) Удалите _get_subclasses () в пользу статического списка компонентов. (предпочтительно)
4.) Сделайте _get_subclasses () умнее.

Следующий шаг: запланируйте обсуждение, чтобы решить, как это сделать.

Я считаю, что нам не следует ничего менять, если мы не хотим сделать наследование не базовых классов более распространенным шаблоном в нашей кодовой базе. В настоящее время мы этого не делаем, поэтому создание системы, которая позволяла бы это делать, мне кажется неважным.

Эта проблема не блокирует целевой источник или какую-либо краткосрочную работу, которая у нас впереди, и текущая система определения подклассов «работает». Если мы действительно хотим 3, то это уже другая история, хе-хе, и мне не терпится услышать аргументы в пользу этого, но я не думаю, что в этом есть необходимость.

И если мы захотим использовать SimpleImputer в TargetImputer в будущем, мы можем использовать композицию вместо наследования, о чем, я думаю, и идет речь в варианте 1.

Согласен с @freddyaboulton здесь, также стоит отметить, что мы определили _get_subclasses() в первую очередь, потому что отслеживание статического списка компонентов было немного утомительным / разочаровывающим, поскольку мы добавляли все больше и больше компонентов. Если мы выберем 3, было бы разумнее сохранить _get_subclasses() но также сохранить список «исключений», таких как случай SimpleImputer / TargetImputer, чтобы они были включены, но другие компоненты, такие как Transformer по-прежнему исключены.

Также хорошо с идеей какой-нибудь техники в стиле композиции, если это помогает.

@ angela97lin Как вы думаете, мы можем закрыть это? Я думаю, мы согласны с тем, что нам не нужно вносить изменения в _get_subclasses чтобы разрешить разработку TargetImputer / других компонентов.