The God Object That Is Two Objects

Decide what you would do from the brief alone, including whether you would change anything at all. Everything below it is available, but the exercise stops working if you open it first.

The brief you were given

ClinicScheduler is 1,900 lines and everyone on the team calls it the God object. You have a week to break it up.

The trap — the fix that looks like good design and is not

Splitting it by layer into SchedulerController, SchedulerService and SchedulerRepository. It is mechanical, every codebase already has a name for it, the 1,900 lines become three files of about six hundred, and the review is short because the shape is familiar. Both responsibilities are still present in all three: the cancellation-fee rule now lives partly in the service and partly in the repository query that decides which appointments are billable, so the change that used to touch one file touches three. A layered split divides code by *kind of code*; what makes this class hard to change is a mixture of *kinds of knowledge*, and those cut the other way.

Read this even if you are confident. It is here rather than behind a button because it is the answer most teams actually ship, it passes review, and the cost of it does not arrive until the change after this one.