A big pain point when working with, and trying to make sense of the flutter repository is that this arguably basic principle of good software engineering is oftentimes not being applied.

What do I mean by programming to an interface?

Here are three examples from the dart SDK that adhere to that principle.

VmService
AnalysisContext
ContextBuilder

These all describe pure interfaces, without any implementation details. The benefit of that is not only that changes to implementations aren't breaking changes anymore since the Interface is the only thing that consumers should depend on, but those interfaces also provide a natural place for documentation. This would also clearly separate tests into black-box tests (testing against the interface) and white-box tests (testing the implementation). Also, it should not be understated that interfaces make it a lot easier to understand a new code-base which does increase the productivity of new developers.

Now, here are a few places in the flutter repo that would benefit from this practice in the long run.

ResidentRunner
Xcode
EmulatorManager
DeviceManager
(and many more: Device, Doctor, ProtocolDiscovery)

All the benefits described above also hold true here.

A concrete example and beneficiary of that would be ColdRunner/HotRunner. They both inherit from ResidentRunner and are very hard to reason about. Splitting ResidentRunner into an interface and a helper object/mixin would be a clear improvement and facilitate long-term maintenance.

What do I expect to achieve with this issue?

1. I would very much like to see changes like these being implemented sometime in the future.
2. Not all contributors are aware of this technique. I've observed classes that started out as an interface but were then 'concretized' by some change that added an implementation detail to it. Contributors should be encouraged to prefer interfaces and concrete implementations for behavior-rich classes.

@jonahwilliams could you perhaps comment on that, do you disagree?