better

La [separació d'interessos](https://en.wikipedia.org/wiki/Separation_of_concerns) (Separation of Concerns: SoC) ens diu que és millor que àrees de diferents funcionalitats tinguin poc solapament. La primera separació amb sentit seria que la sortida la gestionin les vistes i l'entrada els listeners. Però encara ens faltaria afegir l'aplicació en sí.

Per a interpretar els patrons a continuació utilitzarem tres tipus d'interaccions:

* **Comandes**: són peticions per a realitzar canvis. No esperen cap resposta.

* **Consultes** (queries): són peticions per a obtenir valors de l'estat. No realitzen cap canvi.

* **Notificacions**: són notificacions d'esdeveniments que han passat.

En relació a comandes i consultes, és important comentar el concepte de [Command-Query Separation](https://en.wikipedia.org/wiki/Command%E2%80%93query_separation). El que afirma és que cada mètode hauria de ser una ordre que realitzi una acció o una consulta que retorni dades al client, però no totes dues.

El criteris generals que segueixen tots els patrons són:

Els criteris generals que segueixen tots els patrons són:

* El Model no coneix (no depèn de) cap altre component del patró.

* La View és l'únic component que fa referència a aspectes visuals.

El primer patró que es va utilitzar és MVC (Model-View-Controller).

Aquest patró utilitza Model, View i Controller.

* **View**: rep notificacions de canvis al Model i notifica el Controller d'esdeveniments de la UI.

* **Controller**: rep notificacions d'esdeveniments a la View i envia comandes al Model i la View.

* **Model**: notifica la View i rep consultes seves. També rep comandes i consultes del Controller.

* **Controller**: rep esdeveniments de la View i envia comandes al Model.

* **Model**: notifica la View i rep consultes seves. També rep comandes del Controller.

![](../images/mvc.png)

El flux és:

1. View (esdeveniment)

2. Controller (comanda a Model)

3. Model (esdeveniment)

### MVP

Per tal de fer més testable per unitats cada part, apareix el patró MVP, on el Controller es substitueix pel Presenter. Aquest patró fa que totes les interaccions passin pel Presenter, i la View i el Model mai es comuniquen.

Per tal de fer més testable per unitats cada part, apareix el patró MVP, on el Controller es substitueix pel Presenter. Aquest patró fa que totes les interaccions passin pel Presenter, i la View i el Model no es comuniquin directament.

![](../images/mvp.png)

El flux és:

1. View (esdeveniment)

2. Presenter (comanda a Model)

3. Model (esdeveniment)

### MVVM

Aquest patró és similar al MVP, però substitueix el Presenter pel ViewModel. Utilitza la idea de data binding, on els canvis de les dades es transmeten fins a la View a partir del Model mitjançant el ViewModel.

Aquest patró és similar al MVP, però substitueix el Presenter pel ViewModel. Utilitza la idea de data binding o de flux reactiu d'estat, on els canvis de les dades es transmeten fins a la View a partir del Model mitjançant el ViewModel.

![](../images/mvvm.png)

El flux és:

1.  View (commanda a ViewModel)

1. View (comanda a ViewModel)

2. ViewModel (comanda a Model)

3. Model (esdeveniment)

4. ViewModel (esdeveniment)

5. La View s'actualitza

El patró MVVM s'adapta especialment bé al paradigma declaratiu, ja que el data binding o la subscripció a un estat observable permeten que la vista es regeneri automàticament a partir de l'estat.

### Ús actual dels patrons

Avui dia, més que parlar d'un patró únic dominant, convé dir que moltes UI modernes treballen amb una combinació de vista declarativa, estat observable i separació de la lògica de presentació. MVVM és una etiqueta molt habitual per descriure aquest enfocament, sobretot quan hi ha un model d'estat explícit.

* **Mòbil**: Jetpack Compose (Android) i SwiftUI (iOS) són declaratius i funcionen molt bé amb un model de state hoisting i vista reactiva. A Android, `ViewModel` i `StateFlow` s'utilitzen sovint per portar l'estat de la pantalla, però això és una elecció d'arquitectura més que no pas un mandat del framework.

* **Web frontend**: React, Vue i Angular són frameworks declaratius amb actualització reactiva de la UI. Es poden descriure amb vocabulari similar a MVVM en alguns projectes, però no tots encaixen de manera estricta en aquest patró.

* **Escriptori i multiplataforma**: WPF i molts projectes MAUI fan servir MVVM de manera molt natural. JavaFX té un sistema de propietats i data binding amb `javafx.beans` (`Property`, `ObservableValue`) que encaixa molt bé amb aquesta manera de treballar. Flutter és declaratiu i reactiu, però normalment es descriu més com a framework amb `Widget` tree i gestió d'estat que no pas com a MVVM pur.

MVC es manté vigent principalment en **frameworks web de servidor** (Ruby on Rails, Laravel, Spring MVC), on el cicle petició-resposta fa que la separació sigui més natural i no hi ha un binding de dades continu cap a la UI.

MVP ha quedat com a patró més aviat **llegat**, associat al desenvolupament Android clàssic (anterior a Jetpack Compose) i a aplicacions .NET amb WinForms o WebForms. En entorns moderns ha estat parcialment desplaçat per MVVM i per models declaratius de gestió d'estat.

## Construcció de la vista

A l'hora de construir l'arbre de vistes tenim dos paradigmes:

A l'hora de construir l'arbre de vistes tenim dos paradigmes. El paradigma declaratiu és el que millor s'integra amb patrons com MVVM:

* **Procedural**: el codi indica, pas a pas, com arribar a l'estat desitjat de l'arbre de vistes.

* **Declaratiu**: el codi representa directament l'arbre de vistes en funció de l'estat actual.