Lesson 1 of 2 | Ownership, Ordering and Failure
Observer: Independent Notifications and Subscription Lifetimes
Start with the relationship
A sensor dashboard receives a new temperature reading. A chart redraws, a logger records the value, and an alert panel evaluates its own threshold. The source should not know each concrete screen. Observer fits when these reactions are independent and additional subscribers can join or leave. It is not a substitute for a sequence whose steps depend on one another.
Define the payload and lifetime
An example reading contains a sensor identifier, measurement time, numeric value and unit. Decide whether the timestamp means measurement time or receipt time. A value of 30 without a unit is not an adequate contract. Treat the payload as a fact, not a command to perform an unrelated business action.
In the .NET observable interfaces, subscription returns an IDisposable handle. The consumer should own that handle and dispose it when the screen closes. The observable contract does not specify observer notification order. These lifecycle and ordering points are documented in Microsoft Learn.
A useful lifecycle test is: open a screen, subscribe, receive one update, close the screen, publish another update, and confirm the closed screen does not react. Repeat opening and closing to catch duplicate subscriptions. A test that only verifies the first notification misses the common retention and duplicate-handler problems.
Separate the pattern from delivery guarantees
| Question | Decision to make |
|---|---|
| Must every sample be retained? | Choose storage or a durable delivery mechanism explicitly. |
| May a slow chart delay the producer? | State synchronous versus queued delivery and bounded-buffer behavior. |
| Does one handler failing affect others? | Define, observe and test failure propagation. |
| Must one subscriber run before another? | Move that dependency into an explicit workflow. |
Naming the design Observer does not answer these questions. A chart may legitimately show only the latest reading, whereas an audit recorder may require every accepted sample. Those requirements can justify different delivery paths rather than one overloaded event bus.
Worked design exercise
A chart needs the latest value, an audit log needs all accepted readings, and a billing operation must happen only after persistence. Should three interchangeable subscribers handle all three?
A stronger design persists the accepted reading under an explicit contract, then exposes the appropriate notifications. Billing is a dependent workflow step with duplicate protection, not an incidental subscriber whose position in a registration list happens to work. The chart can remain an independent observer. Document what happens if persistence succeeds but later notification fails.
Interview check
Explain one invariant, one lifetime boundary and one failure case before naming a library. If there is one fixed collaborator and no independent subscription need, a direct call can be clearer.
Continue with the coordinator lesson, then try the six-scenario workbook.