The brief: splitting a trip’s expenses fairly

Everything in this course now comes together on one real program. Over the next five lessons you will design, build, and test a command-line Kotlin application — a trip expense splitter, the sort of thing you would genuinely reach for after a holiday with friends. It is small enough to finish and rich enough to exercise data classes, null safety, collections, functions, error handling, and tests — everything the course taught.

Read the brief as a problem to solve, then, before the design lesson, sketch your own model. Comparing your sketch to the built version is where the learning is.

The problem

A group of friends takes a trip to Goa. Along the way, different people pay for different things — one pays for the hotel, another for petrol, a third for dinner. Everyone is meant to share the costs equally, but who actually paid is all over the place. At the end of the trip, the question is the one everybody dreads working out by hand:

"Who owes whom, and how much, so that everyone has paid their fair share?"

The program should let you record expenses (what, who paid, how much, and who it was shared between), then produce the shortest list of payments that settles everyone up.

That last part is the interesting bit. If Kavita paid for the hotel and Ravi paid for petrol, you do not want a tangle of "Ravi owes Kavita ₹1500, Kavita owes Ravi ₹1000, …". You want the net result: the minimum set of transfers that leaves everyone even. That is a real little algorithm, and building it is the satisfying core of the capstone.

Reading the brief for what it needs

Work through it the way the best-practices module taught — nouns, then the hard requirements.

The nouns become the model. A person, an expense (with a payer, an amount, and who it was shared between), and — the output — a transfer (one person pays another some amount). Three data types, straight from the language of the problem. That is the design lesson.

Money must be exact. The whole program is about amounts of money, so the expensive-mistake rule applies with full force: money is integer paise, never a Double. ₹9000.00 is 900000 paise. If you use floating point, the settlement will be off by fractions of a paisa and the "everyone is even" guarantee will quietly fail. This single decision shapes the whole model.

Absence is real. A person might be recorded but pay for nothing; an expense might be shared between everyone or just a few. The model must handle the empty and the partial honestly — the null-safety and collections modules, applied.

The settlement is a computation over collections. "Net balance per person" is a fold over the expenses; "who pays whom" is a transformation of those balances. No mutable-state-and-loops tangle — groupBy, sumOf, minByOrNull, maxByOrNull are the tools. That is the logic lesson.

It must be provably correct. "Everyone ends up even" is a claim you can test: the net balances must always sum to zero, an equal split must leave the payer owed exactly their outlay minus their share, and the transfers must match what is owed. That is the testing lesson, and it is where the capstone earns your trust.

What each lesson builds

• Design — the three data classes (Person, Expense, Transfer), and why each is shaped as it is: val properties, integer paise, a require that rejects a nonsensical expense, a computed sharePaise.
• Logic — netBalances (who is up, who is down) and settle (the greedy who-pays-whom algorithm), written with collection operations.
• CLI — a main that wires it together and prints a readable report, reading like Kotlin throughout.
• Testing — the test suite that proves the settlement is correct, including the failure paths, and the bug the tests catch.

By the end you will have a complete, tested, runnable Kotlin program in a proper Gradle project — exactly the shape of the work you will be handed as an intern, built to the standard the best-practices and design-patterns modules set.

The reference project

The finished code lives in a reference repository you can clone, build, and run — a real Gradle project with src/main/kotlin/splitter/ and a test suite. The lessons build it piece by piece; the repository is there to check your work against when you are stuck, exactly as a mentor's solution would be.

Your task before the next lesson

Do not skip this. Sketch the model yourself. What data classes would you create? What fields does each have, and what type — especially, how do you represent the money? Where would you put the rule "an expense's amount must be positive"? Write it down. Then read the design lesson and compare. The gaps between your sketch and the built version are precisely the things this course was teaching.

Check your work

What the program does. Records trip expenses (payer, amount, participants) and produces the shortest list of payments that settles everyone up.

The interesting core. Computing the net settlement — the minimum transfers — not a tangle of mutual debts.

The three nouns that become the model. Person, expense, and transfer.

The non-negotiable about money. Integer paise, never a Double — or the "everyone is even" guarantee silently fails.

What the settlement is, in collection terms. Net balances are a fold over expenses; who-pays-whom is a transformation of those balances.

Why it must be testable, and what to test. "Everyone ends up even" is checkable: balances sum to zero, equal splits are correct, transfers match what is owed.

What the four build lessons cover. Design (the data classes), logic (the settlement), CLI (the program), and testing (proving it).

Practice

1. Re-read the brief and underline every requirement. Separate the correctness ones (money exact, everyone even) from the feature ones (record expenses, print a report).
2. List the nouns and, for each, decide whether it is a thing (a data class) or a fact about a thing.
3. Decide how you will represent money, and write down why Double is wrong here.
4. Sketch the three data classes with their fields and types.
5. Decide where the rule "amount must be positive" belongs, and how you would enforce it.
6. Think about the settlement: if A paid ₹9000, B paid ₹3000, C paid ₹1500, all shared three ways, work out by hand who owes whom. You will check the program against this later.

Official documentation

• Kotlin — Data classes — The tool for the model.
• Kotlin — Collections overview — Where the settlement logic lives.
• Kotlin — Basic types: numbers — Why integer paise, not Double, for money.

Next: designing the model with data and sealed classes.