Cum explicați separarea preocupărilor altora?

Imaginați-vă că aveți un program care a fost eliberat. Un client vine și vă oferă să vă plătească pentru o îmbunătățire a uneia dintre caracteristicile sale. Pentru a obține banii, va trebui să vă schimbați programul pentru a adăuga noua funcție. Unele dintre lucrurile care vor influența marja de profit sunt:

1. cât de mult cod trebuie să modificați
2. cât de ușor este să faceți modificările
3. cât de probabil sunteți de a sparge funcțiile existente care sunt utilizate de alți clienți
4. cât de mult vă puteți reutiliza modelul / arhitectura existentă

Separarea preocupărilor ajută veți obține răspunsuri mai pozitive la aceste întrebări.

1. dacă tot codul pentru un anumit comportament al aplicației este separat, atunci va trebui să schimbați codul direct asociat cu noua dvs. caracteristică . Care ar trebui să fie mai puțin cod de modificat.
2. dacă comportamentele care vă interesează sunt separate separat de restul aplicației, este mai probabil să puteți schimba o nouă implementare fără a fi nevoie să înțelegeți pe deplin sau manipulați restul programului. De asemenea, ar trebui să fie mai ușor să aflați codul pe care trebuie să îl modificați.
3. Codul pe care nu trebuie să îl modificați este mai puțin probabil să se rupă decât codul pe care îl modificați. Așadar, împărțirea preocupărilor vă ajută să evitați ruperea funcțiilor care nu au legătură, împiedicându-vă să schimbați codul pe care l-ar putea apela. Dacă caracteristicile dvs. sunt amestecate, ați putea schimba comportamentul uneia din întâmplare în timp ce încercați să schimbați alta.
4. Dacă arhitectura dvs. este agnostică până la detaliile logicii tehnice sau de afaceri, atunci este mai puțin probabil ca modificările la implementare noi caracteristici arhitecturale. De exemplu, dacă logica principală a domeniului dvs. este baza de date agnostică, atunci acceptarea unei noi baze de date ar trebui să fie la fel de ușoară ca schimbarea într-o nouă implementare a stratului de persistență.

Comentarii

• Îmi place că ați răspuns bine ancorat în realitatea financiară. Managerii nu au nicio scuză pentru a fi neglijent și ignoră acest concept fundamental.

Uită-te la un spital și gândiți-vă la toate rolurile diferite care sunt implicate în acordarea îngrijirii unui pacient: asistente medicale de triaj, medici, asistenți medicali, tehnicieni, personal de birou, cafenea etc.

Există o persoană care știe cum toți acei oameni își fac treaba? Nu, pentru că ar fi copleșitor. Ei trebuie să separe diferitele responsabilități în roluri distincte, iar punctele de contact dintre aceste roluri sunt foarte specifice.

Dacă el / lucrează într-un birou, îl ia ca exemplu, explică rolul fiecărui personal din acel birou și îl întreabă, ce s-ar întâmpla dacă acești personal nu sunt împărțiți în funcție de slujbele lor?

M-aș uita la modul în care nu a reușit să aplice SoC în codul / designul său și să-l transform într-un exemplu din lumea reală cu care se poate relaționa și acest lucru este în mod evident nedorit.

De exemplu, dacă are o clasă în care clientul trebuie să furnizeze mai multe informații care nu sunt relevante pentru acei clienți, atunci aș folosi analogia unei brutării în care aveți să-ți aduci propriile boabe și drojdie dacă vrei să cumperi o pâine.

Un exemplu ar putea fi un dezvoltator html doriți să separați html, css și javascript în separa fișierele te. În acest fel puteți schimba aspectul a ceva de spus prin simpla modificare a css-ului sau a comportamentului a ceva prin schimbarea fișierului javascript care este încărcat separat. Dacă aveți un site adaptabil sau adaptabil, această paradigmă funcționează bine, deoarece puteți încărca css sau javascript diferite, în funcție de fereastra utilizatorului sau de agentul utilizatorului. Cu toate acestea, dacă modificați html sau șablonul, este posibil ca fie css-ul, fie javascriptul să se poată rupe. Aceste preocupări separate pot fi, de asemenea, dependente.

O altă abordare este de a grupa toate css javascript și html într-un grup de componente sau module. Acest lucru înseamnă că puteți face modificări la un modul și nu ar trebui să afecteze alte componente sau module de pe pagina pe care rulează de-a lungul căruia nu sunt legate. Aici fișierele css, js și html sunt îmbinate într-o singură componentă care poate fi testată pe unitate.Deci, separarea preocupărilor vine sub forma unor componente atomice individuale care pot fi testate unitar, mai degrabă decât separarea elementelor de marcare, stilizare și comportament. Această a doua abordare este mai potrivită pentru crearea de aplicații web mai complexe.

editați. Deoarece am primit un răspuns negativ la acest comentariu, m-am gândit să îl revăd și să încerc să calific o parte din pov. Din păcate, orice feedback aici nu este deosebit de constructiv, dar am văzut o discuție interesantă în altă parte care privește React, tehnologia actuală actuală în dezvoltarea web, un exemplu real, și întreabă dacă rupe separarea preocupărilor sau, în special, dacă rupe una dintre principiul „s of Feather” metodă de proiectare SOLID obiect orientare.

Perspectiva tehnică a dezvoltatorului 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. 

Perspectiva UX / UI Designer

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. 

Perspectiva echipei

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

De asemenea, pe pagină este un link către o prezentare interesantă de la Pete Hunt, de pe Facebook, unde vorbește despre componente, nu șabloane, și despre separarea preocupărilor în aplicația lingvistică, mai degrabă decât separarea preocupărilor cadrului, adică șabloane, css și javascript etc.

În ceea ce privește separarea preocupărilor dvs. în limba aplicației dvs., acest lucru ar putea implica utilizarea diferitelor modele pentru a separa sau decupla codul dvs. în formă modulară care poate fi testat în unitate etc.

Deci, pentru a rezuma, separarea preocupărilor poate depinde de rolul sau punctul dvs. de vedere, așa cum am menționat în altă parte.

Comentarii

• acest lucru nu ‘ nu pare să ofere nimic substanțial asupra punctelor făcute și explicate anterior 7 răspunsuri
• Doar subliniez că separarea preocupărilor poate adopta abordări diferite în funcție de context. Acest lucru este mai aproape de o situație reală în domeniile ingineriei software și subliniez că există diferite abordări pe care le puteți lua atunci când lucrați la pagini html care la început pot părea contradictorii.