More flexible construction of migrations - dependency injection

My work on extending the Migrate UI for 2.6 has revealed some basic weaknesses with how migrations are constructed. The pattern we've used to date has relied primarily on writing new classes extending the base Migration class or intermediate classes, with everything that's important to defining the migration embedded in the constructor. This makes it difficult to modify anything about a migration through the UI, everything has to be done in code. I did manage to work out some ability to override field mappings through the UI, but that implementation feels fragile and hackish to me, and there's not much else that can be done through the UI today.

Meanwhile, trying to get up-to-speed on Drupal 8, I've heard a lot about dependency injection. The Wikipedia article makes it sound harder than it is - the basic idea is, instead of hard-coding stuff in the constructor, make it more dynamic by passing stuff as arguments into the constructor or setting it on the constructed object. Moving to a dependency injection pattern for putting together migration processes would be much more flexible, and make it easier to support a rich UI.

My plan was to get Migrate 2.6 out at pretty much the current level of functionality, and then focus primarily on Migrate 3 for Drupal 8, addressing this and other architectural issues there, but it occurs to me that it may not be that hard to make significant improvements in Migrate 2 simply by adding some setters - ->setSource($source), ->setDestination($destination), etc. - it may be a fairly respectable bang for the buck. No guarantee this will make it in to Migrate 2, but I'd like to take a little time doing a POC and see how effectively this pattern can be applied.