Check Your Understanding

The goal of these tasks isn't to guess a principle's name but to explain the cost of the chosen solution. State your answer first, then check the analysis.

Task 1. Two forms have the same phone check. The forms belong to different products, but the phone format is set by a single company rule. Should the repetition be removed? - Yes, knowledge is repeated here: if the format changes, both forms must change together. Extract the rule into one validator - that's meaningful DRY.

Task 2. You need to save an avatar locally. There's an assumption that cloud storage will appear in a year. Do you need a Storage interface, a factory, and three adapters right now? - Usually no. Isolate the write in one clear function or module: it leaves room for replacement but doesn't create nonexistent implementations. Here KISS and YAGNI work.

Task 3. A registration function creates a user, sends an email, writes an audit record, and formats an HTTP response. Which part do you separate first? - First separate the business scenario from the transport: the HTTP response isn't part of registration. Then move the external effects behind small contracts. The split is defined by reasons to change, not by line count.

There can be several right answers. What matters isn't a principle's name but the ability to name which risk the chosen solution reduces and at what cost. That's exactly what separates applying a principle from quoting it.

What remains is to sum up - and name the primary sources these six principles rest on.