Objects in a Codebase

PartPart of Object Orientation as the Beginning of Software Engineering. A well-designed class does not stay alone for long — it sits in a history of changes, needs explaining to someone who did not write it, and makes decisions that affect real people's data. None of that is separate from the OOP module; it is what the module's content looks like once more than one person, or one sitting, is involved.

Git as a Record of Reasoning Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

ThisThis is not a Git tutorial. It is a look at what version control is actually for, once a design is being worked out rather than just typed in: a record of how it got that way.

1. Create EquipmentItem with validated identity
2. Add lending behaviour and availability query
3. Add tests for repeated lending
4. Extract LoanRepository interface
5. Refactor LoanService to use the repository

Each step is small, reversible, and leaves the class in a working state — which is what makes a commit history readable afterwards as a sequence of decisions rather than one undifferentiated dump. Compare what each commit message actually communicates:

The left column is Pro Git's own advice in practice: a commit message that explains why, written so that someone reading the log later — including you, in six months — can follow the reasoning without reopening every diff¹. A small, bounded branch for trying an alternative design, and a diff that shows a reviewer exactly what changed and why, both follow from the same idea: history is for reading, not just for undo.

Independent-learning lead. Issue references (linking a commit to the problem it addresses) and code review (someone else reading a diff before it merges) are both natural next steps once a project has more than one contributor or more than one evening's work — see Issue Tracking: CSGitLab and GitHub.

Documentation as Design Evidence Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

ThreeThree short forms of documentation do most of the useful work, and none of them restate the code line by line.

The Public Contract

/**
 * Lends this item to the supplied borrower.
 *
 * @throws IllegalArgumentException if borrower is null
 * @throws IllegalStateException if the item is already on loan
 */
public void lendTo(Borrower borrower) {
    // ...
}

Useful Javadoc describes the contract a caller can rely on — what can go wrong and under what name — not a translation of the method body into English.

The README

# Equipment Loan Example

## Purpose
Models the lending and return of university equipment.

## Running the tests
./mvnw test

## Main design decisions
- Items protect their own lending state.
- Storage is accessed through LoanRepository.
- Borrower identifiers are excluded from routine logs.

## Known limitations
- No persistent database implementation.
- No treatment of concurrent lending requests.

The "Known limitations" section matters as much as the rest. Stating plainly what a system does not yet handle is more useful to the next person than silence would be.

A Small Decision Record

## Decision: represent availability through loan state

We did not store a separate `available` boolean because it could
contradict the current-loan field. Availability is calculated from
the presence or absence of an active loan.

This is the encapsulation signal from the main page, written down for a future reader rather than left implicit in the code. A decision record like this is what lets someone maintaining the system later understand why it looks the way it does, not just what it currently does.

Privacy, Security, and Accessibility in the Same Design Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

TheseThese questions are easy to wave at in the abstract and easy to ignore in practice. Tying each one to the equipment-loan system keeps it concrete.

Privacy

Does Borrower need a full name, or does an institutional identifier do the job? UK GDPR's data minimisation principle states the test directly: personal data must be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed"². A borrower's name sitting in a default toString() that ends up in a log file is exactly the kind of accidental disclosure that principle is aimed at — along with how long loan history is retained after an item is returned, and who can read it. See Data Protection Law and Ethics for the fuller legal picture.

Security

Input validation (the constructor's own checks) is necessary and is not the whole of security. Authorisation — who is allowed to lend or override a loan — is a separate question from authentication (who the system believes they are). Secrets have no place in a Git history at all, committed or not. An error message that tells a caller exactly why an operation failed can also tell an attacker exactly what to try next; "operation not permitted" is sometimes the more responsible message, not the less informative one. See Security Design Principles.

Accessibility

If a status display reports only AVAILABLE = green and ON LOAN = red, a reader who cannot distinguish the two colours receives no information at all. WCAG's own success criteria make this explicit: colour must not be the only visual means of conveying information, distinguishing a response, or indicating an action³ — a label that reads "Available" or "On loan" alongside the colour costs almost nothing and fixes the problem outright. Accessibility is a requirement to design for from the start, not a pass applied to a finished interface.

Ethics

A maximum-loan rule protects fairness in the ordinary case and can disadvantage someone with a genuine need in an unusual one. Should staff be able to override it — and if they can, what record should that override leave? Loan history, collected for the mundane purpose of tracking equipment, could in principle answer questions nobody told borrowers it would be used for; that gap between stated purpose and possible use is worth noticing even in a system this small. See Professional Ethics.

Related Topics

• Object Orientation as the Beginning of Software Engineering — the hub page this one continues from.
• Testing Object Behaviour — the tests that make a commit like "Prevent an item being lent while already on loan" verifiable, not just claimed.
• Issue Tracking: CSGitLab and GitHub — where commits and issues meet once more than one person is working on the same code.
• Data Protection Law and Ethics — the fuller legal framework behind this page's privacy signal.
• Security Design Principles — the broader design discipline behind this page's security signal.

References