Replace target enum by classes

[AVHopp]

When discussing #54 , the idea of replacing the introduced enum was discussed. The idea was to potentially use a class-based structure. We agreed that this is an idea worth thinking about, but that it should not yet be implemented in #54 .

[AVHopp]

This is just a copy from the discussion that was held such that we also have it here and notify everyone:

@AVHopp
For me, having both an enum and the corresponding functions feels like boilerplate. Shouldn't there be a possibility for not requiring us to have both an enum here and the transform written in targets.transforms.py? This solution requires to manually keep these two different files in sync which I feel unhappy about.

@AdrianSosic
Hm, can you propose an alternative 🤔 Not sure if there is much room for reduction, but I'd be glad if you can come up with a more condensed approach.
The issues that I see (but perhaps there is a workaround):
Somewhere in the code, we must define (in one way or another) what is the mapping between modes and allowed transformations. This information simply does not come from the enum itself and requires additional specifications.
Instead of specifying the mapping from modes to transforms, I could specify it directly from modes to transform callables, getting rid of the addtional function that implements the selection logic. However, then I lose the high-level representation of these functions and run into difficulties at other places, e.g. I can no longer do value not in _VALID_TRANSFORM_MODES[self.mode] ...
Let me know if you have a concept in mind that works and gets rid of one of the components 👍🏼

@AVHopp
Wouldn't it be possible to have an abstract base class for TRANSFORMS_FUNCTIONS and then have classes for the individual functions?

@Scienfitz
I think this idea is valid, but not for this PR. The same holds for the different Objective modes, once we have more objective modes they might better be turned into classes. The target transformation classes idea is better placed in the same basket rather than here

[Scienfitz]

so my take:

• i dont see any strong reason to make that change for targets at the moment, mainly because there are not really many choices for transform functions.
• The same is true for obejcts in different mode. These might become their own classes, but its completely fine as it is at the moment and only becomes relevant once more modes are available

[Scienfitz]

closing as implemented