Se avessi un collega che non capiva i benefici della Separazione delle preoccupazioni o non lo capiva abbastanza da applicare coerentemente nel suo lavoro quotidiano, come glielo spiegheresti?
Risposte:
Immagina di avere un programma che è stato rilasciato. Un cliente arriva e si offre di pagarti per un miglioramento di una delle sue funzionalità. Per ottenere i soldi, dovrai cambiare il tuo programma per aggiungere la nuova funzionalità. Alcune delle cose che influenzeranno il tuo margine di profitto sono:
La separazione delle preoccupazioni ti aiuta a ottenere risposte più positive a queste domande.
Guarda un ospedale e pensa a tutti i diversi ruoli che sono coinvolti nella fornitura di cure a un paziente: infermieri di triage, medici, assistenti medici, tecnici, impiegati, mensa, ecc.
C'è una persona che sa come tutte quelle persone ottengono il loro lavoro? No, perché sarebbe travolgente. Devono separare le diverse responsabilità in ruoli distinti e i punti di contatto tra questi ruoli sono molto specifici.
Se lavora in un ufficio, prendilo come esempio, spiega il ruolo di ciascun personale in quell'ufficio e chiedigli, cosa accadrebbe se quel personale non fosse diviso in base al proprio lavoro?
Vorrei vedere come non è riuscito ad applicare il SoC nel suo codice / design e trasformarlo in un esempio del mondo reale con cui può relazionarsi e che è ovviamente indesiderato.
Ad esempio, se ha una classe in cui il cliente deve fornire diverse informazioni che non sono rilevanti per quei clienti, allora userei l'analogia di una panetteria in cui devi portare i tuoi cereali e lievito se vuoi acquistare un pane.
Un esempio potrebbe essere uno sviluppatore HTML che potrebbe voler separare HTML, CSS e JavaScript in file separati. In questo modo puoi cambiare l'aspetto di qualcosa da dire semplicemente modificando il CSS o il comportamento di qualcosa cambiando il file javascript che viene caricato separatamente. Se si dispone di un sito reattivo o adattivo, questo paradigma funziona bene in quanto è possibile caricare diversi CSS o JavaScript a seconda del viewport o dell'agente dell'utente. Tuttavia, se modifichi l'html o il modello, è probabile che il CSS o il JavaScript possano rompersi. Queste preoccupazioni separate possono anche dipendere.
Un altro approccio è quello di raggruppare tutti i tuoi CSS CSS e HTML in un gruppo di componenti o moduli. Ciò significa che è possibile apportare modifiche a un modulo e che non dovrebbe influire su altri componenti o moduli nella pagina che viene eseguito a fianco di quelli non correlati. Qui i file css, js e html vengono uniti in un singolo componente che può essere testato in unità. Quindi la separazione delle preoccupazioni si presenta sotto forma di singoli componenti atomici che possono essere testati in unità piuttosto che separazione di markup, stile ed elementi comportamentali. Questo secondo approccio è più adatto alla creazione di applicazioni Web più complesse.
modificare. Da quando ho ricevuto una risposta negativa a questo commento, ho pensato di rivederlo e provare a qualificare un po 'del mio pov. Sfortunatamente qualsiasi feedback qui non è particolarmente costruttivo, ma ho visto un'altra discussione interessante altrove che esamina React, l'attuale tecnologia calda nello sviluppo web, un esempio del mondo reale, e mi chiede se rompe la separazione delle preoccupazioni o in particolare se rompe uno dei i principi della metodologia di progettazione orientata agli oggetti SOLID di Feather.
La prospettiva tecnica dello sviluppatore JavaScript
NO, because JSX is a view language. That's one responsibility.
BUT, this implies that the JS developer is self-enforcing SoC/SRP on his own architecture by not mixing ViewModel concerns in his JSX. This type of vigilance "in the wild" is highly suspect because JSX involves the full JavaScript dialect.
La prospettiva del progettista UX / UI
YES, because JSX mixes Semantic Content (Model) with Behavior (Controller)
YES, because the intrusion, specifically of JavaScript, into the Semantic Model makes it difficult or impossible for me to play my role and leverage my expertese and skills.
La prospettiva della squadra
NO, if both...
Separate files are used for the View (JSX) and ViewModel (JS).
Either there aren't UI/UX/Designers involved, or they are productive working directly with JSX (not very common).
YES, if either...
Everything is in the same file, causing problems for version control or productive use of modern editors.
Members of the team who are comfortable with HTML/CSS but less capable with JavaScript are excluded because of mixture or roles.
Inoltre sulla pagina è presente un collegamento a un'interessante presentazione di Pete Hunt, di Facebook, in cui parla di componenti e non di modelli, e di separare le preoccupazioni nell'applicazione linguistica piuttosto che di separare le preoccupazioni del framework, ovvero modelli, css e javascript eccetera.
Per quanto riguarda la separazione delle preoccupazioni nella lingua dell'applicazione, ciò potrebbe comportare l'uso di vari schemi per separare o disaccoppiare il codice in una forma modulare che può essere testata in unità, ecc.
Quindi, per riassumere, separare le preoccupazioni può dipendere dal tuo ruolo o punto di vista, come menzionato altrove.