When a library system puts member information and member behavior in the same class, one class can accumulate many data and code relations. Splitting them creates two simpler parts: data entities that hold information and code modules that manipulate it. section 1.2.1 section 2.0
The technique places behavior in stateless functions whose data arrives explicitly as an argument, rather than hiding state inside an object’s methods. Data and code can then be designed and understood independently. section 2.0 section 2.6
Use the principle diagram to see the intended boundary between data entities and code modules. section 2.0
The separation simplifies a system through several constraints:
- Data entities contain members but no code; their relationships use association and composition. section 2.4
- Code modules aggregate stateless functions; their relationships use module usage rather than inheritance. section 2.4
- Independent data and code parts can be understood in either order without tracing the other part’s details. section 1.2.1 section 2.4
- Changing permissions or member categories often adds focused functions instead of expanding a class hierarchy. section 2.5
Library permissions without a growing hierarchy
A library operation can receive libraryData explicitly, ask UserManagement whether the user is a librarian or Super member, and delegate retrieval to Catalog.getBookLendings. Adding VIP access similarly adds UserManagement.isVIPMember and a Catalog operation, without changing the data entities. section 2.5
For business logic that manipulates collections, keep intent-focused logic separate from data manipulation utilities. Discover each utility’s convenient signature, write its unit test, describe its behavior plainly, then implement it. section 14.5 section 14.5
