If I understand correctly, this means not to use a design pattern until it makes sense to do so, correct?
Sì.
Don't start off saying you're going to use the Strategy Pattern, wait until you write some code, and if using the Strategy Pattern makes sense for your design, then use it.
Sì. Tecnicamente, potresti capire che il modello strategico è appropriato prima ancora di scrivere qualsiasi codice, ma dovrebbe essere perché stavi pensando al problema reale e alla progettazione di una soluzione per quel problema, che presumo sia ciò che intendevi.
Do I treat the MCV/MVP pattern the same way when I create GUI applications? From the respective links, it says that it's an architectural pattern.
Sì, MVC / MVP / etc sono schemi architettonici. In un certo senso, questo non fa la differenza perché dovresti comunque usare MVC / MVP / etc solo quando hanno senso; quando è una misura ragionevole per il problema reale che stai cercando di risolvere. Dove fa la differenza è che, poiché si applica a un livello molto più alto rispetto, ad esempio, al modello di strategia, di solito capirai se ha senso o meno e decidere se lo userai come parte di il tuo lavoro di progettazione, prima di scrivere un sacco di codice.
Ricorda inoltre che "MVC / MVP" non è un singolo modello, ma una famiglia molto vasta di pattern correlati, e non c'è consenso su ciò che conta esattamente come "MVC" o "MVP" o "MVVM" o il resto della zuppa alfabetica associata.
Suppose if I create a GUI application and I don't use the MCV/MVP pattern, but my code is clean, readable, and maintainable, is it still a code smell/bad design that I didn't use the MCV/MVP pattern?
Niente affatto, perché MVC / MVP / etc non sono corretti per ogni applicazione GUI. Ad esempio, alcune GUI potrebbero essere così semplici da risultare eccessive, o alcune GUI potrebbero non avere nessuno stato persistente da inserire in un "modello", ecc. Ci sono buone ragioni per cui questa famiglia di modelli è così popolare, ma 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 manutenibile", senza eccezioni, quindi quasi per definizione non si hanno 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 pattern MVC / MVP?", direi: leggi di perché quei pattern sono così popolari, cioè quali problemi hanno " stai cercando di risolvere, in modo che in futuro tu possa capire se il tuo ultimo problema potrebbe essere risolto da quei modelli.