Interfaces Aren’t Overkill — They’re Future-Proofing Your Code Early in my Flutter journey, I tho...Interfaces Aren’t Overkill — They’re Future-Proofing Your Code Early in my Flutter journey, I tho...
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Ajah's avatar
Ajah Emmanuel
• Aug 12
Interfaces Aren’t Overkill — They’re Future-Proofing Your Code
Early in my Flutter journey, I thought interfaces were just unnecessary ceremony.
“Why create an abstract class when I can just write a service class for API calls and use it directly?” I asked.
Well, I worked under senior devs then, and I followed their guidance, hoping to understand “why” one day. When I started owning/overseeing projects, the "why" became vidvid to me.
In this project, I was using flutter_secure_storage for auth tokens and some simple user data. Everything worked perfectly.
Then the client said: “We need parts of the app to work offline.”
I needed a local database — Hive. Fortunately, I already had a local storage interface. All I had to do was:
Create HiveLocalStorageServiceImpl implementing the interface, "default" it as a dependency in the offline-specific cubits
Zero breaking changes, zero headaches, everything just worked.
I use to understand interfaces like hosting an event with a strict dress code:
Black shoes ✅
White wristwatch ✅
Green face cap ✅
Every guest must follow the rules (the interface), but each guest can choose their own style:
Guest A: Oxford shoes, Rolex, silk cap
Guest B: Nike sneakers, Casio watch, baseball cap
Guest C: Crocs, Apple Watch, vintage cap
All follow the contract, all do their own thing.
In code, it is the same: one view-model uses FlutterSecureStorage for tokens, another uses Hive for offline meter readings. The interface guarantees the contract; the implementation decides the style.
Why this matters:
✅ Flexibility => Swap Hive, Isar, or any storage without touching dependent code
✅ Testing => Mock any implementation and inject it wherever needed
✅ Clarity => The contract is explicit, separate from the implementation
✅ Future-proofing => Requirements change, implementations change, interface stays stable
Interfaces aren’t about being fancy. They are dress codes for your code, saving you headaches as projects grow and external services get involved.
They say: “I don’t care how you do it, but you MUST do these things.”
And yeah, If your app touches the outside world —network calls, local database, sensors, etc, you should hide it behind an interface.
Back to feed
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started