You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Why is programming to an interface not encouraged and/or enforced? #54949
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.
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.
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?
I would very much like to see changes like these being implemented sometime in the future.
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?
I don't disagree with updating many of these interfaces, but in practice we've found that trickier than you might think. For example, refactoring the resident runner was previously backed up on getting better tests written to prevent regressions. The better testing is currently backed up on swapping out the current vm_service implementation with the more testable package:vm_service.
In terms of refactoring, we're currently focused on removing the usage of Zone injected global variables: #47161 .
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
jonahwilliams commentedon Apr 16, 2020
I don't disagree with updating many of these interfaces, but in practice we've found that trickier than you might think. For example, refactoring the resident runner was previously backed up on getting better tests written to prevent regressions. The better testing is currently backed up on swapping out the current vm_service implementation with the more testable
package:vm_service.In terms of refactoring, we're currently focused on removing the usage of Zone injected global variables: #47161 .
github-actions commentedon Aug 21, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.