Exercise 3: Why a Centralized APIClient Is a Genuine Maintenance Win — Possible Solution =============================================================================================== If every individual ViewModel implemented its own version of status-code checking, decoding, and error handling directly, that same real logic - the 200..<300 success range check, the do/catch-wrapped JSONDecoder call, deciding which APIError case to throw for which real condition - would end up duplicated once per ViewModel that happens to need networking. This is a genuinely real maintenance cost: a fix or an improvement discovered later (like Exercise 2's own new .unauthorized handling) would need to be found and applied separately inside every single ViewModel's own copy of that logic, with a real, concrete risk that one or more copies get missed or updated inconsistently. Centralizing this logic inside one shared APIClient, with its own single generic fetch(...) function, means that exact kind of fix only ever needs to happen in ONE real place. Every ViewModel that calls apiClient.fetch(...) automatically benefits from any future improvement to that shared logic - a new error case, a smarter retry strategy, additional logging - without needing its own code touched at all. Connecting this directly to Chapter 1's own MVVM separation-of-concerns principle: that chapter's own real rule of thumb was that a ViewModel's job is holding and exposing STATE and screen-specific LOGIC for one screen - not literally how to construct and send an HTTP request. Networking mechanics genuinely belong to a distinct real layer of their own, sitting underneath every ViewModel rather than being reimplemented separately inside each one - the exact same kind of separation Chapter 1 already argued for between Model, View, and ViewModel, extended one layer further to cleanly separate "how to talk to the network" from "what this particular screen needs to show." ANSWER: A centralized APIClient means a fix or improvement to networking logic (status-code handling, error mapping, decoding) only needs to happen in one real place, rather than being duplicated and potentially updated inconsistently across every individual ViewModel. This extends Chapter 1's own MVVM separation-of-concerns principle one layer further - networking mechanics are their own distinct real concern, genuinely separate from a ViewModel's actual job of holding and exposing state and screen-specific logic for one particular screen. WHY THIS WORKS AS AN ANSWER ------------------------------ This identifies the concrete, real duplication risk a centralized APIClient avoids, and explicitly ties that architectural benefit back to the specific separation-of-concerns principle Chapter 1 already established for this course.