Clean Code Practices with Structs in Go

Welcome to the very first lesson of the "Clean Code with Multiple Structs in Go" course! 🎉 This course aims to guide you in writing code that's easy to understand, maintain, and enhance. Within the broader scope of clean coding, effective struct collaboration is crucial for building well-structured applications. In this lesson, we will delve into the intricacies of struct collaboration and coupling—key factors that can make or break the maintainability of your software. Specifically, we'll address some common "code smells" that indicate problems in struct interactions and explore ways to resolve them.

Let's dive into the challenges of struct collaboration by focusing on four common code smells:

• Feature Envy: Occurs when a method in one struct is overly interested in methods or data in another struct.
• Inappropriate Intimacy: Describes a situation where two structs are too closely interconnected, sharing private details.
• Message Chains: Refer to sequences of method calls across several structs, indicating a lack of clear abstraction.
• Middle Man: Exists when a struct mainly delegates its behavior to another struct without adding functionality.

Understanding these code smells will enable you to improve your struct designs, resulting in cleaner and more maintainable code.

These code smells can significantly impact system design and maintainability. Let's consider their implications:

• They can lead to tightly coupled structs, making them difficult to modify or extend. 🔧
• Code readability decreases, as it becomes unclear which struct is responsible for which functionality.

Addressing these issues often results in code that's not only easier to read but also more flexible and scalable. Tackling these problems can markedly enhance software architecture, making it more robust and adaptable.

Feature Envy occurs when a method in one struct is more interested in the fields or methods of another struct than its own. Here's an example in Go:

package main

import "fmt"

type Item struct {
    Price    float64
    Quantity int
}

type ShoppingCart struct {
    Items []Item
}

func (sc ShoppingCart) CalculateTotalPrice() float64 {
    total := 0.0
    for _, item := range sc.Items {
        // Feature Envy: The ShoppingCart method is overly interested in the internal fields of Item
        total += item.Price * float64(item.Quantity)
    }
    return total
}

func main() {
    cart := ShoppingCart{
        Items: []Item{
            {Price: 5.0, Quantity: 2},
            {Price: 10.0, Quantity: 1},
        },
    }
    fmt.Printf("Total Price: %.2f\n", cart.CalculateTotalPrice())
}

In this scenario, CalculateTotalPrice in ShoppingCart overly accesses data from Item, indicating feature envy.

To refactor, consider moving the logic to the Item struct:

package main

import "fmt"

type Item struct {
    Price    float64
    Quantity int
}

func (item Item) CalculateTotal() float64 {
    return item.Price * float64(item.Quantity)
}

type ShoppingCart struct {
    Items []Item
}

func (sc ShoppingCart) CalculateTotalPrice() float64 {
    total := 0.0
    for _, item := range sc.Items {
        total += item.CalculateTotal()
    }
    return total
}

func main() {
    cart := ShoppingCart{
        Items: []Item{
            {Price: 5.0, Quantity: 2},
            {Price: 10.0, Quantity: 1},
        },
    }
    fmt.Printf("Total Price: %.2f\n", cart.CalculateTotalPrice())
}

Now, each Item calculates its own total, reducing dependency and distributing responsibility appropriately. ✔️