One invoice class, three groups editing it

transcript

One invoice class. Three bosses. And every one of them edits the same file.

The class prices the invoice, with tax. It lays the invoice out as text. And it sends it by email, through whichever provider is set.

Finance changes the tax rate. Design changes the layout. Operations changes the mail provider. One class. Three reasons to change.

Here's the catch. A tax edit lives next to the layout. One typo, and the printout breaks. You can't test the tax alone. And finance and design collide in the same file, in the same week.

Split by who asks for changes. A tax rule for finance. A printer for design. A mailer for operations. The tax drops to 12 percent? One argument. Total 560.

Not one method per class. One reason to change. Name who would ask for a change. That is the seam. Then test each job alone, and swap the mailer for a fake.

Full breakdown in the lecture.