Learn Exported vs Unexported Fields | Encapsulation and Interfaces

Swipe to show menu

Go uses capitalization as a fundamental mechanism to control the visibility of identifiers, including struct fields and methods. When you define a field or method with a name starting with an uppercase letter, it becomes exported, meaning it is accessible from other packages. Conversely, a name starting with a lowercase letter is unexported and only accessible within the same package. This convention is Go's approach to encapsulation, allowing you to hide internal implementation details and expose only the necessary API surface. Encapsulation is crucial for maintaining clear boundaries in your codebase, preventing unintended dependencies, and enabling safe refactoring.

main.go

settings/config.go


              1234567891011121314151617
            
package main

import (
	"fmt"
	"example.com/settings"
)

func main() {
	cfg := settings.Config{
		AppName: "MyApp",
	}
	// Accessing exported field
	fmt.Println("AppName:", cfg.AppName)

	// The following line would fail to compile, as dbPassword is unexported:
	// fmt.Println(cfg.dbPassword)
}

When designing backend packages, you should carefully consider which fields and methods truly need to be exported. Exposing only what is necessary keeps your package's API clean and reduces the risk of misuse or breaking changes. By making fields unexported, you can enforce invariants and control how data is accessed or modified, often by providing exported getter and setter methods or dedicated functions. This approach encourages loose coupling between packages and supports maintainable, robust code.

Everything was clear?

Thanks for your feedback!

Section 2. Chapter 1

Ask AI

Ask anything or try one of the suggested questions to begin our chat

Section 2. Chapter 1