How do SOLID principles apply to Flutter/Dart development?
TL;DR: SOLID in Dart: S — one reason to change per class; O — extend behavior via new classes not modification; L — subclasses must be substitutable; I — small focused interfaces over large ones; D — depend on abstractions (interfaces), not concretions.
Full Answer
S — Single Responsibility
A widget should render, a Bloc should manage state, a repository should fetch data. Don't mix concerns in one class.
O — Open/Closed
Add new widget themes by subclassing or composition, not by editing the base widget. In Bloc, new state subtypes extend the sealed class.
L — Liskov Substitution
Any QuizRepository implementation should be substitutable for another. FakeRepository in tests, RealRepository in production — same contract.
I — Interface Segregation
A ReadOnlyQuestionsRepository and a WritableQuestionsRepository are better than one giant interface with 20 methods.
D — Dependency Inversion
QuizBloc depends on the QuizRepository abstract class, not QuizRepositoryImpl. The Dio/SQLite details are hidden behind the interface.
Code Examples
// Interface: swap real <-> fake without changing QuizBloc
Common Mistakes
- ✗Treating SOLID as dogma — apply where it reduces coupling, not as a checklist
- ✗Creating interfaces for every class when there's only one implementation — premature abstraction
Interview Tip
Pick one principle and show a concrete Flutter example. Dependency Inversion with repository interfaces is the most impactful in Flutter apps.