These two ideas are closely related. The easiest mental model is:<\/p>\n\n\n\n
\nInterface = a list of behaviors.<\/strong>
Implicit implementation = Go automatically accepts any type that has those behaviors.<\/strong><\/p>\n<\/blockquote>\n\n\n\nYou never write
implements<\/code> in Go.<\/p>\n\n\n\n
\n\n\n\n1. Interfaces<\/h1>\n\n\n\n
What is an interface?<\/h2>\n\n\n\n
An interface<\/strong> describes what something can do<\/strong>, without saying how it does it<\/strong>.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
type Speaker interface {\n Speak() string\n}<\/code><\/pre>\n\n\n\nThis means:<\/p>\n\n\n\n
\nAnything that has a method
Speak() string<\/code> can be treated as aSpeaker<\/code>.<\/p>\n<\/blockquote>\n\n\n\nThe interface does not<\/strong> contain the implementation.<\/p>\n\n\n\n
\n\n\n\nWhy use interfaces?<\/h2>\n\n\n\n
Interfaces help you write code that works with different types<\/strong> without caring about their exact type.<\/p>\n\n\n\n
Imagine:<\/p>\n\n\n\n
\n
- Dog can speak<\/li>\n\n\n\n
- Person can speak<\/li>\n\n\n\n
- Robot can speak<\/li>\n<\/ul>\n\n\n\n
Your program doesn’t necessarily need to know whether something is a Dog, Person, or Robot.<\/p>\n\n\n\n
It only needs to know:<\/p>\n\n\n\n
\n“Can this thing
Speak()<\/code>?”<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nComplete Example \u2014 Interface<\/h2>\n\n\n\n
Copy and run:<\/p>\n\n\n\n
package main\n\nimport \"fmt\"\n\n\/\/ Speaker describes a behavior.\n\/\/\n\/\/ Any type that has:\n\/\/ Speak() string\n\/\/\n\/\/ can be used as a Speaker.\ntype Speaker interface {\n\tSpeak() string\n}\n\n\/\/ Dog is a normal struct.\ntype Dog struct {\n\tName string\n}\n\n\/\/ Dog has the Speak method.\nfunc (d Dog) Speak() string {\n\treturn d.Name + \" says Woof!\"\n}\n\n\/\/ Person is another normal struct.\ntype Person struct {\n\tName string\n}\n\n\/\/ Person also has the Speak method.\nfunc (p Person) Speak() string {\n\treturn p.Name + \" says Hello!\"\n}\n\n\/\/ This function does NOT care\n\/\/ whether it receives Dog, Person, etc.\n\/\/\n\/\/ It only requires something\n\/\/ that satisfies the Speaker interface.\nfunc makeItSpeak(s Speaker) {\n\tfmt.Println(s.Speak())\n}\n\nfunc main() {\n\tdog := Dog{Name: \"Buddy\"}\n\tperson := Person{Name: \"John\"}\n\n\tmakeItSpeak(dog)\n\tmakeItSpeak(person)\n}<\/code><\/pre>\n\n\n\nOutput:<\/p>\n\n\n\n
Buddy says Woof!\nJohn says Hello!<\/code><\/pre>\n\n\n\n
\n\n\n\nUnderstand the important part<\/h2>\n\n\n\n
Look at this:<\/p>\n\n\n\n
type Speaker interface {\n\tSpeak() string\n}<\/code><\/pre>\n\n\n\nThe interface says:<\/p>\n\n\n\n
I need something with Speak() string<\/code><\/pre>\n\n\n\nThen:<\/p>\n\n\n\n
func (d Dog) Speak() string<\/code><\/pre>\n\n\n\nDog has that method.<\/p>\n\n\n\n
And:<\/p>\n\n\n\n
func (p Person) Speak() string<\/code><\/pre>\n\n\n\nPerson also has that method.<\/p>\n\n\n\n
Therefore both can be passed here:<\/p>\n\n\n\n
func makeItSpeak(s Speaker)<\/code><\/pre>\n\n\n\n
\n\n\n\nWhat happened?<\/h2>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
flowchart TD\n A[\"Speaker interface\"] --> B[\"Requires: Speak() string\"]\n C[\"Dog\"] --> D[\"Has Speak() string\"]\n E[\"Person\"] --> F[\"Has Speak() string\"]\n D --> G[\"Can be used as Speaker\"]\n F --> G<\/code><\/pre>\n\n\n\n
\n\n\n\nWhy is this useful?<\/h2>\n\n\n\n
Without the interface, you might write:<\/p>\n\n\n\n
func makeDogSpeak(d Dog) {\n\tfmt.Println(d.Speak())\n}\n\nfunc makePersonSpeak(p Person) {\n\tfmt.Println(p.Speak())\n}<\/code><\/pre>\n\n\n\nWith an interface:<\/p>\n\n\n\n
func makeItSpeak(s Speaker) {\n\tfmt.Println(s.Speak())\n}<\/code><\/pre>\n\n\n\nOne function works with many different types.<\/p>\n\n\n\n
\n\n\n\nWhen should I use an interface?<\/h2>\n\n\n\n
Use an interface when several types should be usable through the same behavior<\/strong>.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Writer\n Write()\n\nReader\n Read()\n\nNotifier\n Notify()\n\nPaymentProcessor\n Pay()\n\nStorage\n Save()\n\nSpeaker\n Speak()<\/code><\/pre>\n\n\n\nThink:<\/p>\n\n\n\n
\n“I don’t care exactly WHAT you are. I care about WHAT YOU CAN DO.”<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nWhere are interfaces commonly used?<\/h2>\n\n\n\n
You’ll see them in:<\/p>\n\n\n\n
\n
- function parameters<\/li>\n\n\n\n
- testing and mocks<\/li>\n\n\n\n
- database abstractions<\/li>\n\n\n\n
- HTTP code<\/li>\n\n\n\n
- file handling<\/li>\n\n\n\n
- logging<\/li>\n\n\n\n
- external services<\/li>\n\n\n\n
- application architecture<\/li>\n<\/ul>\n\n\n\n
For a beginner, the most important use is:<\/p>\n\n\n\n
func doSomething(x SomeInterface)<\/code><\/pre>\n\n\n\nIt allows different types to be passed to the same function.<\/p>\n\n\n\n
\n\n\n\n2. Implicit Interface Implementation<\/h1>\n\n\n\n
This is one of the most important differences between Go and languages such as Java.<\/p>\n\n\n\n
In Go, you do not explicitly declare that a type implements an interface<\/strong>.<\/p>\n\n\n\n
Go checks the methods automatically.<\/p>\n\n\n\n
\n\n\n\nThe key rule<\/h2>\n\n\n\n
Suppose we have:<\/p>\n\n\n\n
type Notifier interface {\n\tNotify()\n}<\/code><\/pre>\n\n\n\nAnd:<\/p>\n\n\n\n
type Email struct{}\n\nfunc (e Email) Notify() {\n\tfmt.Println(\"Sending email\")\n}<\/code><\/pre>\n\n\n\nGo automatically knows:<\/p>\n\n\n\n
Email has Notify()\n\nNotifier requires Notify()\n\nTherefore:\n\nEmail satisfies Notifier<\/code><\/pre>\n\n\n\nThere is no:<\/p>\n\n\n\n
implements Notifier<\/code><\/pre>\n\n\n\nThat is why it is called implicit interface implementation<\/strong>.<\/p>\n\n\n\n
\n\n\n\nComplete Example \u2014 Implicit Interface Implementation<\/h1>\n\n\n\n
Copy and run:<\/p>\n\n\n\n
package main\n\nimport \"fmt\"\n\n\/\/ Notifier says:\n\/\/ \"Any type with Notify() can be a Notifier.\"\ntype Notifier interface {\n\tNotify()\n}\n\n\/\/ Email is just a normal struct.\ntype Email struct {\n\tAddress string\n}\n\n\/\/ Email has the method required by Notifier.\n\/\/\n\/\/ Notice:\n\/\/ We NEVER wrote:\n\/\/ Email implements Notifier\n\/\/\n\/\/ Go figures it out automatically.\nfunc (e Email) Notify() {\n\tfmt.Println(\"Sending email to:\", e.Address)\n}\n\n\/\/ SMS is another normal struct.\ntype SMS struct {\n\tPhone string\n}\n\n\/\/ SMS also has Notify().\n\/\/\n\/\/ Therefore SMS ALSO automatically\n\/\/ satisfies the Notifier interface.\nfunc (s SMS) Notify() {\n\tfmt.Println(\"Sending SMS to:\", s.Phone)\n}\n\n\/\/ sendNotification accepts ANY type\n\/\/ that satisfies Notifier.\nfunc sendNotification(n Notifier) {\n\tn.Notify()\n}\n\nfunc main() {\n\temail := Email{\n\t\tAddress: \"john@example.com\",\n\t}\n\n\tsms := SMS{\n\t\tPhone: \"1234567890\",\n\t}\n\n\tsendNotification(email)\n\tsendNotification(sms)\n}<\/code><\/pre>\n\n\n\nOutput:<\/p>\n\n\n\n
Sending email to: john@example.com\nSending SMS to: 1234567890<\/code><\/pre>\n\n\n\n
\n\n\n\nWhat exactly makes
Email<\/code> aNotifier<\/code>?<\/h1>\n\n\n\nThe interface requires:<\/p>\n\n\n\n
type Notifier interface {\n\tNotify()\n}<\/code><\/pre>\n\n\n\nEmail has:<\/p>\n\n\n\n
func (e Email) Notify()<\/code><\/pre>\n\n\n\nSo Go says:<\/p>\n\n\n\n
Notifier requirement\n \u2193\n Notify()\n \u2191\nEmail has Notify()\n \u2193\nEmail satisfies Notifier<\/code><\/pre>\n\n\n\nNothing else is required.<\/p>\n\n\n\n
\n\n\n\nThere is no
implements<\/code><\/h1>\n\n\n\nThis is the part worth remembering.<\/p>\n\n\n\n
In some languages you might see something conceptually like:<\/p>\n\n\n\n
class Email implements Notifier<\/code><\/pre>\n\n\n\nGo does not<\/strong> work like that.<\/p>\n\n\n\n
You simply write:<\/p>\n\n\n\n
type Email struct{}<\/code><\/pre>\n\n\n\nand:<\/p>\n\n\n\n
func (e Email) Notify() {\n\tfmt.Println(\"Email sent\")\n}<\/code><\/pre>\n\n\n\nThat’s enough.<\/p>\n\n\n\n
Go notices that the method matches the interface.<\/p>\n\n\n\n
\n\n\n\nHow does Go decide?<\/h1>\n\n\n\n
Go compares the interface’s required methods with the type’s methods.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
type Notifier interface {\n\tNotify()\n}<\/code><\/pre>\n\n\n\nType A:<\/p>\n\n\n\n
type Email struct{}\n\nfunc (Email) Notify() {}<\/code><\/pre>\n\n\n\n\u2705 Implements
Notifier<\/code>.<\/p>\n\n\n\nType B:<\/p>\n\n\n\n
type SMS struct{}\n\nfunc (SMS) Notify() {}<\/code><\/pre>\n\n\n\n\u2705 Implements
Notifier<\/code>.<\/p>\n\n\n\nType C:<\/p>\n\n\n\n
type Car struct{}\n\nfunc (Car) Drive() {}<\/code><\/pre>\n\n\n\n\u274c Does NOT implement
Notifier<\/code>.<\/p>\n\n\n\nWhy?<\/p>\n\n\n\n
Because
Car<\/code> has:<\/p>\n\n\n\nDrive()<\/code><\/pre>\n\n\n\nbut the interface requires:<\/p>\n\n\n\n
Notify()<\/code><\/pre>\n\n\n\n
\n\n\n\nWhat if an interface has multiple methods?<\/h1>\n\n\n\n
Then the type must have all<\/strong> of them.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
type Device interface {\n\tStart()\n\tStop()\n}<\/code><\/pre>\n\n\n\nThis satisfies it:<\/p>\n\n\n\n
type Computer struct{}\n\nfunc (Computer) Start() {}\nfunc (Computer) Stop() {}<\/code><\/pre>\n\n\n\nBut this does not:<\/p>\n\n\n\n
type Computer struct{}\n\nfunc (Computer) Start() {}<\/code><\/pre>\n\n\n\nbecause:<\/p>\n\n\n\n
Start() \u2705\nStop() \u274c<\/code><\/pre>\n\n\n\nAll required methods must exist.<\/p>\n\n\n\n
\n\n\n\nInterfaces vs Implicit Implementation<\/h1>\n\n\n\n
Concept<\/th> Interface<\/th> Implicit Implementation<\/th><\/tr><\/thead> What is it?<\/td> Defines required behaviors<\/td> Determines whether a type satisfies an interface<\/td><\/tr> Example<\/td> type Speaker interface { Speak() }<\/code><\/td>Dog<\/code> hasSpeak()<\/code>, so Dog satisfies Speaker<\/td><\/tr>Contains data?<\/td> No<\/td> Not applicable<\/td><\/tr> Contains required methods?<\/td> Yes<\/td> Type must provide those methods<\/td><\/tr> Need implements<\/code> keyword?<\/td>No<\/td> No<\/td><\/tr> Checked by Go?<\/td> Yes<\/td> Yes<\/td><\/tr> Main purpose<\/td> Define behavior<\/td> Connect types to interfaces automatically<\/td><\/tr> Think of it as<\/td> “What must you do?”<\/td> “You can already do it, so you qualify.”<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\nInterface vs Struct<\/h1>\n\n\n\n
This distinction is also important.<\/p>\n\n\n\n
Struct<\/th> Interface<\/th><\/tr><\/thead> Describes data<\/td> Describes behavior<\/td><\/tr> Contains fields<\/td> Contains method requirements<\/td><\/tr> Name string<\/code><\/td>Speak() string<\/code><\/td><\/tr>Represents what something is<\/strong><\/td> Represents what something can do<\/strong><\/td><\/tr> Usually creates concrete values<\/td> Usually used to accept multiple types<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Example struct:<\/p>\n\n\n\n
type Dog struct {\n\tName string\n\tAge int\n}<\/code><\/pre>\n\n\n\nThis describes data.<\/p>\n\n\n\n
Example interface:<\/p>\n\n\n\n
type Speaker interface {\n\tSpeak() string\n}<\/code><\/pre>\n\n\n\nThis describes behavior.<\/p>\n\n\n\n
\n\n\n\nThe relationship between everything<\/h1>\n\n\n\n
flowchart TD\n A[\"Interface\"] --> B[\"Defines required methods\"]\n\n B --> C[\"Speak() string\"]\n\n D[\"Dog\"] --> E[\"Has Speak() string\"]\n F[\"Person\"] --> G[\"Has Speak() string\"]\n H[\"Car\"] --> I[\"Has Drive()\"]\n\n E --> J[\"Satisfies Speaker\"]\n G --> J\n I --> K[\"Does NOT satisfy Speaker\"]\n\n J --> L[\"Can be passed to function expecting Speaker\"]<\/code><\/pre>\n\n\n\n
\n\n\n\nThe Mental Model<\/h1>\n\n\n\n
Don’t think:<\/p>\n\n\n\n
Dog IS a Speaker<\/code><\/pre>\n\n\n\nInstead think:<\/p>\n\n\n\n
Dog CAN Speak<\/code><\/pre>\n\n\n\nTherefore:<\/p>\n\n\n\n
Dog can be USED AS a Speaker.<\/code><\/pre>\n\n\n\nThat is very close to how Go interfaces are intended to be understood.<\/p>\n\n\n\n
\n\n\n\nWhat \u2192 Why \u2192 When \u2192 How \u2192 Where<\/h1>\n\n\n\n
Question<\/th> Answer<\/th><\/tr><\/thead> What?<\/strong><\/td> An interface defines methods that a type must have<\/td><\/tr> Why?<\/strong><\/td> So one piece of code can work with many different types<\/td><\/tr> When?<\/strong><\/td> When different types share the same behavior<\/td><\/tr> How?<\/strong><\/td> Define an interface and give types matching methods<\/td><\/tr> Where?<\/strong><\/td> Commonly in function parameters, libraries, services, testing and abstractions<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n For implicit implementation:<\/p>\n\n\n\n
Question<\/th> Answer<\/th><\/tr><\/thead> What?<\/strong><\/td> Automatic interface satisfaction<\/td><\/tr> Why?<\/strong><\/td> Removes explicit implements<\/code> declarations<\/td><\/tr>When?<\/strong><\/td> Whenever a type’s methods match an interface<\/td><\/tr> How?<\/strong><\/td> Simply implement all required methods<\/td><\/tr> Where?<\/strong><\/td> Everywhere interfaces are used in Go<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\nThe 5 Rules to Remember<\/h1>\n\n\n\n
\n
- An interface describes behavior.<\/strong><\/li>\n<\/ol>\n\n\n\n
type Speaker interface {\n\tSpeak()\n}<\/code><\/pre>\n\n\n\n\n
- A type satisfies an interface by having all required methods.<\/strong><\/li>\n<\/ol>\n\n\n\n
func (Dog) Speak() {}<\/code><\/pre>\n\n\n\n\n
- There is no
implements<\/code> keyword.<\/strong><\/li>\n<\/ol>\n\n\n\nYou never write:<\/p>\n\n\n\n
Dog implements Speaker<\/code><\/pre>\n\n\n\n\n
- Multiple unrelated types can satisfy the same interface.<\/strong><\/li>\n<\/ol>\n\n\n\n
Dog \u2192 Speak()\nPerson \u2192 Speak()\nRobot \u2192 Speak()<\/code><\/pre>\n\n\n\nAll three can satisfy
Speaker<\/code>.<\/p>\n\n\n\n\n
- Functions can accept the interface instead of the concrete type.<\/strong><\/li>\n<\/ol>\n\n\n\n
func talk(s Speaker) {\n\ts.Speak()\n}<\/code><\/pre>\n\n\n\nNow
talk()<\/code> can work with every compatible type.<\/p>\n\n\n\n
\n\n\n\nOne-Sentence Summary<\/h1>\n\n\n\n
The entire concept can be reduced to:<\/p>\n\n\n\n
\nAn interface says “I need these methods”; any Go type that has those methods automatically satisfies the interface.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
So whenever you see:<\/p>\n\n\n\n
type X interface {\n\tDoSomething()\n}<\/code><\/pre>\n\n\n\nread it mentally as:<\/p>\n\n\n\n
\n“Give me anything that knows how to
DoSomething()<\/code>.”<\/strong><\/p>\n<\/blockquote>\n\n\n\nThat mental model will make Go interfaces much easier to understand.<\/p>\n","protected":false},"excerpt":{"rendered":"
These two ideas are closely related. The easiest mental model is: Interface = a list of behaviors.Implicit implementation = Go automatically accepts any type that has those… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1080","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1080","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=1080"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1080\/revisions"}],"predecessor-version":[{"id":1081,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1080\/revisions\/1081"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=1080"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=1080"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=1080"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}