Hogyan magyarázza el az aggodalmak elkülönítését másoknak?

Képzelje el, hogy van programja amelyet kiadtak. Jön egy ügyfél, és felajánlja, hogy fizet az egyik szolgáltatásának fejlesztéséért. A pénz megszerzéséhez meg kell változtatnia a programot az új funkció hozzáadásához. Néhány dolog, amely befolyásolja a haszonkulcsát:

1. mennyi kódot kell megváltoztatnia
2. milyen egyszerű elvégezni a módosításokat
3. mennyire valószínű, hogy megtöri a más ügyfelek által használt meglévő szolgáltatásokat
4. mennyire tudja újból felhasználni a meglévő modellt / architektúrát

A gondok elkülönítése segít minél több pozitív választ kaphat ezekre a kérdésekre.

1. ha az alkalmazás egy adott viselkedésének összes kódja el van választva, akkor csak az új szolgáltatáshoz közvetlenül társított kódot kell megváltoztatnia. . Amelyiknek kevesebb kódot kellene megváltoztatnia.
2. ha az Önt érdeklő magatartásformák szépen el vannak választva az alkalmazás többi részétől, akkor valószínűbb, hogy képes lesz egy új megvalósítást cserélni anélkül, hogy teljesen meg kellene értenie vagy manipulálni a program többi részét. Könnyebbnek kell lennie annak kiderítésében is, hogy melyik kódot kell megváltoztatnia.
3. Az a kód, amelyet nem kell megváltoztatnia, kisebb valószínűséggel törik meg, mint a megváltoztatott kód. Tehát az aggodalmak felosztása segít elkerülni a nem kapcsolódó funkciók megrongálódását, megakadályozva azt, hogy módosítson olyan kódot, amelyet hívhatnak. Ha a funkciók összekeverednek, akkor véletlenül megváltoztathatja az egyik viselkedését, miközben megpróbál egy másikat megváltoztatni.
4. Ha az architektúrája agnosztikus a technikai vagy az üzleti logika szempontjából, akkor a megvalósítás módosítása kevésbé valószínű, hogy megköveteli új építészeti jellemzők. Például, ha a fő tartományi logikája adatbázis-agnosztikus, akkor az új adatbázis támogatásának ugyanolyan egyszerűnek kell lennie, mint a perzisztencia réteg új megvalósításának cseréjével.

Megjegyzések

• Szeretem, hogy a választ szilárdan rögzítette a pénzügyi valóságban. A vezetőknek nincs mentségük arra, hogy hanyag legyen, és figyelmen kívül hagyják ezt az alapvető koncepciót.

Nézzen meg egy kórházat, és gondoljon végig a páciens ellátásának különböző szerepein: triagia ápolók, orvosok, orvosi asszisztensek, technikusok, irodai személyzet, büfé stb.

Van olyan ember, aki tudja, hogyan ezeknek az embereknek minden nek elvégzik a munkáját? Nem, mert elsöprő lenne. Különböző szerepkörökre kell szétválasztaniuk a különböző felelősségeket, és a szerepek közötti érintési pontok nagyon specifikusak.

Ha ő irodában dolgozik, vegye példának, magyarázza el az egyes személyzet szerepét az irodában, és kérdezze meg tőle, mi történne, ha ezeket a személyzeteket nem osztanák meg munkájuk szerint?

Megnézném, hogyan nem alkalmazta a SoC-t a kódjában / kialakításában, és ezt egy valós példaértékűvé tenném, amellyel kapcsolatba léphet vele ez nyilvánvalóan nemkívánatos.

Például, ha van olyan osztálya, ahol az ügyfélnek több olyan információt kell megadnia, amely nem releváns az ügyfelek számára, akkor egy pékség analógiáját használnám, ahol Ön rendelkezik saját kenyeret és élesztőt hozni, ha kenyeret akar vásárolni.

Például lehet egy html fejlesztő külön akarja különválasztani a html-t, a css-t és a javascript-et te fájlokat. Így megváltoztathatja a mondat kinézetét és hangulatát, egyszerűen módosítva a css-t vagy valami viselkedését a külön betöltött javascript fájl megváltoztatásával. Ha van adaptív vagy adaptív webhelye, akkor ez a paradigma jól működik, és különböző cs-ket vagy javascripteket tölthet be a felhasználók nézetablakától vagy felhasználói ügynökétől függően. Ha azonban módosítja a html-t vagy a sablont, akkor valószínű, hogy a css vagy a javascript megszakadhat. Ezek a külön aggodalmak is függhetnek.

Egy másik megközelítés az, ha az összes cs javascriptet és html-t komponensek vagy modulok csoportjába csomagolja. Ez azt jelenti, hogy módosíthatja az egyik modult, és ez nem érinti az oldal többi összetevőjét vagy modulját, amelyek nem futnak egymás mellett. Itt a css, js és html fájlok egyetlen komponenssé egyesülnek, amely egységesen tesztelhető.Tehát az aggodalmak elkülönítése egyedi atomkomponensek formájában történik, amelyek egységesen tesztelhetők, nem pedig a jelölés, a stílus és a viselkedési elemek szétválasztása. Ez a második megközelítés alkalmasabb összetettebb webalkalmazások létrehozására.

szerkesztés. Mivel nemleges választ kaptam erre a megjegyzésre, azt gondoltam, hogy újra megvizsgálom, és megpróbálom minősíteni a pov-omat. Sajnos az itteni visszajelzések nem különösebben építő jellegűek, de láttam egy érdekes beszélgetést másutt, amely a React-et, a webfejlesztés aktuális forró technológiáját, a valós példát vizsgálja, és megkérdezi, hogy nem törik-e meg az aggodalmak szétválasztását, vagy különösen, ha az a “s of Feather” SZOLID objektum-orientált tervezési módszertan.

A JavaScript fejlesztői technikai perspektíva

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. 

Az UX / UI tervezői nézőpont

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. 

A csapat perspektívája

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

Az oldalon található egy link Pete Hunt (Facebook) érdekes bemutatójára is, ahol a sablonokról, nem pedig a sablonokról beszél, és a nyelvalkalmazásban szereplő aggályok elkülönítéséről. a keretrendszer aggályainak elkülönítése, pl. sablonok, css és javascript stb.

Ami az aggodalmakat az alkalmazás nyelvén különíti el, ez különféle minták használatával járhat a kód elkülönítéséhez vagy szétválasztásához moduláris formában amelyek egységesen tesztelhetők stb.

Összefoglalva tehát: az aggodalmak elkülönítése szerepétől vagy nézőpontjától függhet, amint azt máshol említettük.

Megjegyzések

• ez nem ‘ úgy tűnik, nem kínál semmit lényegeset az előzőekben kifejtett és kifejtett pontok felett. 7 válasz
• Csak arra hívom fel a figyelmet, hogy az aggodalmak elkülönítése a kontextustól függően eltérő megközelítést alkalmazhat. Ez közelebb áll a valós helyzetekhez a szoftvertervezés csövében, és kiemelem, hogy különböző megközelítéseket alkalmazhat, amikor html oldalakon dolgozik, és amelyek először ellentmondásosnak tűnhetnek.