Se tu avessi un collega che non capiva i vantaggi di Separation of Concerns, o non lo capisse abbastanza da applicarlo coerentemente nel loro lavoro quotidiano, come lo spiegheresti a loro?
Immagina di avere un programma che è stato rilasciato. Un cliente arriva e si offre di pagare per un miglioramento di una delle sue caratteristiche. Per ottenere i soldi, è necessario modificare il programma per aggiungere la nuova funzione. 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 nel fornire assistenza a un paziente: infermieri di triage, medici, assistenti medici, tecnici, impiegati, caffetteria, ecc.
C'è una sola persona che sa come tutti di quelle persone ottengono il 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 ogni membro dello staff in quell'ufficio e chiedigli, cosa succederebbe se questi dipendenti non fossero divisi in base al loro lavoro?
Vorrei vedere come ha fallito nell'applicare il SoC nel suo codice / design e trasformarlo in un esempio del mondo reale con cui possa relazionarsi e che è ovviamente indesiderato.
Per esempio, se ha una classe in cui il cliente ha bisogno di 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 il tuo lievito se voglio comprare un pane.
Un esempio potrebbe essere che uno sviluppatore HTML potrebbe voler separare html, css e javascript in file separati. In questo modo puoi cambiare l'aspetto di qualcosa dicendo 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 della finestra degli utenti o del programma utente. Tuttavia, se modifichi l'html o il modello, è probabile che il css o il javascript potrebbero rompersi. Queste preoccupazioni separate possono anche essere dipendenti.
Un altro approccio è quello di raggruppare tutti i tuoi css javascript e html in un gruppo di componenti o moduli. Ciò significa che è possibile apportare modifiche a un modulo e non dovrebbe influire su altri componenti o moduli sulla pagina che viene eseguita insieme a quelli non correlati. Qui i file css, js e html sono uniti in un singolo componente che può essere testato unitamente. Quindi la separazione delle preoccupazioni si presenta sotto forma di singoli componenti atomici che possono essere testati unitamente piuttosto che separare markup, elementi stilistici e comportamentali. Questo secondo approccio è più adatto alla creazione di applicazioni Web più complesse.
modifica. Dal momento che ho ricevuto una risposta negativa a questo commento ho pensato di rivisitarlo e provare a qualificare alcuni dei miei poveri. Sfortunatamente qualsiasi feedback qui non è particolarmente costruttivo, ma ho visto una discussione interessante altrove che esamina React, l'attuale tecnologia hot nello sviluppo web, un esempio reale del mondo, e chiede se interrompe la separazione delle preoccupazioni o, in particolare, se interrompe una delle il principio della metodologia di progettazione degli oggetti SOLID di Feather.
La prospettiva dello sviluppatore tecnico 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.
The Team Perspective
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.
Anche nella pagina c'è un collegamento a un'interessante presentazione di Pete Hunt, di Facebook, in cui parla di componenti non di modelli e separa le preoccupazioni nell'applicazione del linguaggio piuttosto che separare le preoccupazioni del framework, cioè i modelli, css e javascript ecc.
Per quanto riguarda la separazione delle tue preoccupazioni nella lingua della tua applicazione, ciò potrebbe implicare l'uso di vari modelli per separare o disaccoppiare il tuo codice in forma modulare che può essere testato unitariamente ecc.
Quindi, per riassumere, la separazione delle preoccupazioni può dipendere dal tuo ruolo o dal tuo punto di vista, come menzionato altrove.
Leggi altre domande sui tag object-oriented code-quality