Come spieghi Separazione delle preoccupazioni agli altri?

27

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?

    
posta Marcie 30.12.2010 - 13:18
fonte

5 risposte

36

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:

  1. quanto codice devi modificare
  2. quanto è facile apportare le modifiche
  3. la probabilità di violazione delle funzionalità esistenti utilizzate da altri clienti
  4. quanto puoi riutilizzare il tuo modello / architettura esistente

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

  1. se tutto il codice per un particolare comportamento dell'applicazione è separato, sarà sufficiente modificare il codice direttamente associato alla nuova funzione. Quale dovrebbe essere meno codice da cambiare.
  2. se i comportamenti che ti interessano sono nettamente separati dal resto dell'applicazione, è più probabile che tu possa passare a una nuova implementazione senza dover comprendere o manipolare completamente il resto del programma. Dovrebbe anche essere più facile scoprire quale codice è necessario modificare.
  3. Il codice che non è necessario modificare è meno probabile che si interrompa rispetto al codice che si modifica. Quindi, separare 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 insieme, potresti cambiare il comportamento di una per errore mentre provi a cambiarne un'altra.
  4. Se la tua architettura è indipendente dai dettagli tecnici o di business logic, le modifiche all'implementazione richiedono meno nuove funzionalità architettoniche. Ad esempio, se la logica del dominio principale è indipendente dal database, il supporto di un nuovo database dovrebbe essere semplice come passare da una nuova implementazione del livello di persistenza.
risposta data 30.12.2010 - 15:38
fonte
8

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.

    
risposta data 30.12.2010 - 14:26
fonte
5

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?

    
risposta data 30.12.2010 - 13:48
fonte
0

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.

    
risposta data 30.12.2010 - 15:22
fonte
-3

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.

link

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.

    
risposta data 20.01.2017 - 21:56
fonte

Leggi altre domande sui tag