Jak wyjaśnisz innym separację problemów?

Wyobraź sobie, że masz program który został wydany. Przychodzi klient i oferuje Ci zapłatę za ulepszenie jednej ze swoich funkcji. Aby otrzymać pieniądze, musisz zmienić swój program i dodać nową funkcję. Niektóre z rzeczy, które wpłyną na wysokość Twojej marży to:

1. ile kodu musisz zmienić
2. jak łatwo jest wprowadzić zmiany
3. jakie jest prawdopodobieństwo, że zepsujesz istniejące funkcje używane przez innych klientów
4. ile możesz ponownie wykorzystać istniejący model / architektura

Rozdzielenie problemów pomaga aby uzyskać bardziej pozytywne odpowiedzi na te pytania.

1. jeśli cały kod dla określonego zachowania aplikacji zostanie oddzielony, będziesz musiał tylko zmienić kod bezpośrednio powiązany z nową funkcją . Który powinien być mniej kodu do zmiany.
2. jeśli zachowania, którymi jesteś zainteresowany, są starannie oddzielone od reszty aplikacji, jest bardziej prawdopodobne, że będziesz w stanie zamienić się na nową implementację bez konieczności pełnego zrozumienia lub manipulować resztą programu. Powinno być również łatwiejsze ustalenie, który kod należy zmienić.
3. Kod, którego nie musisz zmieniać, jest mniej podatny na złamanie niż kod, który sam zmieniasz. Tak więc rozdzielenie obaw pomaga uniknąć awarii niepowiązanych funkcji, zapobiegając konieczności zmiany kodu, który mogliby wywołać. Jeśli funkcje są pomieszane, możesz przypadkowo zmienić zachowanie jednego z nich, próbując zmienić inny.
4. Jeśli Twoja architektura jest niezależna od szczegółów technicznych lub biznesowych, zmiany w implementacji będą mniej wymagały nowe cechy architektoniczne. Na przykład, jeśli logika domeny głównej jest niezależna od bazy danych, obsługa nowej bazy danych powinna być tak łatwa, jak wymiana w nowej implementacji warstwy trwałości.

Komentarze

• Podoba mi się, że odpowiedź jest mocno osadzona w finansowej rzeczywistości. Menedżerowie nie mają wymówki, by być niedbałym i ignorować tę fundamentalną koncepcję.

Spójrz na szpital i pomyśl o różnych rolach związanych z opieką nad pacjentem: pielęgniarki segregacyjne, lekarze, asystenci medyczni, technicy, personel biurowy, stołówka itp.

Czy jest jakaś osoba, która wie, jak to zrobić wszyscy z tych ludzi wykonują swoją pracę? Nie, ponieważ byłoby to przytłaczające. Muszą rozdzielić różne obowiązki na różne role, a punkty styku między tymi rolami są bardzo specyficzne.

Jeśli on / pracuje w biurze, weź to jako przykład, wyjaśnij rolę każdego personelu w tym biurze i zapytaj go, co by się stało, gdyby ten personel nie był podzielony według ich pracy?

Spojrzałbym na to, jak nie udało mu się zastosować SoC w swoim kodzie / projekcie i przekształciłbym to w prawdziwy przykład, z którym może się odnieść i jest to oczywiście niepożądane.

Na przykład, jeśli ma zajęcia, w których klient musi podać kilka informacji, które nie są istotne dla tych klientów, użyłbym analogii piekarni, w której masz przynieść własne zboża i drożdże, jeśli chcesz kupić chleb.

Jednym z przykładów może być programista html chcesz oddzielić html, css i javascript na osobne te pliki. W ten sposób możesz zmienić wygląd i styl wypowiedzi, po prostu modyfikując css lub zachowanie czegoś, zmieniając plik javascript, który jest ładowany oddzielnie. Jeśli masz witrynę responsywną lub adaptacyjną, ten paradygmat działa dobrze, ponieważ możesz załadować różne css lub javascript w zależności od widoku użytkownika lub agenta użytkownika. Jednak jeśli zmodyfikujesz kod HTML lub szablon, istnieje prawdopodobieństwo, że CSS lub JavaScript może się zepsuć. Te oddzielne problemy mogą być również zależne.

Innym podejściem jest spakowanie całego javascript i html css w grupę komponentów lub modułów. Oznacza to, że możesz wprowadzać zmiany w jednym module i nie powinno to wpływać na inne komponenty lub moduły na stronie, obok których działa, a które nie są powiązane. Tutaj pliki css, js i html są łączone w jeden komponent, który można przetestować jednostkowo.Tak więc oddzielenie obaw następuje w postaci pojedynczych atomowych komponentów, które można przetestować jednostkowo, zamiast oddzielania znaczników, stylizacji i elementów behawioralnych. To drugie podejście jest bardziej odpowiednie do tworzenia bardziej złożonych aplikacji internetowych.

edytuj. Ponieważ otrzymałem negatywną odpowiedź na ten komentarz, pomyślałem, że wrócę do niego i spróbuję zakwalifikować niektóre z moich punktów widzenia. Niestety, żadna opinia tutaj nie jest szczególnie konstruktywna, ale widziałem interesującą dyskusję w innym miejscu, która dotyczy React, aktualnej gorącej technologii w tworzeniu stron internetowych, rzeczywistego przykładu i pyta, czy przerywa podział obaw, czy w szczególności przerywa jeden z zasada „s of Feather” metodologia projektowania obiektów SOLID.

Techniczna perspektywa dla programistów 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. 

Perspektywa projektanta 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. 

Z perspektywy zespołu

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

Również na stronie znajduje się link do ciekawej prezentacji od Pete Hunt z Facebooka, gdzie mówi on o komponentach, a nie szablonach i oddziela obawy w aplikacji językowej, a nie oddzielenie problemów związanych z frameworkiem, tj. szablony, css i javascript itp.

Jeśli chodzi o oddzielenie problemów w języku aplikacji, może to wymagać użycia różnych wzorców w celu oddzielenia lub oddzielenia kodu do postaci modułowej które można przetestować jednostkowo itp.

Podsumowując, oddzielenie obaw może zależeć od twojej roli lub punktu widzenia, jak wspomniano gdzie indziej.

Komentarze

• to nie ' nie wydaje się oferować niczego istotnego w porównaniu z uwagami przedstawionymi i wyjaśnionymi w poprzednich 7 odpowiedzi
• Zwracam tylko uwagę, że oddzielenie obaw może przyjąć różne podejście w zależności od kontekstu. Jest to bliższe rzeczywistej sytuacji w inżynierii oprogramowania i podkreślam, że podczas pracy ze stronami html można zastosować różne podejścia, które na pierwszy rzut oka mogą wydawać się sprzeczne.