Week 3: Structs, Methods & Interfaces

1. Defining Structs

A struct is a named collection of fields — Go's only real way to group related data together, with none of the class machinery (constructors, access modifiers, inheritance) that comes bundled with it in other languages.

type User struct {
    ID    int
    Name  string
    Email string
}

func main() {
    u := User{ID: 1, Name: "Asha", Email: "asha@example.com"}
    fmt.Println(u.Name) // Asha

    // a "zero value" struct — every field defaults to its type's zero value
    var empty User
    fmt.Println(empty) // {0  }
}

There's no separate constructor syntax — the idiomatic pattern for validated or defaulted construction is a plain function, conventionally named NewUser, that returns a fully-formed struct (or an error).

2. Methods: Value vs. Pointer Receivers

A method is a function with a receiver — the type it's attached to, written before the function name. The receiver can be a value (a copy) or a pointer (a reference to the original).

func (u User) Greeting() string { // value receiver: gets a copy of u
    return "Hi, " + u.Name
}

func (u *User) SetEmail(email string) { // pointer receiver: mutates the original
    u.Email = email
}

func main() {
    u := User{Name: "Asha"}
    fmt.Println(u.Greeting()) // "Hi, Asha" — reading, a copy is fine

    u.SetEmail("asha@new.com") // Go automatically takes &u here
    fmt.Println(u.Email)       // "asha@new.com" — the original was mutated
}

The rule of thumb: use a pointer receiver whenever the method needs to mutate the receiver, or the struct is large enough that copying it on every call is wasteful. Mixing receiver types on the same struct's methods is legal but considered poor style — pick one and stay consistent.

3. Interfaces & Structural Typing

An interface is a set of method signatures. A type satisfies it automatically the moment it implements those methods — there's no implements keyword, and a type can satisfy an interface it was never written with in mind.

type Greeter interface {
    Greeting() string
}

func Welcome(g Greeter) {
    fmt.Println(g.Greeting())
}

func main() {
    u := User{Name: "Asha"}
    Welcome(u) // User satisfies Greeter just by having a Greeting() method
}

This is Go's version of duck typing, checked at compile time — Welcome accepts anything with a Greeting() string method, whether or not that type's author ever heard of Greeter. It's what makes small, focused interfaces (often just one or two methods) so common in idiomatic Go: a caller only needs to define the interface it depends on, not coordinate with the implementer.

4. Composition over Inheritance

Instead of subclassing, Go lets a struct embed another — the outer struct gains the inner struct's fields and methods directly, without an explicit delegation step.

type Base struct {
    ID int
}

func (b Base) Describe() string {
    return fmt.Sprintf("entity #%d", b.ID)
}

type Product struct {
    Base   // embedded, no field name — "Base" is implied
    Name   string
    Price  float64
}

func main() {
    p := Product{Base: Base{ID: 7}, Name: "Widget", Price: 9.99}
    fmt.Println(p.ID)         // 7 — promoted field, accessed directly
    fmt.Println(p.Describe()) // "entity #7" — promoted method
}

This is composition, not inheritance — Product doesn't "become a" Base, it just has one, with its exported fields and methods promoted up for convenience. Combined with small interfaces, this is how Go achieves what inheritance-heavy languages use class hierarchies for, without the fragility of a deep inheritance tree.

5. Hands-on Exercise

6. Knowledge Check

Four quick questions. Expand each to check your answer.