It's maybe borderline whether chain administration belongs to the basic building blocks or in the 'advanced' section. It's here because it's actually a MoveAdministration implementation that's a bit more advanced in that it also keeps chain-information.
A chain is a set of connected stones by one color. As such they are inseparable. If they get captured they get captured all together. That also means the stones in a chain share their liberties. Since a chain is such a basic unit of information and the number of liberties it has of such vital importance, it makes sense to keep this information available to other parts of a Go-playing engine.
There are many ways in which this information can be obtained. But the basic idea is always the same. What the tesuji.games.go.common.ChainAdministration class attempts to do is to compute and update this information incrementally whenever a stone is played. And when a move is taken back. Taking back a move doesn't happen often in normal play, but it happens very often by modules that read ahead.
So what is the information we'd like to make available and how can we do this as efficiently as possible? Here is an attempt to analyze what is theoretically the minimum amount of computationally effort that is necessary to compute this information.
So it makes sense to define a Chain data-structure. What we'd like to store in it is a list of stones that are in the chain and a list of the liberties that the chain has. This is information that is very suitable for incremental computation.
Whenever a move is played, it always affects exactly the chains directly next to that move played. It's a short list of the possible circumstances that can happen when a stone is added.