Hoe leg je Separation of Concerns uit aan anderen?

Stel je voor dat je een programma hebt die is vrijgegeven. Een klant komt langs en biedt aan om u te betalen voor een verbetering van een van de functies. Om het geld te krijgen, moet u uw programma wijzigen om de nieuwe functie toe te voegen. Enkele dingen die van invloed zijn op wat uw winstmarge is, zijn:

1. hoeveel code u moet wijzigen
2. hoe gemakkelijk het is om de wijzigingen aan te brengen
3. hoe waarschijnlijk het is dat u bestaande functies die door andere klanten worden gebruikt, verbreekt
4. hoeveel u uw bestaande model / architectuur kunt hergebruiken

Scheiding van zorgen helpt u om meer positieve antwoorden op deze vragen te krijgen.

1. als alle code voor een bepaald gedrag van de toepassing is gescheiden, hoeft u alleen de code te wijzigen die rechtstreeks verband houdt met uw nieuwe functie . Dat zou minder code moeten zijn om te veranderen.
2. als het gedrag waarin je geïnteresseerd bent netjes gescheiden zijn van de rest van de applicatie, is de kans groter dat je een nieuwe implementatie kunt omwisselen zonder dat je het volledig hoeft te begrijpen of manipuleer de rest van het programma. Het zou ook gemakkelijker moeten zijn om erachter te komen welke code u moet wijzigen.
3. Code die u niet hoeft te wijzigen, zal minder snel breken dan code die u wel verandert. Dus door de zorgen op te splitsen, kunt u voorkomen dat niet-gerelateerde functies worden afgebroken door te voorkomen dat u de code die ze zouden kunnen bellen, hoeft te wijzigen. Als uw functies door elkaar worden gehaald, kunt u het gedrag van de ene per ongeluk veranderen terwijl u probeert een andere te veranderen.
4. Als uw architectuur agnostisch is voor technische of zakelijke logische details, is het minder waarschijnlijk dat wijzigingen in de implementatie nodig zijn nieuwe architectonische kenmerken. Als uw hoofddomeinlogica bijvoorbeeld database-agnostisch is, zou het ondersteunen van een nieuwe database net zo eenvoudig moeten zijn als het omwisselen van een nieuwe implementatie van de persistentielaag.

Opmerkingen

• Ik vind het geweldig dat je het antwoord stevig verankerd hebt in de financiële realiteit. Managers hebben geen excuus om slordig te zijn en dit fundamentele concept te negeren.

Kijk naar een ziekenhuis en denk eens aan alle verschillende rollen die betrokken zijn bij het verlenen van zorg aan een patiënt: triageverpleegkundigen, artsen, medische assistenten, techneuten, administratief personeel, cafetaria, enz.

Is er iemand die weet hoe al van die mensen krijgen hun werk gedaan? Nee, want het zou overweldigend zijn. Ze moeten de verschillende verantwoordelijkheden verdelen in verschillende rollen en de contactpunten tussen die rollen zijn heel specifiek.

Als hij / zij werkt op een kantoor, neem het als voorbeeld, leg de rol van elk personeel in dat kantoor uit, en vraag hem, wat zou er gebeuren als dat personeel niet wordt verdeeld volgens hun baan?

Ik zou kijken hoe hij SoC niet in zijn code / ontwerp toepaste en dat omzetten in een real-world voorbeeld waarmee hij zich kan identificeren en dat is duidelijk ongewenst.

Als hij bijvoorbeeld een klas heeft waar de klant verschillende stukjes informatie moet verstrekken die niet relevant zijn voor die klanten, dan zou ik de analogie gebruiken van een bakkerij waar je om je eigen granen en gist mee te nemen als je een brood wilt kopen.

Een voorbeeld zou een html-ontwikkelaar kunnen zijn wil html, css en javascript scheiden in separa te bestanden. Op deze manier kun je het uiterlijk en het gevoel van iets zeggen veranderen door simpelweg de css of het gedrag van iets aan te passen door het javascript-bestand te wijzigen dat apart wordt geladen. Als u een responsieve of adaptieve site heeft, werkt dit paradigma goed, aangezien u verschillende css of javascript kunt laden, afhankelijk van een gebruikersviewport of user-agent. Als u echter de html of sjabloon wijzigt, is de kans groot dat de css of javascript kan breken. Deze afzonderlijke zorgen kunnen ook afhankelijk zijn.

Een andere benadering is om al uw css javascript en html te bundelen in een groep componenten of modules. Dit betekent dat u wijzigingen kunt aanbrengen in één module en dat het geen invloed mag hebben op andere componenten of modules op de pagina die wordt weergegeven en die niet gerelateerd zijn. Hier worden de css-, js- en html-bestanden samengevoegd tot een enkele component die kan worden getest.De scheiding van zorgen komt dus in de vorm van individuele atomaire componenten die een eenheid kunnen testen in plaats van scheiding van opmaak-, stijl- en gedragselementen. Deze tweede benadering is meer geschikt voor het maken van meer complexe webapplicaties.

bewerken. Omdat ik een negatief antwoord op deze opmerking heb gekregen, dacht ik dat ik het opnieuw zou bezoeken en zou proberen een deel van mijn pov te kwalificeren. Helaas is alle feedback hier niet bijzonder constructief, maar ik heb ergens anders een interessante discussie gezien die kijkt naar React, de huidige populaire technologie in webontwikkeling, een voorbeeld uit de echte wereld, en vraagt of het scheiding van zorgen doorbreekt of in het bijzonder als het een van het principe van Feathers SOLID objectgeoriënteerde ontwerpmethodologie.

Het technische JavaScript-ontwikkelaarsperspectief

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. 

Het UX / UI-ontwerperperspectief

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. 

Het teamperspectief

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

Op de pagina staat ook een link naar een interessante presentatie van Pete Hunt, van Facebook, waar hij het heeft over componenten, niet over sjablonen, en de problemen in de taaltoepassing in plaats van het scheiden van zorgen van het raamwerk, dwz sjablonen, css en javascript enz.

Met betrekking tot het scheiden van uw zorgen in de taal van uw toepassing kan dit betekenen dat u verschillende patronen moet gebruiken om uw code te scheiden of ontkoppelen in een modulaire vorm dat kan worden getest op eenheden enz.

Dus om samen te vatten, het scheiden van zorgen kan afhangen van uw rol of standpunt, zoals elders vermeld.

Reacties

• dit lijkt ‘ t niets substantiëels te bieden over de punten die in eerdere 7 antwoorden
• Ik wijs er alleen op dat het scheiden van zorgen verschillende benaderingen kan hebben, afhankelijk van de context. Dit komt dichter bij de werkelijkheid in de wereld van software engineering en ik benadruk dat er verschillende benaderingen zijn die u kunt volgen bij het werken aan html-paginas die in eerste instantie tegenstrijdig lijken.