Course 1.1Lesson 5 of 5

Project: a library system

In this project we build a library system with two classes. A Book knows its title and author and who has it, and a Library keeps a list of books and a log, and can add a book, find a book by title ignoring capitals, lend a book to a person, take it back, and list the books that are available. The rules live inside the classes: a book that does not exist, a book that is already out and a return of a book that is not out are refused with a ValueError. We plan the classes and a table of expected states, build the program, test the refused actions, and extend the library with due dates and a limit on the books of a person.

about 25 min1 simulation2 practice questions

Lesson 5 of 5Show all lessons

Try the code and the simulations beside the lesson.

What you will be able to do

After this lesson you can

design a program as a few classes that work together,
let one class hold and manage objects of another,
keep the rules inside the classes, and
test a system by following its state.

The goal

A small library lends books. It must know which books it has, who has borrowed each one, and a record of what happened. It must refuse the actions that make no sense: to borrow a book that does not exist, to borrow a book that is already out, and to return a book that is not out.

Step 1: find the classes

A good way to find the classes: look for the nouns of the description, and ask what each one knows and does.

Noun	It knows	It does
`Book`	its title, its author, who has it	says whether it is available
`Library`	its list of books, the log	adds a book, finds a book, lends, takes back, lists the available

The person is just a name here, a text. It does not need a class yet. (You could make one later, if a person must have a limit or an address.)

Step 2: the expected states

Work out what should happen, before you write any code. The library has Dune, Emma and Ulysses. Six actions are run.

Action	Result	Who has what
Asha borrows `dune`	ok (capitals do not matter)	Asha has Dune
Ravi borrows `Dune`	refused: Dune is with Asha	no change
Meera borrows `Hamlet`	refused: no such book	no change
give back `Dune`	ok	nobody has it
give back `Dune` again	refused: the book is not out	no change
Ravi borrows `Emma`	ok	Ravi has Emma

At the end the available books are Dune and Ulysses.

Step 3: the program

Run it, and compare each line with the table.

Look at the design.

- Book is small. borrower is None when nobody has the book, and the method is_available turns that into a clear question. The code that reads book.is_available() is easier to read than book.borrower is None.

- Library holds a list of Book objects: one class that manages objects of another. self.books is made inside __init__, so each library has its own list, with no shared default.

- find loops over the books and compares the titles in small letters. It returns the object, or None. This is the search pattern from the course on searching.

- borrow checks the rules in order: the book exists, the book is free. Only then does it change the state. After a refusal, nothing has changed.

- give_back refuses when the book does not exist or is not out, then writes the log, and then clears borrower. It writes the log before it clears the borrower, because the log needs the name.

- available returns a sorted list of titles, made with a generator expression.

- The main program catches the ValueError from the library, and prints a message. The library raises, and the caller decides: the pattern of the course on errors.

Step 4: test the refused actions

The row of the table that matters most is "no change". After a refused action, the state must be exactly as it was. Add to your test:

Test	Expected
borrow a book that is out	refused, and the borrower is unchanged
return a book twice	the second is refused, and the log has one return
a library with no books	`available()` gives `[]`, and every borrow is refused
two libraries	adding a book to one does not add it to the other

The last row tests the shared default trap. It would fail if self.books were a default list.

Every method checks its rule first and changes the state last, so a refused call never leaves a half-made change.

Extend it

Pick one or two, and do them without looking at a solution. Write the expected states first.

A limit. A person may have at most 2 books. A new method books_of(person) helps.
A count. Library.count_out() gives the number of books that are out.
Due dates. A book borrowed on a day is due 14 days later. Use the datetime module.
Search by author. by_author(name) gives the titles.
A Member class. A member has a name, a list of the books that the member holds, and a limit.

Common mistakes

One big class that does everything. Two small classes, each with a clear job, are easier to follow.
Changing the state and then checking. Check first.
A shared default list in Library.__init__.
Comparing titles with capitals. Use lower() on both.
Clearing borrower before the log is written.

Practice

Start with two quick questions. Each New numbers gives you a fresh one, so you can practise as long as you like.

Then the labs and the problems:

Warm-up. Open the lab Project: the library system. The checker runs your classes on a script of actions, including refused ones.
Build. Do Step 4 for one extension, and add rows to the table.
Stretch. Open the lab Bank account again, and compare its design with the library: where do you see the same ideas?