it-swarm.it

Come spieghi agli altri la separazione delle preoccupazioni?

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?

37
Marcie

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:

  1. quanto codice devi cambiare
  2. quanto è facile apportare le modifiche
  3. quanto è probabile che si rompano le 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 determinato comportamento dell'applicazione è separato, dovrai solo modificare il codice direttamente associato alla tua nuova funzionalità. Quale dovrebbe essere meno codice da modificare.
  2. se i comportamenti che ti interessano sono nettamente separati dal resto dell'applicazione, è più probabile che tu sia in grado di scambiare una nuova implementazione senza dover comprendere completamente o manipolare il resto del programma. Dovrebbe anche essere più facile scoprire quale codice è necessario modificare.
  3. Il codice che non è necessario modificare ha meno probabilità di rompersi rispetto al codice che si modifica. 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 uno per caso mentre provi a cambiarne un altro.
  4. Se la tua architettura è indipendente dai dettagli tecnici o logici aziendali, è meno probabile che le modifiche all'implementazione richiedano nuove funzionalità architettoniche. Ad esempio, se la logica del dominio principale è indipendente dal database, supportare un nuovo database dovrebbe essere facile come scambiare una nuova implementazione del livello di persistenza.
53
flamingpenguin

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, personale d'ufficio, caffetteria, ecc.

C'è una persona che sa come tutte di 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.

10
RationalGeek

Se lui/lei lavora in un ufficio, prendilo come esempio, spiega il ruolo di ciascun personale in quell'ufficio e chiedigli, cosa succederebbe se quel personale non fosse diviso in base al suo lavoro?

5

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.