Come spieghi agli altri la Separazione delle preoccupazioni?

Immagina di avere un programma che è stato rilasciato. Un cliente arriva e si offre di pagarti per un miglioramento di una delle sue caratteristiche. Per ottenere i soldi, dovrai modificare il programma per aggiungere la nuova funzionalità. Alcune delle cose che influenzeranno il tuo margine di profitto sono:

1. quanto codice devi cambiare
2. quanto è facile apportare le modifiche
3. quanto è probabile che tu rompa le funzionalità esistenti che vengono utilizzate da altri clienti
4. quanto puoi riutilizzare il tuo modello / architettura esistente

La separazione delle preoccupazioni aiuta per ottenere risposte più positive a queste domande.

1. se tutto il codice per un particolare comportamento dellapplicazione è separato, allora dovrai solo modificare il codice direttamente associato alla tua nuova funzionalità . Che dovrebbe essere meno codice da modificare.
2. se i comportamenti che ti interessano sono nettamente separati dal resto dellapplicazione è più probabile che sarai in grado di scambiare una nuova implementazione senza dover comprendere appieno o manipolare il resto del programma. Dovrebbe anche essere più facile scoprire quale codice è necessario modificare.
3. È meno probabile che il codice che non devi modificare si rompa rispetto al codice che modifichi. Quindi suddividere le preoccupazioni ti aiuta a evitare la rottura di funzionalità non correlate impedendoti di dover modificare il codice che potrebbero chiamare. Se le tue funzionalità sono confuse, potresti cambiare il comportamento di una per sbaglio mentre provi a cambiarne unaltra.
4. Se la tua architettura è indipendente dai dettagli tecnici o di logica aziendale, è meno probabile che le modifiche allimplementazione richiedano nuove caratteristiche architettoniche. Ad esempio, se la logica del dominio principale è indipendente dal database, supportare un nuovo database dovrebbe essere facile come lo scambio in una nuova implementazione del livello di persistenza.

Commenti

• Mi piace che tu abbia reso la risposta saldamente ancorata alla realtà finanziaria. I manager non hanno scuse per essere sciatti e ignorare questo concetto fondamentale.

Guarda un ospedale e pensa a tutti i diversi ruoli coinvolti nel fornire assistenza a un paziente: infermieri, medici, assistenti medici, tecnici, personale impiegatizio, mensa, ecc.

Cè qualcuno che sa come tutte quelle persone portano a termine 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 lui / lei lavora in un ufficio, prendilo come esempio, spiega il ruolo di ogni personale in quellufficio e chiedigli, cosa succederebbe, se quel personale non fosse diviso in base al loro lavoro?

Vorrei vedere come non è riuscito ad applicare SoC nel suo codice / progetto e trasformarlo in un esempio del mondo reale con cui può relazionarsi e questo è 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 lanalogia di una panetteria in cui hai per portare i tuoi cereali e il lievito se vuoi comprare un pane.

Un esempio potrebbe essere uno sviluppatore HTML potrebbe vuoi separare html, css e javascript in separa te file. In questo modo puoi cambiare laspetto di qualcosa di detto semplicemente modificando il css o il comportamento di qualcosa cambiando il file javascript che viene caricato separatamente. Se hai un sito reattivo o adattivo, questo paradigma funziona bene in quanto puoi caricare css o javascript diversi a seconda del viewport degli utenti o dellagente utente. Tuttavia, se modifichi lhtml o il modello, è probabile che il css o il javascript non funzionino. Queste preoccupazioni separate possono anche essere dipendenti.

Un altro approccio consiste nel 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 corre lungo il lato non correlati. Qui i file css, js e html vengono uniti in un unico 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 e elementi comportamentali. Questo secondo approccio è più adatto alla creazione di applicazioni web più complesse.

edit. Dato che ho ricevuto una risposta negativa a questo commento, ho pensato di rivisitarlo e provare a qualificare alcuni dei miei pov. Sfortunatamente qualsiasi feedback qui non è particolarmente costruttivo, ma ho visto una discussione interessante altrove che guarda a React, lattuale tecnologia calda nello sviluppo web, un esempio del mondo reale, e chiede se rompe la separazione delle preoccupazioni o in particolare se rompe una delle i principi della metodologia di progettazione SOLID orientata agli oggetti di Feather.

La prospettiva dello sviluppatore JavaScript tecnico

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 designer 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 del team

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. 

https://hashnode.com/post/does-react-really-violate-separation-of-concern-by-putting-html-and-js-in-a-single-file-cil3bn5hj0011a65347rsdut0

Anche sulla pagina cè un collegamento a uninteressante presentazione di Pete Hunt, di Facebook, in cui parla di componenti non di modelli e separa le preoccupazioni nellapplicazione del linguaggio piuttosto che separare le preoccupazioni dal framework, ad esempio modelli, css e javascript ecc.

Per quanto riguarda la separazione delle tue preoccupazioni nella lingua della tua applicazione questo potrebbe comportare luso di vari schemi per separare o disaccoppiare il tuo codice in una forma modulare che può essere testato insieme ecc.

Quindi, per riassumere, separare le preoccupazioni può dipendere dal tuo ruolo o punto di vista, come menzionato altrove.

Commenti

• questo ‘ non sembra offrire qualcosa di sostanziale rispetto ai punti fatti e spiegati in precedenza 7 risposte
• Sto solo sottolineando che separare le preoccupazioni può richiedere approcci diversi a seconda del contesto. Questo è più vicino a una situazione del mondo reale nel campo dellingegneria del software e sto evidenziando che ci sono diversi approcci che puoi adottare quando lavori su pagine html che a prima vista possono sembrare contraddittori.