There Is No BookMyShow Class

Requirements are settled. The next step is turning them into an actual class diagram, and there are exactly two ways to get there.

Two Ways to Find the Classes in Any Design

The first is visualization: picture the system's physical structure, then picture a user moving through it. Both of those pictures hand you entities, which is exactly the technique the physical-structure walk in this series has been using all along.

The second is pulling nouns directly out of a written requirements document. A requirement like "users should be able to split an expense among friends and settle up later" hands you four candidate classes just by naming them: User, Expense, Friend, Settlement.

That technique earns its own full treatment later, once a case study actually starts from a requirements doc instead of a live conversation. For a system like BookMyShow, visualization is the tool that does the work.

One Test, Asked Against Every Candidate: Does It Actually Have Data to Store?

A class earns its place for exactly one reason: there's real data the system needs to hold about it. Not "it physically exists." Not "it sounds like an important part of the system." Data, specifically.

Take Game, from tic-tac-toe. It earns its place because the system has to store whose turn it is, who's winning, who's playing. Take that data away, and there'd be nothing left to justify a Game class at all.

That's the whole test, and it's about to knock out three tempting classes in this design, one after another: a Screen, BookMyShow itself, and Show. Same test, same failure, three separate times — none of them have any real data left over once you actually check.

Candidate One: A Screen

Walking the physical structure of a movie theatre, a natural instinct shows up: an auditorium has a screen, so shouldn't there be a Screen class?

No. A screen does have real features worth tracking, like IMAX or 3D support. But a movie booking platform doesn't need to model why a screen supports IMAX, only that a given auditorium does.

That's because an admin declares it directly, rather than the system inferring it from screen size or hardware. There's no data left over that only a Screen class could hold. Those features just live on the Auditorium (or on the Show running in it) instead.

The classes that belong in a design depend on what the system is for, not on cataloguing everything that physically exists. A movie booking platform and a cinema management system could describe the exact same building and still need entirely different classes:

1. A cinema management system might genuinely need a Screen class, tracking hardware, maintenance schedules, seating adjustments, because that data actually matters to what it does.
2. A booking platform doesn't, because none of it ever surfaces in a booking flow.

The same split shows up between a parking lot management system and a parking lot finder: identical physical parking lots, different use cases, different classes.

Candidate Two: BookMyShow Itself

Ask most candidates to sketch the top of a class diagram, and they'll draw a box named after the system itself. For BookMyShow, that produces a BookMyShow class sitting at the top, holding everything else underneath it.

That instinct is wrong, and the Screen test explains exactly why. The mistake usually comes from misreading a pattern that looked right in an earlier design:

1. A parking lot system's top class was ParkingLot, not ParkingLotManagementSystem. It holds real data: floors, gates, an address.
2. A tic-tac-toe game's top class was Game, not TicTacToe. It holds real data too: whose turn it is, who's winning, who's playing.

Neither class was named after the system. Both were named after a real entity the system needed data about.

Now run the same test on "BookMyShow" itself: is there anything you'd actually store about it? Not about a city, not about a theatre, about the platform as a concept. There isn't. Nothing in this system needs a row that says "here is a fact about BookMyShow." No data, no class, same as the screen.

Finding the Real Root: Walk Down Until Something Has Data

So what actually sits at the top? Walk the physical structure downward and stop at the first thing that passes the test.

ExpandNothing about the system itself needs storing, so the walk starts at City, the first real entity in the hierarchy

That's City. A city has a name, and everything else in the system (theatres, auditoriums, shows) exists inside one.

There's a nice real-world confirmation of this too. Open the actual BookMyShow app, and the very first thing it asks you to pick is a city, before anything else even loads.

Candidate Three: Show

One more tempting alternative: what if Show sits at the top instead, holding a list of the cities it's running in?

Same test, same outcome. A show is one movie, at one specific time, in one specific auditorium. It doesn't span multiple cities, a movie does, by having many different shows, each pinned to exactly one place.

"A list of cities" was never a true attribute of one show. This fails for the identical reason BookMyShow did: there's no data there to justify the class.

A Class That Does Something Isn't the Same as a Class That Stores Something

One distinction worth keeping separate from the test above: a class that assigns a user to a city, or drives the overall flow of the application, can absolutely exist. It just isn't a data entity the way City or Show is.

A behavioral class does things. An entity class stores things. Picture something like a BookingService: it takes a user's chosen city, routes them to the right theatres, calls the payment provider, updates seat status.

It does all of that without ever needing a city attribute on itself. It just passes the city along to whichever class actually stores it, because its job is coordinating behavior, not holding a record of facts.

The Same Test, One Level Down

The same question rules out plenty of smaller things too, not just entire classes. If an auditorium has some kind of restriction worth noting, that's an attribute on Auditorium, like a description field, not a reason to invent a new class, for the same reason Screen didn't need one.

Some details never make it into the model at all, however real they are:

1. Which bouncer is assigned to which auditorium matters to a security system, not a booking platform.
2. A user's Aadhaar number, or their parent's name, is a real fact about that person, and completely irrelevant to what a platform like this needs to store.

A class holds what its own system needs, not everything that happens to be true.