Ho riflettuto per un po 'sui motivi che impediscono a molti programmatori - io stesso prima di tutto - di scrivere codice pulito, modulare ed espressivo sviluppando, ad esempio, le app CocoaTouch.
Quello che ho scoperto è che i miei tre migliori tre motivi stanno seguendo:
- Codice UI. UI / UX specifiche del dispositivo, confusione generale, "soluzioni rapide e soluzioni alternative" e così via.
- Scadente controller - Visualizza disaccoppiamento. A volte il controller termina il processo di cui è responsabile la visualizzazione.
- Cablaggio di test sparse.
Naturalmente, questi problemi derivano dalla mancanza di disciplina o abitudine a scrivere codice pulito. Ma è difficile disciplinare te stesso se l'ambiente ti permette di non farlo .
È facile smistare il bucato se hai una serie di cassetti dedicati, ma se hai un cassetto, si trasformerà lentamente in disordine, a meno che tu non sia molto disciplinato.
E poi ho provato ad applicare l'idea di 'ordinare i cassetti' per risolvere i miei problemi di codice - e ho pensato che fosse possibile ordinare i componenti MVP come segue:
- Il modello è in realtà un quadro di classi responsabili della gestione dei dati. Il modello è riutilizzabile, in quanto è un insieme di routine per lavorare con i dati.
- Visualizza è in realtà un quadro di classi responsabili della presentazione delle informazioni graficamente. Non dipende molto da che sull'ambiente e può essere sicuramente riutilizzato.
- Controller è un framework di classi responsabili del coordinamento dei livelli sopra menzionati e che lavorano con i percorsi di interazione dell'utente. L'applicazione stessa è qualcosa come (?) Un grande controller. Poiché unisce insieme un insieme definito di modelli a un insieme definito di viste, non è riutilizzabile e dipende pesantemente da quelle + piattaforme ecc.
Quindi dato che M e V sono in qualche modo riusabili, e C non lo è - forse ha senso forzare la separazione di M e V? Il modo migliore per assicurarsi che siano separati consiste nel metterli in librerie statiche. Successivamente, possono essere collegati all'app, che contiene solo il codice del controller.
Questo approccio mi sembra abbastanza buono perché:
- solo il controller dipende da qualcosa qui
- lo sviluppatore può scrivere suite di test separate per quei moduli
- le classi di interfaccia utente possono essere riutilizzate facilmente in altre app Le classi di modelli
- possono essere estratte in codebase multipiattaforma mantenendo la vecchia facciata I commit
- sono limitati a tre moduli realmente distinti: cosa c'è di più distinto di una libreria separata?
Che ne pensi? Suona come un'idea da seguire?