Se capisco correttamente, questo significa non utilizzare un modello di progettazione fino a quando non ha senso farlo, giusto?
Sì.
Non iniziare dicendo che stai per utilizzare il modello di strategia, attendi fino a quando non scrivi un codice e se l'uso del modello di strategia ha senso per il tuo design, quindi usalo.
Sì. Tecnicamente, potresti capire che il modello di strategia è appropriato prima ancora di scrivere qualsiasi codice, ma questo dovrebbe essere perché stavi pensando al problema reale e progettando una soluzione per quel problema, che presumo sia ciò che intendevi.
Tratto il modello MCV / MVP allo stesso modo quando creo applicazioni GUI? Dai rispettivi collegamenti, si dice che è un modello architettonico.
Sì, MVC / MVP / etc sono modelli architettonici. In un certo senso, ciò non fa differenza perché dovresti usare MVC / MVP / etc solo quando hanno senso; quando si adatta perfettamente al problema reale che stai cercando di risolvere. Il punto in cui fa la differenza è che, poiché si applica a un livello molto più elevato rispetto, per esempio, al modello di strategia, in genere capirai se ha senso o meno e deciderai se lo userai come parte di il tuo lavoro di progettazione, prima di scrivere molto codice.
Inoltre, tieni presente che "MVC / MVP" non è un singolo modello, ma una famiglia enorme di modelli correlati e non vi è consenso su ciò che conta esattamente come "MVC" o "MVP" o "MVVM" o il resto del zuppa di alfabeto associata.
Supponiamo che se creo un'applicazione GUI e non utilizzo il pattern MCV / MVP, ma il mio codice è pulito, leggibile e gestibile, è ancora un odore di codice / cattiva progettazione che non ho usato il pattern MCV / MVP ?
Niente affatto, perché MVC / MVP / etc non sono adatti a tutte le applicazioni GUI. Ad esempio, alcune GUI potrebbero essere così semplici da essere eccessivamente complete, oppure alcune GUI potrebbero non avere uno stato persistente da inserire in un "modello", ecc. Vi sono buone ragioni per cui quella famiglia di schemi è così popolare, ma loro non sono gli unici modi per scrivere un buon software GUI.
Inoltre, un "odore di codice" di solito significa qualcosa su uno specifico frammento di codice che potrebbe essere un sintomo di un problema più grande. Se tutto il tuo codice è "pulito, leggibile e gestibile", senza eccezioni, quasi per definizione non hai odori di codice (tranne forse alcuni odori di codice "falso positivo" che non indicano alcun problema reale ).
Quindi, per rispondere al titolo della tua domanda: "Come trattare il modello MVC / MVP?", Direi: vai a leggere perché questi modelli sono così popolari, cioè quali problemi stanno cercando di risolvere, in modo che in futuro puoi dire se il tuo ultimo problema potrebbe essere risolto da questi schemi.