liveBook · Manning

Coupling

As explained in Learn Go with Pocket-Sized Projects

Coupling is the degree to which software components depend on one another and therefore must change together.

Coupling describes how strongly pieces of code depend on one another. Structures and functions that must be updated together are coupled. Spreading them across packages can make code quality harder to maintain, even when the package layout looks tidy. section 8.2.1

> tree
.
├── go.mod
├── internal
│   ├── api
│   │   ├── doc.go
│   │   └── http.go
│   └── handlers
│       ├── doc.go
│       ├── newgame
│       │   └── handler.go
│       └── router.go
└── main.go

The project tree separates the HTTP API, endpoint handler, and router. Use it to ask which files are likely to change together as the new-game endpoint grows. section 8.2.1

There is no fixed rule to put every function in one package or give every function its own. Keep related logic together where practical, consider how each package will grow, and refactor the layout when later changes reveal a poor fit. section 8.2.1

How Learn Go with Pocket-Sized Projects covers it

How deep it goes
Defines coupling through code that changes together and explains its maintenance tradeoff; it gives no metric for measuring it.
Examples
Uses a new-game endpoint split among API definitions, a handler, and a router.
What it assumes
Assumes familiarity with Go packages and functions rather than teaching them from zero.
What you can do after
Evaluate/understand package boundaries by checking which structures and functions will need updates together.
How it connects
Connects coupling to Go packages, HTTP handlers, code quality, and refactoring.

Also explained in

Compare how 17 books explain coupling →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Learn Go with Pocket-Sized Projects. The section links point to the parts of the book it draws on.