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...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 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.

Ivo Ivanov

max

• Sep 17

It's been 3 years since I started UI Flip and its website was the first one I built in Framer. It was far from great and an overhaul was way overdue. I started a new version from scratch earlier this year and it has been on-hold for months, as I wanted to polish it just a little bit more, but this morning I said "f*ck it, just ship it" and hit that "publish" button 🚀

Completed work

Framer Website Development Claude Figma Framer Web Design portfolio Framer Website Design

Bearplus Fullstack Agency

• Sep 17

The Heron chat widget is the product's main touchpoint. It floats over the architect's design software, answers questions about the model, and executes changes once approved.

Designing UI that lives inside another application changes the constraints. It has to hold legibility over dense linework, keep a small footprint, stay clearly branded without competing with the host software, and dismiss cleanly.

The product page demonstrates rather than describes. The widget is shown over a real floor plan, mid-conversation about an HVAC clearance issue, with the affected room highlighted in the drawing behind it. The surrounding layout is kept deliberately quiet so the widget holds the visual weight.