In MVP (Model-View-Presenter), how does the Presenter's relationship with the View differ from the Controller's relationship with the View in classic MVC, and what problem does that difference solve?

## Where the wiring lives MVP (Model-View-Presenter) emerged as a refinement of MVC aimed squarely at **testability**, and the clearest way to see the difference is to trace where the 'View reads Model state' wiring lives. In classic MVC, the View is typically permitted to observe the Model directly — it registers for change notifications, pulls the current state, and redraws itself; the Controller's job is mostly to translate input events into Model mutations. That means a meaningful chunk of 'what shows on screen given this state' logic can live inside the View itself, tangled up with actual rendering code. ## What MVP changes MVP severs that link entirely. - **The View** in MVP is treated as a passive, nearly logic-free implementation of a narrow interface — commonly literally an interface/protocol type, e.g. an interface with methods like `showError(msg)` and `setLoadingVisible(visible)`. It forwards raw input events (button clicks, text changes) to the Presenter, and does nothing else with them — no interpretation, no validation, no reading the Model. - **The Presenter** is the one object that knows about both the View interface and the Model: it receives the forwarded event, invokes Model operations, and then explicitly calls methods on the View interface to push the exact, already-formatted result. There is no implicit observation or binding — every View update is an explicit, traceable method call initiated by the Presenter. ## Why the pattern exists The reason this exists is unit-testability of interaction logic, not just business logic. MVC already lets you test the Model without a UI, but the coordination logic — which error message to show for which failure, what order calls happen in, when to show a spinner — typically lived in the View or Controller and required a real UI to exercise. By reducing the View to a pure interface, MVP lets a test double implement that interface trivially, and the test asserts on which interface methods the Presenter called and with what arguments, with zero real UI framework in the test process. This mattered enormously on platforms where instantiating the real View was slow or impossible outside a running app. The classic examples: - **early Android**, where Activities/Fragments are heavyweight and hard to unit test without an emulator (which is exactly why early Android architecture guidance pushed MVP); - **WinForms/Swing desktop apps**, where MVP (an idea articulated at Taligent and popularized further by Martin Fowler's 'Passive View' and 'Supervising Controller' variants) let teams test dialog and form logic headlessly. ## The cost The trade-off is verbosity and manual wiring. Every piece of state the View needs to display requires an explicit interface method and an explicit Presenter call — there's no framework mechanism that keeps View and Model in sync automatically. For a screen with twenty fields, that's twenty methods on the View interface and twenty corresponding calls scattered through the Presenter, which is a lot of boilerplate compared to a data-binding approach. It also means the Presenter must remember to call every relevant View method any time related state changes, which is a manual synchronization burden a human can get wrong. ## Failure modes The dominant failure mode is analogous to MVC's fat Controller: - a **'fat Presenter'** that accumulates so many View-interface methods and so much sequencing logic that it becomes its own untestable monolith, especially once conditional branches multiply. Because the Presenter is the sole owner of all View-update sequencing, it tends to grow unboundedly on screens with many states. - a second common failure, **Presenters that quietly start referencing platform/UI types anyway**, which reintroduces the untestability MVP was adopted to remove. ## A concrete example A concrete real-world example: Google's official Android Architecture Guide, roughly 2016-2018, recommended MVP as the pattern for testable Android apps precisely because Activity/Fragment classes couldn't be constructed in a plain JVM unit test — a mock View interface let Presenter logic be tested with fast, JVM-only unit tests instead of slow instrumented device tests. Android's later move toward MVVM via Architecture Components' LiveData/ViewModel was driven by wanting to eliminate exactly the boilerplate described above by letting the View auto-observe state instead of the Presenter manually pushing it.