A Complete Answer in Five Minutes

Before any theory, here is a whole answer.

It is deliberately small. One screen of classes, one diagram, one page of code. The case studies later in the course are ten times this size, but they have the same structure. Read it once and the rest of the course is easier to follow.

You are not expected to understand the diagram notation yet. Look at the boxes and the lines. Chapter 2 explains every symbol in it.

The question

"Design a music playlist."

That is all the interviewer says. The first step is never to write code. The first step is to turn that sentence into a list you can design against.

Step 1: the requirements

Three questions to the interviewer produce three answers, and those three answers define the whole problem.

1. A playlist holds songs, and the order matters.
2. A user can play the next song, and the player remembers where it is.
3. A user can turn shuffle on, and the order changes.

Out of scope, agreed out loud: accounts, downloads, storage, and the audio itself. Saying what you are not building is worth as much as saying what you are.

Step 2: the actors

One actor, the listener, and three things they do: add a song, play the next one, turn shuffle on. On a question this small the step takes ten seconds. On a parking lot it takes three minutes and saves you ten minutes later, because the actors tell you which classes have to exist.

Step 3: the classes

Five classes and one interface. Each one gets a single sentence, and if the sentence needs the word "and", the class is probably two classes.

The third requirement is the one that decided this design. Without shuffle, Player could simply count upwards and there would be no PlayOrder at all. The rule for "what plays next" can vary, so it becomes its own type. The player then does not need to know which rule it holds.

Step 4: connect them

Three facts are worth taking from that picture, because they are the facts an interviewer checks.

• The filled diamond between Playlist and Song means the playlist owns its songs. The star means it owns many of them.
• The plain arrow from Player to PlayOrder means the player uses an order but does not own it. The arrow points at the interface, never at InOrder or Shuffled.
• The dashed arrows with the hollow triangles mean InOrder and Shuffled implement PlayOrder. Adding a third rule later adds one more box below them and changes nothing else.

Step 5: the code

Five short classes and the interface they share. Read the tab for the language you would use in the interview.

Now run it twice with two different orders.

The output:

in order:
  playing Sunrise by Ada Lane
  playing Blue Line by The Meridians
  playing Paper Boats by Nori Kim
  end of playlist
shuffled:
  playing Paper Boats by Nori Kim
  playing Sunrise by Ada Lane
  playing Blue Line by The Meridians
  end of playlist

Two behaviours, one Player, and no if statement anywhere that checks which mode is on.

What to notice

A requirement became a class. Shuffle was one line in the requirement list. It turned into an interface with two implementations. This is the normal direction in this round: requirements produce classes, not the other way round.

No class does two jobs. Song does not know it is in a playlist. Playlist does not know anything is playing. Player does not know how the next position is chosen. Each one can be described in a sentence without the word "and".

The design is open to a change you did not build. Repeat one song, and play an album in reverse, are two more classes that implement PlayOrder. Nothing already written has to be reopened.

We left things out on purpose. There is no pause, no volume, no queue, no time. Shuffled is given its order instead of generating one, so the lesson prints the same output every time you run it. In a real interview you would say that out loud rather than hope nobody asks.

That last habit is one of the most valuable in this round. Every case study in this course ends with a section called "What we left out" for the same reason.

Key Takeaways

• A complete answer is small: a short requirement list with a clear boundary, a few classes, one diagram, and code for the main flow.
• Requirements come first. Classes come out of requirements, and never the other way round.
• A rule that can vary becomes its own type, and the class that uses it does not need to know which version it holds.
• If a class responsibility needs the word "and", it is probably two classes.
• Naming what you did not build is part of the answer, not an admission of failure.

You have now seen the whole structure once. The rest of the course fills in the detail. Chapter 2 teaches the notation used in that diagram. Chapter 3 turns those five steps into a repeatable method, and chapter 4 applies it to twenty two real questions. The next lesson shows how to read a case study so that you learn from it, instead of only reading it.