Observer: Refactor OrderService Notifications

The starter `OrderService` exposes `subscribe(OrderObserver)`, `unsubscribe(OrderObserver)`, and `markShipped(orderId)` but its internal notify loop is wrong. Instead of calling the uniform `observer.onOrderShipped(order)` method on each subscriber, it does an `instanceof` chain to discriminate between subscriber types and reaches into their internals to record the notification: ```java public Order markShipped(String orderId) { Order order = new Order(orderId); for (OrderObserver obs : observers) { if (obs instanceof EmailObserver) { ((EmailObserver) obs).getNotifiedOrders().add(order); } else if (obs instanceof SmsObserver) { ((SmsObserver) obs).getNotifiedOrders().add(order); } else if (obs instanceof AuditLogObserver) { ((AuditLogObserver) obs).getNotifiedOrders().add(order); } // any other observer type is silently dropped } return order; } ``` This is the wrong way to use the Observer pattern. The Subject is treating each subscriber's reference as a tag ("which kind of observer is this?") instead of as a delegate ("do your thing on this order"). The `onOrderShipped` method on each observer is stubbed and never called. Adding a new observer type means editing the `instanceof` chain, which is exactly what the pattern is supposed to make unnecessary. Refactor so that the notification logic lives on each observer and `OrderService.markShipped` becomes a uniform notify loop. After your refactor, the design must expose this exact public API: ```java class Order { public Order(String orderId); public String getOrderId(); } interface OrderObserver { void onOrderShipped(Order order); } class EmailObserver implements OrderObserver { public List<Order> getNotifiedOrders(); } class SmsObserver implements OrderObserver { public List<Order> getNotifiedOrders(); } class AuditLogObserver implements OrderObserver { public List<Order> getNotifiedOrders(); } class OrderService { public OrderService(); public void subscribe(OrderObserver observer); public void unsubscribe(OrderObserver observer); public Order markShipped(String orderId); // creates an Order, calls observer.onOrderShipped(order) on every subscriber, returns the order. // contains no instanceof. // wraps each notify call so that one observer's exception does not block the others. } ``` The `onOrderShipped` method on each concrete observer is empty in the starter. Move the recording logic (adding the order to `notifiedOrders`) into each `onOrderShipped`. Then replace the body of `markShipped` with a uniform loop that calls `observer.onOrderShipped(order)` on every subscriber, wrapped in a try/catch so a misbehaving observer does not block the others. The validator runs ten checks: 1. `new EmailObserver().onOrderShipped(order)` records the order. The recording logic must live in the observer. 2. `new SmsObserver().onOrderShipped(order)` records the order. 3. `new AuditLogObserver().onOrderShipped(order)` records the order. 4. A subscribed observer is notified when `markShipped` is called. 5. Two subscribed observers are both notified. 6. An observer that has been unsubscribed is not notified. 7. The validator subscribes its own brand-new `OrderObserver` (an `AnalyticsObserver` it defines internally) and asserts the service notifies it. Any `instanceof` chain on subscriber types fails this check. 8. If a subscribed observer throws on notification, the other subscribers are still notified. The notify loop must be exception-isolated. 9. `OrderService.markShipped` returns the same `Order` instance the observers were notified with. 10. The observers field on `OrderService` is declared as a collection of the `OrderObserver` interface (not a concrete observer class). The smelly starter passes only the constructor and field-type checks; it fails every behavioural check until the refactor is real.