Golang: The Last Interface Explanation You'll Ever Need

Interfaces are common, easy and important to use in Golang. Next to interfaces, structs are also really important. I've also made a video about them, so feel free to check out this video as well: • This is your last vide...
📝 Description
This time we're tackling interfaces, a vital component of Go and a must-have in every Go developer's toolkit. We'll start off with the basics of defining and implementing interfaces and move on to more advanced topics like implicit interface implementation, the empty interface, and type assertions. We'll also explore the practical application of interfaces through a use case involving a Shape interface with an `Area()` method. This will provide a clear demonstration of methods attached to structs.
⏳ Timestamps:
00:00 - Definition of defer
00:35 - Why interfaces are important
01:42 - Practical example of interfaces
08:38 - The interface type
11:33 - Interface composition
14:29 - Errors and interfaces
17:22 - Outro
👋 Hey there!
If you are new to this channel: Hey 👋 my name is Flo and I am a professional software engineer with a passion for coding in Golang, TypeScript, JavaScript, and Rust. This channel is where I share that passion and dive into the exciting world of software engineering. Plus, I love using Emojis and paper-based animations (so have a look for that, if you want to find my videos).
📨 Support and Connect!
Buy me a coffee: www.buymeacoffee.com/florianw...
Become a member: / @flowoelki
Discord: / discord
Instagram: / flowydev
LinkedIn: / florian-woelki
TikTok: / florianwoelki
GitHub: github.com/FlorianWoelki
#golang #go #interface

[@donzepe]

Nice explanation my friend!

[@FloWoelki]

Thank you! Cheers!

[@user-de6ep3vz4l]

This teacher is so logical, thanks!!

[@FloWoelki]

Thank you :D

[@nanonkay5669]

The kind of thinking of interfaces being a contract is not wrong, but kinda abstract.
Think of an interface as a membership, named after whatever you decide to call your interface, in this case "Shape". For any struct/class that wants to have that membership, they have to implement the functions described in that interface, much like how you may want to meet certain criteria to have a gym membership.
So for Circle and Rectangle, they have to implement all Shape functions/methods to have a Shape membership. This is convenient because perhaps there could be a function somewhere that only takes Shape members to operate on them (calculateArea), and if Circle and Rectangle are Shape members, that function can operate on either one of them

[@FloWoelki]

That's also a nice way to see it, except that I can always have a membership of something without meeting any requirement or using the membership :D

[@sval4020]

Hey Flo, just wanted to say how much I like your teaching style. Your videos are great! Please cover more advanced Golang topics such as Go concurrency patterns and best practices. Thank you!

[@FloWoelki]

Thank you so much for the great feedback!
Go Concurrency patterns is definitely a video on my todo list :)

[@vishamr2012]

excellent..Thx a lot

[@FloWoelki]

Thank you for watching :)

[@chrisritter9344]

This was great!

[@FloWoelki]

I am glad you've liked it :)

[@falanges5301]

Thanks so much 💝 this really helped me, keep on goin

[@FloWoelki]

You're welcome 😊

[@AntonyMapfumo]

Nice explanation. Thanks. Subscribed.

[@FloWoelki]

Awesome, thank you!

[@inifitecosmos]

👌

[@nikital2608]

What is the font name?

[@FloWoelki]

I am using `monaspace` :)

[@atljBoss]

implicit implementation of interfaces is a bit weird in Go. Would prefer the rusty way!

[@FloWoelki]

I prefer the explicit interface implementation as well, because things are much clearer.

[@jordanhasgul4401]

If you want to make it clear that a struct implements a particular interface, you can do a compile time assertion.
var _ MyInterface = (*MyStruct)(nil)
So you get the explicitness while still allowing consumers to define their own interfaces for which your struct can also satisfy.
Not saying to do this, just sharing some knowledge.