Skip to content

Why is programming to an interface not encouraged and/or enforced? #54949

Closed

Description

@modulovalue

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?

Activity

  1. jonahwilliams commented on Apr 16, 2020

    @jonahwilliams
    Contributor

    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 .

  2. github-actions commented on Aug 21, 2021

    @github-actions

    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.

  3. locked as resolved and limited conversation to collaborators on Aug 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    c: contributor-productivityTeam-specific productivity, code health, technical debt.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions