Controlar qué partes del código son visibles desde otros paquetes es fundamental para escribir software organizado y seguro. En Go, este mecanismo funciona de una forma sorprendentemente sencilla: la primera letra del identificador determina si es público o privado. Sin keywords especiales, sin decoradores, solo una convención tipográfica que el compilador hace cumplir de forma estricta.
¿Cómo funcionan los modificadores de acceso en Go?
En lenguajes como Java o C# existen palabras reservadas como public y private para definir la visibilidad de variables, funciones o tipos de datos. Go elimina esa complejidad con una regla única [01:00]:
- Primera letra en mayúscula: el elemento es público (exported), accesible desde cualquier paquete externo.
- Primera letra en minúscula: el elemento es privado (unexported), solo accesible dentro del mismo paquete.
Esta convención aplica a structs, funciones, variables y cualquier tipo de dato que declares dentro de un paquete.
¿Cómo crear un paquete con acceso público y privado?
Para ilustrar este concepto se crea una carpeta llamada mypackages dentro de src, con un archivo mypackages.go. La buena práctica es que el nombre del paquete coincida con el nombre de la carpeta [02:08].
Dentro de ese paquete se definen dos structs con la misma estructura pero diferente visibilidad:
go
package mypackages
// struct privado: solo accesible dentro de mypackages
type carPrivate struct {
brand string
year int
}
// CarPublic es un car con acceso público
type CarPublic struct {
Brand string
Year int
}
Observa que CarPublic tiene la primera letra en mayúscula tanto en el nombre del struct como en sus campos Brand y Year. El struct carPrivate, en cambio, usa minúsculas y queda restringido al paquete donde fue declarado.
¿Por qué el editor pide un comentario en los elementos públicos?
Cuando exportas un tipo de dato, Go espera que documentes su propósito con un comentario que comience con el nombre del identificador [03:35]. Esto no es solo una sugerencia del linter: es una buena práctica obligatoria en proyectos profesionales.
go
// CarPublic es un car con acceso público
type CarPublic struct {
¿Cómo importar y usar un paquete en el archivo main?
Desde el archivo main.go puedes importar el paquete usando la ruta relativa a partir de la carpeta src, que es donde vive tu variable de entorno GOPATH [04:22]. El editor suele detectar la importación de forma automática:
go
package main
import pk "mypackages"
func main() {
myCar := pk.CarPublic{}
myCar.Brand = "Ferrari"
myCar.Year = 2020
fmt.Println(myCar)
}
Aquí se utiliza un alias de importación (pk) para simplificar las llamadas al paquete [05:50]. En lugar de escribir mypackages.CarPublic, basta con pk.CarPublic.
¿Qué ocurre al intentar acceder a un campo o struct privado?
Si cambias Year a year (minúscula) en el struct público e intentas asignarle un valor desde main, el compilador lanza un error claro: no puede acceder a esa variable porque es privada [06:30].
Lo mismo sucede al intentar instanciar un struct privado como carPrivate desde otro paquete [07:55]. El runtime de Go indica que ese tipo de dato no existe fuera de su paquete de origen.
¿Funciona igual con las funciones?
Exactamente igual. Una función con la primera letra en mayúscula es pública; con minúscula, privada [08:40].
go
// PrintMessage es para imprimir un mensaje
func PrintMessage(text string) {
fmt.Println(text)
}
// función privada, solo accesible dentro de mypackages
func printMessage(text string) {
fmt.Println(text)
}
Desde main, la llamada pk.PrintMessage("Hola, Flash") funciona correctamente, mientras que pk.printMessage("Hola") genera un error de compilación indicando que la función no es accesible [10:10].
¿Cuándo usar acceso privado o público?
La recomendación es directa: si tu dato no necesita ser accesible desde fuera del paquete, mantenlo privado. Esto reduce el acoplamiento entre paquetes y protege la integridad de tus datos. Los modificadores de acceso se pueden aplicar a structs, funciones, slices, maps y cualquier campo dentro de estas estructuras.
¿Has probado ya a organizar tu código en paquetes con estas reglas de visibilidad? Comparte tu experiencia o dudas en los comentarios.
