{"id":1063,"date":"2026-08-16T21:27:55","date_gmt":"2026-08-16T21:27:55","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1063"},"modified":"2026-08-16T21:27:56","modified_gmt":"2026-08-16T21:27:56","slug":"go-tutorials-module-package-function-method-interface","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/go-tutorials-module-package-function-method-interface\/","title":{"rendered":"Go Tutorials \u2014 Module, Package, Function, Method & Interface"},"content":{"rendered":"\n

These five concepts become much easier once you see how they fit together<\/strong>:<\/p>\n\n\n\n

flowchart TD\n    M[\"Module<br\/>Whole Go project\"]\n    P1[\"Package main\"]\n    P2[\"Package fmt\"]\n    F[\"Function<br\/>add()\"]\n    T[\"Type<br\/>Person\"]\n    ME[\"Method<br\/>person.Greet()\"]\n    I[\"Interface<br\/>Speaker\"]\n\n    M --> P1\n    P1 --> F\n    P1 --> T\n    T --> ME\n    I -. \"method satisfies\" .-> ME\n    P1 -->|\"imports\"| P2<\/code><\/pre>\n\n\n\n
The simplest mental model is:<\/p>\n\n\n\n
\n
Module = Project<\/strong>
Package = Folder \/ code group<\/strong>
Function = Standalone action<\/strong>
Method = Action belonging to a type<\/strong>
Interface = Required behavior<\/strong><\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n
1. Module<\/h1>\n\n\n\n
What is a Module?<\/h2>\n\n\n\n
A module is your Go project<\/strong>.<\/p>\n\n\n\n
It is normally a directory containing a file called:<\/p>\n\n\n\n
go.mod<\/code><\/pre>\n\n\n\n
Example:<\/p>\n\n\n\n
myapp\/\n\u251c\u2500\u2500 go.mod\n\u2514\u2500\u2500 main.go<\/code><\/pre>\n\n\n\n
Think:<\/p>\n\n\n\n
\n
Module = entire project<\/strong><\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n
Why do we need a Module?<\/h2>\n\n\n\n
Go uses the module to know:<\/p>\n\n\n\n
    \n
  • the name of your project<\/li>\n\n\n\n
  • which external dependencies your project uses<\/li>\n\n\n\n
  • which versions of dependencies should be downloaded<\/li>\n<\/ul>\n\n\n\n
    \n\n\n\n
    When do we use it?<\/h2>\n\n\n\n
    Normally when starting a new Go project:<\/p>\n\n\n\n
    mkdir myapp\ncd myapp\n\ngo mod init myapp<\/code><\/pre>\n\n\n\n
    Go creates:<\/p>\n\n\n\n
    go.mod<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Complete Example<\/h2>\n\n\n\n
    Run:<\/p>\n\n\n\n
    mkdir module-demo\ncd module-demo\n\ngo mod init module-demo<\/code><\/pre>\n\n\n\n
    You’ll see:<\/p>\n\n\n\n
    go: creating new go.mod: module module-demo<\/code><\/pre>\n\n\n\n
    Now create:<\/p>\n\n\n\n
    main.go<\/code><\/h3>\n\n\n\n
    package main\n\nimport \"fmt\"\n\nfunc main() {\n\t\/\/ This is our program.\n\tfmt.Println(\"Hello from my Go module!\")\n}<\/code><\/pre>\n\n\n\n
    Run:<\/p>\n\n\n\n
    go run .<\/code><\/pre>\n\n\n\n
    Output:<\/p>\n\n\n\n
    Hello from my Go module!<\/code><\/pre>\n\n\n\n
    Your directory now looks like:<\/p>\n\n\n\n
    module-demo\/\n\u251c\u2500\u2500 go.mod\n\u2514\u2500\u2500 main.go<\/code><\/pre>\n\n\n\n
    And go.mod<\/code> will look approximately like:<\/p>\n\n\n\n
    module module-demo\n\ngo 1.26<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    What does this mean?<\/h2>\n\n\n\n
    module module-demo<\/code><\/pre>\n\n\n\n
    means:<\/p>\n\n\n\n
    \n
    The name\/path of this module is module-demo<\/code>.<\/p>\n<\/blockquote>\n\n\n\n
    And:<\/p>\n\n\n\n
    go 1.26<\/code><\/pre>\n\n\n\n
    tells Go which Go language\/module version this project targets.<\/p>\n\n\n\n
    \n\n\n\n
    Where does Module sit?<\/h2>\n\n\n\n
    flowchart TD\n    A[\"module-demo<br\/>MODULE\"]\n    B[\"go.mod\"]\n    C[\"main.go\"]\n    D[\"package main\"]\n\n    A --> B\n    A --> C\n    C --> D<\/code><\/pre>\n\n\n\n
    Remember<\/h3>\n\n\n\n
    \n
    One project usually has one go.mod<\/code>.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    2. Package<\/h1>\n\n\n\n
    What is a Package?<\/h2>\n\n\n\n
    A package is a group of related Go code<\/strong>.<\/p>\n\n\n\n
    Every .go<\/code> file must declare which package it belongs to.<\/p>\n\n\n\n
    For example:<\/p>\n\n\n\n
    package main<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Why do we need Packages?<\/h2>\n\n\n\n
    Packages help organize code.<\/p>\n\n\n\n
    Imagine a large application:<\/p>\n\n\n\n
    shopping-app\/\n\u251c\u2500\u2500 main.go\n\u251c\u2500\u2500 users\/\n\u251c\u2500\u2500 payments\/\n\u251c\u2500\u2500 orders\/\n\u2514\u2500\u2500 products\/<\/code><\/pre>\n\n\n\n
    You could have packages such as:<\/p>\n\n\n\n
    main\nusers\npayments\norders\nproducts<\/code><\/pre>\n\n\n\n
    Instead of putting everything into one huge file.<\/p>\n\n\n\n
    \n\n\n\n
    When do we use Packages?<\/h2>\n\n\n\n
    Always.<\/p>\n\n\n\n
    Every Go file belongs to a package.<\/p>\n\n\n\n
    Even the smallest Go program has:<\/p>\n\n\n\n
    package main<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Complete Example<\/h2>\n\n\n\n
    Create main.go<\/code>:<\/p>\n\n\n\n
    package main\n\n\/\/ \u2191 This file belongs to the \"main\" package.\n\nimport \"fmt\"\n\n\/\/ \u2191 We are using another package called \"fmt\".\n\/\/ fmt is part of Go's standard library.\n\nfunc main() {\n\n\t\/\/ Println is a function inside the fmt package.\n\tfmt.Println(\"Hello Go!\")\n\n}<\/code><\/pre>\n\n\n\n
    Run:<\/p>\n\n\n\n
    go run main.go<\/code><\/pre>\n\n\n\n
    Output:<\/p>\n\n\n\n
    Hello Go!<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Look carefully at this<\/h2>\n\n\n\n
    fmt.Println(\"Hello Go!\")<\/code><\/pre>\n\n\n\n
    Here:<\/p>\n\n\n\n
    fmt<\/code><\/pre>\n\n\n\n
    is the package<\/strong>.<\/p>\n\n\n\n
    And:<\/p>\n\n\n\n
    Println<\/code><\/pre>\n\n\n\n
    is a function inside the package<\/strong>.<\/p>\n\n\n\n
    So:<\/p>\n\n\n\n
    fmt.Println()\n\u2502   \u2502\n\u2502   \u2514\u2500\u2500 Function\n\u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500 Package<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    What is special about package main<\/code>?<\/h2>\n\n\n\n
    This is important.<\/p>\n\n\n\n
    package main<\/code><\/pre>\n\n\n\n
    means:<\/p>\n\n\n\n
    \n
    This package is intended to build an executable program.<\/p>\n<\/blockquote>\n\n\n\n
    For an executable Go program, you normally need:<\/p>\n\n\n\n
    package main\n\nfunc main() {\n\n}<\/code><\/pre>\n\n\n\n
    So:<\/p>\n\n\n\n
    package main\n     +\nfunc main()\n     =\nexecutable Go program<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Package relationship<\/h2>\n\n\n\n
    flowchart LR\n    A[\"package main\"] -->|\"uses\"| B[\"package fmt\"]\n    B --> C[\"Println()\"]<\/code><\/pre>\n\n\n\n
    Remember<\/h3>\n\n\n\n
    \n
    Module contains packages.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    3. Function<\/h1>\n\n\n\n
    What is a Function?<\/h2>\n\n\n\n
    A function is a named block of code that performs a task<\/strong>.<\/p>\n\n\n\n
    Example:<\/p>\n\n\n\n
    func add(a int, b int) int {\n\treturn a + b\n}<\/code><\/pre>\n\n\n\n
    Think:<\/p>\n\n\n\n
    \n
    Function = reusable action<\/p>\n<\/blockquote>\n\n\n\n
    Examples:<\/p>\n\n\n\n
    add()\nlogin()\nsendEmail()\ncalculateSalary()\nprintReport()<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Why use Functions?<\/h2>\n\n\n\n
    Without functions, you would repeat the same code again and again.<\/p>\n\n\n\n
    Instead of:<\/p>\n\n\n\n
    result := 10 + 20<\/code><\/pre>\n\n\n\n
    everywhere, you can create:<\/p>\n\n\n\n
    add(10, 20)<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Complete Example<\/h2>\n\n\n\n
    package main\n\nimport \"fmt\"\n\n\/\/ add is a FUNCTION.\n\/\/\n\/\/ a int  -> first input\n\/\/ b int  -> second input\n\/\/ int    -> function returns an integer\nfunc add(a int, b int) int {\n\n\tresult := a + b\n\n\treturn result\n}\n\nfunc main() {\n\n\t\/\/ Calling the function\n\tanswer := add(10, 20)\n\n\tfmt.Println(\"Answer:\", answer)\n}<\/code><\/pre>\n\n\n\n
    Run:<\/p>\n\n\n\n
    go run main.go<\/code><\/pre>\n\n\n\n
    Output:<\/p>\n\n\n\n
    Answer: 30<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Understand the function<\/h2>\n\n\n\n
    func add(a int, b int) int {\n\treturn a + b\n}<\/code><\/pre>\n\n\n\n
    Break it down:<\/p>\n\n\n\n
    func add(a int, b int) int\n\u2502    \u2502   \u2502             \u2502\n\u2502    \u2502   \u2502             \u2514\u2500\u2500 return type\n\u2502    \u2502   \u2502\n\u2502    \u2502   \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 parameters\n\u2502    \u2502\n\u2502    \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 function name\n\u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 function keyword<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    How do we call it?<\/h2>\n\n\n\n
    answer := add(10, 20)<\/code><\/pre>\n\n\n\n
    Flow:<\/p>\n\n\n\n
    flowchart LR\n    A[\"main()\"] --> B[\"add(10,20)\"]\n    B --> C[\"10 + 20\"]\n    C --> D[\"return 30\"]\n    D --> A<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Where can a function exist?<\/h2>\n\n\n\n
    A normal function belongs to a package<\/strong>.<\/p>\n\n\n\n
    For example:<\/p>\n\n\n\n
    package main\n\nfunc add() {\n}<\/code><\/pre>\n\n\n\n
    add()<\/code> belongs to package main<\/code>.<\/p>\n\n\n\n
    Remember<\/h3>\n\n\n\n
    \n
    Function = standalone behavior.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    4. Method<\/h1>\n\n\n\n
    This is where many Go learners get confused.<\/p>\n\n\n\n
    A method is almost the same as a function.<\/p>\n\n\n\n
    The difference is:<\/p>\n\n\n\n
    \n
    A method belongs to a type.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    Function vs Method<\/h1>\n\n\n\n
    Function:<\/p>\n\n\n\n
    func greet() {\n\n}<\/code><\/pre>\n\n\n\n
    Method:<\/p>\n\n\n\n
    func (p Person) greet() {\n\n}<\/code><\/pre>\n\n\n\n
    Notice this:<\/p>\n\n\n\n
    (p Person)<\/code><\/pre>\n\n\n\n
    That is called the receiver<\/strong>.<\/p>\n\n\n\n
    It connects the function to Person<\/code>.<\/p>\n\n\n\n
    \n\n\n\n
    Why use Methods?<\/h2>\n\n\n\n
    Suppose we have:<\/p>\n\n\n\n
    type Person struct {\n\tName string\n}<\/code><\/pre>\n\n\n\n
    A person may perform actions:<\/p>\n\n\n\n
    Person\n \u251c\u2500\u2500 Greet()\n \u251c\u2500\u2500 Walk()\n \u251c\u2500\u2500 Sleep()\n \u2514\u2500\u2500 Work()<\/code><\/pre>\n\n\n\n
    These actions naturally belong to Person<\/code>.<\/p>\n\n\n\n
    So methods make sense.<\/p>\n\n\n\n
    \n\n\n\n
    Complete Example<\/h2>\n\n\n\n
    package main\n\nimport \"fmt\"\n\n\/\/ Person is a custom type.\ntype Person struct {\n\tName string\n}\n\n\/\/ Greet is a METHOD belonging to Person.\n\/\/\n\/\/ (p Person) is called the RECEIVER.\n\/\/\n\/\/ It means:\n\/\/ \"This method belongs to Person.\"\nfunc (p Person) Greet() {\n\n\tfmt.Println(\"Hello, my name is\", p.Name)\n}\n\nfunc main() {\n\n\t\/\/ Create a Person value\n\tperson := Person{\n\t\tName: \"Rajesh\",\n\t}\n\n\t\/\/ Call the method using the Person value\n\tperson.Greet()\n}<\/code><\/pre>\n\n\n\n
    Run:<\/p>\n\n\n\n
    go run main.go<\/code><\/pre>\n\n\n\n
    Output:<\/p>\n\n\n\n
    Hello, my name is Rajesh<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Understand this line<\/h2>\n\n\n\n
    func (p Person) Greet()<\/code><\/pre>\n\n\n\n
    Break it down:<\/p>\n\n\n\n
    func (p Person) Greet()\n\u2502     \u2502        \u2502\n\u2502     \u2502        \u2514\u2500\u2500 method name\n\u2502     \u2502\n\u2502     \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 receiver\n\u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 keyword<\/code><\/pre>\n\n\n\n
    The receiver:<\/p>\n\n\n\n
    (p Person)<\/code><\/pre>\n\n\n\n
    means:<\/p>\n\n\n\n
    \n
    Greet()<\/code> belongs to Person<\/code>.<\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    Therefore we can write<\/h2>\n\n\n\n
    person.Greet()<\/code><\/pre>\n\n\n\n
    Think:<\/p>\n\n\n\n
    person.Greet()\n\u2502      \u2502\n\u2502      \u2514\u2500\u2500 Method\n\u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 Person object\/value<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Function vs Method<\/h2>\n\n\n\n
    Normal function:<\/p>\n\n\n\n
    Greet(person)<\/code><\/pre>\n\n\n\n
    Method:<\/p>\n\n\n\n
    person.Greet()<\/code><\/pre>\n\n\n\n
    Conceptually:<\/p>\n\n\n\n
    flowchart LR\n    A[\"Person\"] --> B[\"Greet()\"]\n    A --> C[\"Walk()\"]\n    A --> D[\"Work()\"]<\/code><\/pre>\n\n\n\n
    Remember<\/h3>\n\n\n\n
    \n
    Function = standalone action<\/strong><\/p>\n<\/blockquote>\n\n\n\n
    \n
    Method = action attached to a type<\/strong><\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    5. Interface<\/h1>\n\n\n\n
    This is usually the most confusing one.<\/p>\n\n\n\n
    But there is a very simple way to think about it.<\/p>\n\n\n\n
    \n
    Interface = a list of behaviors\/methods that something must have.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
    Suppose we create:<\/p>\n\n\n\n
    type Speaker interface {\n\tSpeak()\n}<\/code><\/pre>\n\n\n\n
    This means:<\/p>\n\n\n\n
    \n
    Anything that has a Speak()<\/code> method can be considered a Speaker<\/code>.<\/p>\n<\/blockquote>\n\n\n\n
    That’s the core idea.<\/p>\n\n\n\n
    \n\n\n\n
    Why use an Interface?<\/h1>\n\n\n\n
    Imagine:<\/p>\n\n\n\n
    Dog can Speak()\nPerson can Speak()\nRobot can Speak()<\/code><\/pre>\n\n\n\n
    All three are completely different types.<\/p>\n\n\n\n
    But they have one thing in common:<\/p>\n\n\n\n
    Speak()<\/code><\/pre>\n\n\n\n
    So we could create:<\/p>\n\n\n\n
    type Speaker interface {\n\tSpeak()\n}<\/code><\/pre>\n\n\n\n
    Now functions can work with anything that knows how to Speak<\/strong>.<\/p>\n\n\n\n
    \n\n\n\n
    Complete Interface Example<\/h1>\n\n\n\n
    package main\n\nimport \"fmt\"\n\n\/\/ Speaker is an INTERFACE.\n\/\/\n\/\/ Anything that has:\n\/\/\n\/\/ Speak()\n\/\/\n\/\/ automatically satisfies this interface.\ntype Speaker interface {\n\tSpeak()\n}\n\n\/\/ Person is a custom type.\ntype Person struct {\n\tName string\n}\n\n\/\/ Person has a Speak method.\n\/\/\n\/\/ Therefore Person automatically satisfies\n\/\/ the Speaker interface.\nfunc (p Person) Speak() {\n\n\tfmt.Println(p.Name, \"says hello!\")\n}\n\n\/\/ This function accepts ANYTHING\n\/\/ that satisfies the Speaker interface.\nfunc makeItSpeak(s Speaker) {\n\n\ts.Speak()\n}\n\nfunc main() {\n\n\tperson := Person{\n\t\tName: \"Rajesh\",\n\t}\n\n\t\/\/ Person has Speak()\n\t\/\/ therefore Person can be passed as Speaker.\n\tmakeItSpeak(person)\n}<\/code><\/pre>\n\n\n\n
    Run:<\/p>\n\n\n\n
    go run main.go<\/code><\/pre>\n\n\n\n
    Output:<\/p>\n\n\n\n
    Rajesh says hello!<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    The important part<\/h1>\n\n\n\n
    We created:<\/p>\n\n\n\n
    type Speaker interface {\n\tSpeak()\n}<\/code><\/pre>\n\n\n\n
    And Person<\/code> has:<\/p>\n\n\n\n
    func (p Person) Speak() {\n}<\/code><\/pre>\n\n\n\n
    Therefore:<\/p>\n\n\n\n
    Speaker requires Speak()\n           \u2191\n           \u2502\nPerson has Speak()\n           \u2502\n           \u2193\nPerson satisfies Speaker<\/code><\/pre>\n\n\n\n
    You do NOT<\/strong> write something like:<\/p>\n\n\n\n
    Person implements Speaker<\/code><\/pre>\n\n\n\n
    Go figures it out automatically.<\/p>\n\n\n\n
    This is called implicit interface implementation<\/strong>.<\/p>\n\n\n\n
    \n\n\n\n
    Visualize it<\/h2>\n\n\n\n
    flowchart TD\n    I[\"Speaker Interface<br\/>requires Speak()\"]\n\n    P[\"Person\"]\n    D[\"Dog\"]\n    R[\"Robot\"]\n\n    PM[\"Speak()\"]\n    DM[\"Speak()\"]\n    RM[\"Speak()\"]\n\n    P --> PM\n    D --> DM\n    R --> RM\n\n    PM --> I\n    DM --> I\n    RM --> I<\/code><\/pre>\n\n\n\n
    If all three types have:<\/p>\n\n\n\n
    Speak()<\/code><\/pre>\n\n\n\n
    then all three satisfy:<\/p>\n\n\n\n
    Speaker<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    The Complete Mental Model<\/h1>\n\n\n\n
    Now connect everything together.<\/p>\n\n\n\n
    Imagine this project:<\/p>\n\n\n\n
    shop\/\n\u251c\u2500\u2500 go.mod\n\u2514\u2500\u2500 main.go<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Module<\/h3>\n\n\n\n
    shop<\/code><\/pre>\n\n\n\n
    The entire project.<\/p>\n\n\n\n
    \n\n\n\n
    Package<\/h3>\n\n\n\n
    Inside main.go<\/code>:<\/p>\n\n\n\n
    package main<\/code><\/pre>\n\n\n\n
    Code organization.<\/p>\n\n\n\n
    \n\n\n\n
    Function<\/h3>\n\n\n\n
    func calculatePrice() {\n\n}<\/code><\/pre>\n\n\n\n
    Standalone behavior.<\/p>\n\n\n\n
    \n\n\n\n
    Type<\/h3>\n\n\n\n
    type Customer struct {\n\tName string\n}<\/code><\/pre>\n\n\n\n
    Represents something.<\/p>\n\n\n\n
    \n\n\n\n
    Method<\/h3>\n\n\n\n
    func (c Customer) Buy() {\n\n}<\/code><\/pre>\n\n\n\n
    Behavior attached to Customer<\/code>.<\/p>\n\n\n\n
    \n\n\n\n
    Interface<\/h3>\n\n\n\n
    type Buyer interface {\n\tBuy()\n}<\/code><\/pre>\n\n\n\n
    Defines the behavior something must have.<\/p>\n\n\n\n
    \n\n\n\n
    How Everything Fits Together<\/h1>\n\n\n\n
    flowchart TD\n    M[\"MODULE<br\/>shopping-app\"]\n\n    P[\"PACKAGE<br\/>main\"]\n\n    F[\"FUNCTION<br\/>calculatePrice()\"]\n\n    T[\"TYPE<br\/>Customer\"]\n\n    ME[\"METHOD<br\/>customer.Buy()\"]\n\n    I[\"INTERFACE<br\/>Buyer<br\/>requires Buy()\"]\n\n    M --> P\n\n    P --> F\n    P --> T\n    P --> I\n\n    T --> ME\n\n    ME -. \"satisfies\" .-> I<\/code><\/pre>\n\n\n\n
    That one diagram is worth remembering.<\/p>\n\n\n\n
    \n\n\n\n
    Master Comparison<\/h1>\n\n\n\n
    Concept<\/th>Simple Meaning<\/th>Example<\/th>Belongs To \/ Contains<\/th>Main Purpose<\/th><\/tr><\/thead>
    Module<\/strong><\/td>Entire Go project<\/td>module shopping<\/code><\/td>Contains packages<\/td>Project\/dependency management<\/td><\/tr>
    Package<\/strong><\/td>Group of Go code<\/td>package main<\/code><\/td>Belongs to module<\/td>Organize code<\/td><\/tr>
    Function<\/strong><\/td>Standalone action<\/td>add()<\/code><\/td>Belongs to package<\/td>Perform reusable work<\/td><\/tr>
    Method<\/strong><\/td>Function attached to a type<\/td>person.Greet()<\/code><\/td>Belongs to a type<\/td>Give behavior to types<\/td><\/tr>
    Interface<\/strong><\/td>Required methods\/behavior<\/td>Speaker<\/code><\/td>Defined in a package<\/td>Allow different types to share behavior<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    \n\n\n\n
    Module vs Package<\/h1>\n\n\n\n
    Module<\/th>Package<\/th><\/tr><\/thead>
    Entire project<\/td>Part of project<\/td><\/tr>
    Defined by go.mod<\/code><\/td>Defined by package xxx<\/code><\/td><\/tr>
    Can contain many packages<\/td>Contains Go files\/types\/functions<\/td><\/tr>
    Handles dependencies<\/td>Organizes code<\/td><\/tr>
    Example shopping-app<\/code><\/td>Example payment<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Think:<\/p>\n\n\n\n
    Company\n  \u2193\nDepartments<\/code><\/pre>\n\n\n\n
    similar to:<\/p>\n\n\n\n
    Module\n  \u2193\nPackages<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Package vs Function<\/h1>\n\n\n\n
    Package<\/th>Function<\/th><\/tr><\/thead>
    Groups code<\/td>Performs an action<\/td><\/tr>
    Contains functions<\/td>Lives inside package<\/td><\/tr>
    fmt<\/code><\/td>Println()<\/code><\/td><\/tr>
    math<\/code><\/td>Sqrt()<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Example:<\/p>\n\n\n\n
    fmt.Println()<\/code><\/pre>\n\n\n\n
    fmt       = package\nPrintln   = function<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Function vs Method<\/h1>\n\n\n\n
    This distinction is extremely important.<\/p>\n\n\n\n
    Function<\/th>Method<\/th><\/tr><\/thead>
    Standalone<\/td>Attached to a type<\/td><\/tr>
    No receiver<\/td>Has receiver<\/td><\/tr>
    add(10,20)<\/code><\/td>person.Greet()<\/code><\/td><\/tr>
    func add()<\/code><\/td>func (p Person) Greet()<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Function:<\/p>\n\n\n\n
    func greet() {\n}<\/code><\/pre>\n\n\n\n
    Method:<\/p>\n\n\n\n
    func (p Person) greet() {\n}<\/code><\/pre>\n\n\n\n
    The magic difference is:<\/p>\n\n\n\n
    (p Person)<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Method vs Interface<\/h1>\n\n\n\n
    Method<\/th>Interface<\/th><\/tr><\/thead>
    Actual behavior\/code<\/td>Required behavior<\/td><\/tr>
    Contains implementation<\/td>Usually only method signatures<\/td><\/tr>
    Speak()<\/code> prints something<\/td>Says “Speak()<\/code> must exist”<\/td><\/tr>
    Attached to a type<\/td>Can be satisfied by many types<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Example:<\/p>\n\n\n\n
    Interface says:<\/p>\n\n\n\n
    type Speaker interface {\n\tSpeak()\n}<\/code><\/pre>\n\n\n\n
    Person provides:<\/p>\n\n\n\n
    func (p Person) Speak() {\n\tfmt.Println(\"Hello\")\n}<\/code><\/pre>\n\n\n\n
    Therefore:<\/p>\n\n\n\n
    Person \u2192 satisfies \u2192 Speaker<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Function vs Interface<\/h1>\n\n\n\n
    Function<\/th>Interface<\/th><\/tr><\/thead>
    Performs actual work<\/td>Describes required behavior<\/td><\/tr>
    Contains code<\/td>Contains method signatures<\/td><\/tr>
    add()<\/code><\/td>Speaker<\/code><\/td><\/tr>
    Called directly<\/td>Used as a type\/contract<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    For example:<\/p>\n\n\n\n
    func makeItSpeak(s Speaker) {\n\ts.Speak()\n}<\/code><\/pre>\n\n\n\n
    Here:<\/p>\n\n\n\n
    makeItSpeak = function\nSpeaker     = interface\nSpeak       = required method<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Module vs Everything Else<\/h1>\n\n\n\n
    This hierarchy makes it easier:<\/p>\n\n\n\n
    MODULE\n\u2502\n\u251c\u2500\u2500 PACKAGE\n\u2502    \u2502\n\u2502    \u251c\u2500\u2500 Function\n\u2502    \u2502\n\u2502    \u251c\u2500\u2500 Type\n\u2502    \u2502     \u2502\n\u2502    \u2502     \u2514\u2500\u2500 Method\n\u2502    \u2502\n\u2502    \u2514\u2500\u2500 Interface\n\u2502\n\u2514\u2500\u2500 PACKAGE\n     \u2502\n     \u251c\u2500\u2500 Function\n     \u251c\u2500\u2500 Type\n     \u2514\u2500\u2500 Interface<\/code><\/pre>\n\n\n\n
    Or visually:<\/p>\n\n\n\n
    flowchart TD\n    M[\"MODULE\"]\n\n    P1[\"PACKAGE\"]\n    P2[\"PACKAGE\"]\n\n    F[\"FUNCTION\"]\n    T[\"TYPE\"]\n    ME[\"METHOD\"]\n    I[\"INTERFACE\"]\n\n    M --> P1\n    M --> P2\n\n    P1 --> F\n    P1 --> T\n    P1 --> I\n\n    T --> ME<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    One-Line Definitions You Should Memorize<\/h1>\n\n\n\n
    Concept<\/th>Memorize This<\/th><\/tr><\/thead>
    Module<\/strong><\/td>A Go project containing one or more packages<\/td><\/tr>
    Package<\/strong><\/td>A group of related Go files\/code<\/td><\/tr>
    Function<\/strong><\/td>A reusable standalone block of code<\/td><\/tr>
    Method<\/strong><\/td>A function attached to a type<\/td><\/tr>
    Interface<\/strong><\/td>A set of methods describing behavior<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    \n\n\n\n
    The 5 Questions to Ask Yourself<\/h1>\n\n\n\n
    Whenever you see Go code, identify these things.<\/p>\n\n\n\n
    1. What is the module?<\/h3>\n\n\n\n
    Look at:<\/p>\n\n\n\n
    go.mod<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    2. What package am I in?<\/h3>\n\n\n\n
    Look at the first line:<\/p>\n\n\n\n
    package main<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    3. Is this a function?<\/h3>\n\n\n\n
    Look for:<\/p>\n\n\n\n
    func add() {\n}<\/code><\/pre>\n\n\n\n
    No receiver \u2192 function<\/strong>.<\/p>\n\n\n\n
    \n\n\n\n
    4. Is this a method?<\/h3>\n\n\n\n
    Look for:<\/p>\n\n\n\n
    func (p Person) Greet() {\n}<\/code><\/pre>\n\n\n\n
    Receiver exists:<\/p>\n\n\n\n
    (p Person)<\/code><\/pre>\n\n\n\n
    \u2192 method<\/strong><\/p>\n\n\n\n
    \n\n\n\n
    5. Is this an interface?<\/h3>\n\n\n\n
    Look for:<\/p>\n\n\n\n
    type Speaker interface {\n\tSpeak()\n}<\/code><\/pre>\n\n\n\n
    \u2192 interface<\/strong><\/p>\n\n\n\n
    \n\n\n\n
    Final Example to Test Your Understanding<\/h1>\n\n\n\n
    Don’t run this yet. Just identify each part:<\/p>\n\n\n\n
    package main\n\nimport \"fmt\"\n\ntype Person struct {\n\tName string\n}\n\ntype Speaker interface {\n\tSpeak()\n}\n\nfunc add(a int, b int) int {\n\treturn a + b\n}\n\nfunc (p Person) Speak() {\n\tfmt.Println(p.Name, \"is speaking\")\n}\n\nfunc main() {\n\n\tp := Person{Name: \"Rajesh\"}\n\n\tp.Speak()\n\n\tfmt.Println(add(10, 20))\n}<\/code><\/pre>\n\n\n\n
    The answer is:<\/p>\n\n\n\n
    package main\n      \u2193\nPACKAGE\n\n\ntype Person struct\n      \u2193\nTYPE\n\n\ntype Speaker interface\n      \u2193\nINTERFACE\n\n\nfunc add(...)\n      \u2193\nFUNCTION\n\n\nfunc (p Person) Speak()\n      \u2193\nMETHOD\n\n\nfunc main()\n      \u2193\nFUNCTION<\/code><\/pre>\n\n\n\n
    And if the directory has:<\/p>\n\n\n\n
    go.mod<\/code><\/pre>\n\n\n\n
    then the entire directory\/project is the:<\/p>\n\n\n\n
    MODULE<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    The Most Important Picture<\/h1>\n\n\n\n
    Keep this mental picture:<\/p>\n\n\n\n
    flowchart LR\n    M[\"Module<br\/>PROJECT\"] --> P[\"Package<br\/>CODE GROUP\"]\n\n    P --> F[\"Function<br\/>DO SOMETHING\"]\n\n    P --> T[\"Type<br\/>REPRESENT SOMETHING\"]\n\n    T --> ME[\"Method<br\/>TYPE CAN DO SOMETHING\"]\n\n    P --> I[\"Interface<br\/>MUST BE ABLE TO DO SOMETHING\"]\n\n    ME -. \"can satisfy\" .-> I<\/code><\/pre>\n\n\n\n
    In plain English<\/h3>\n\n\n\n
    \n
    Module:<\/strong> This is my project.
    Package:<\/strong> This is how I organize my project’s code.
    Function:<\/strong> Do this work.
    Method:<\/strong> This particular type can do this work.
    Interface:<\/strong> I don’t care what the type is, as long as it can do this work.<\/p>\n<\/blockquote>\n\n\n\n
    If you get these five sentences clear, Go functions, methods, and interfaces become much easier to understand.<\/strong><\/p>\n\n\n\n
    <\/p>\n","protected":false},"excerpt":{"rendered":"
    These five concepts become much easier once you see how they fit together: The simplest mental model is: Module = ProjectPackage = Folder \/ code groupFunction =… <\/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-1063","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1063","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=1063"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1063\/revisions"}],"predecessor-version":[{"id":1064,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1063\/revisions\/1064"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=1063"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=1063"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=1063"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}