Как вы объясняете разделение проблем другим?

Если у вас был коллега, который не понимал преимуществ Разделения проблем или не понимал этого достаточно, чтобы последовательно применять его в своей повседневной работе, как бы вы объяснили им это?

Представьте, что у вас есть программа, которая была выпущена. Приходит клиент и предлагает заплатить вам за усовершенствование одной из его функций. Чтобы получить деньги, вам нужно будет изменить программу, чтобы добавить новую функцию. Некоторые вещи, которые будут влиять на размер вашей прибыли:

1. сколько кода вы должны изменить
2. как легко внести изменения
3. насколько вероятно, что вы нарушите существующие функции, которые используются другими клиентами
4. сколько вы можете использовать вашу существующую модель / архитектуру

Разделение проблем помогает вам получить более положительные ответы на эти вопросы.

1. если весь код для конкретного поведения приложения выделен, вам нужно будет только изменить код, непосредственно связанный с вашей новой функцией. Который должен быть меньше кода, чтобы изменить.
2. если интересующее вас поведение аккуратно отделено от остальной части приложения, более вероятно, что вы сможете поменяться новой реализацией без необходимости полностью понимать или манипулировать остальной частью программы. Также должно быть проще выяснить, какой код вам нужно изменить.
3. Код, который вам не нужно менять, с меньшей вероятностью сломается, чем код, который вы меняете. Таким образом, разделение проблем помогает вам избежать поломок в несвязанных функциях, предотвращая необходимость изменять код, который они могут вызывать. Если ваши функции смешаны вместе, вы можете случайно изменить поведение одной из них, пытаясь изменить другую.
4. Если ваша архитектура не зависит от деталей технической или бизнес-логики, то изменения в реализации с меньшей вероятностью потребуют новых архитектурных функций. Например, если ваша основная логика домена не зависит от базы данных, то поддержка новой базы данных должна быть такой же простой, как и замена новой реализации уровня персистентности.

Посмотрите на больницу и подумайте обо всех различных ролях, которые участвуют в оказании медицинской помощи пациенту: медсестры-сортировщики, врачи, медицинские помощники, технические специалисты, канцелярский персонал, кафетерий и т. Д.

Есть ли один человек, который знает, как все эти люди выполняют свою работу? Нет, потому что это было бы подавляющим. Они должны разделять разные обязанности на отдельные роли, а точки соприкосновения между этими ролями очень специфичны.

Если он / она работает в офисе, возьмите его в качестве примера, объясните роль каждого сотрудника в этом офисе и спросите его, что произойдет, если эти сотрудники не будут разделены в зависимости от их работы?

Я бы посмотрел на то, как он не смог применить SoC в своем коде / дизайне, и превратил это в реальный пример, с которым он может иметь дело, и это явно нежелательно.

Например, если у него есть класс, где клиенту нужно предоставить несколько частей информации, которые не имеют отношения к этим клиентам, то я бы использовал аналогию с пекарней, где вы должны приносить свои собственные зерна и дрожжи, если вы хотите купить хлеб.

Одним из примеров может быть html-разработчик, который хочет разделить html, css и javascript на отдельные файлы. Таким образом, вы можете изменить внешний вид чего-то, скажем, просто изменив CSS или поведение чего-либо, изменив файл javascript, который загружается отдельно. Если у вас есть адаптивный или адаптивный сайт, эта парадигма работает хорошо, так как вы можете загружать различные CSS или JavaScript в зависимости от области просмотра пользователя или пользовательского агента. Однако, если вы измените html или шаблон, есть вероятность, что css или javascript могут сломаться. Эти отдельные проблемы также могут быть зависимыми.

Другой подход заключается в объединении всего вашего CSS JavaScript и HTML в группу компонентов или модулей. Это означает, что вы можете вносить изменения в один модуль, и это не должно влиять на другие компоненты или модули на той странице, на которой он выполняется, если он не связан. Здесь файлы css, js и html объединяются в один компонент, который можно тестировать модулем. Таким образом, разделение интересов происходит в форме отдельных атомных компонентов, которые могут быть проверены модулем, а не разделением элементов разметки, стиля и поведения. Этот второй подход больше подходит для создания более сложных веб-приложений.

редактировать. Поскольку я получил отрицательный ответ на этот комментарий, я подумал, что вернусь к нему и попытаюсь оценить некоторые из моих POV. К сожалению, любые отзывы здесь не особенно конструктивны, но я видел интересное обсуждение в другом месте, которое рассматривает React, текущую горячую технологию в веб-разработке, пример из реальной жизни и спрашивает, нарушает ли это разделение интересов или, в частности, если оно нарушает одно из принцип методики ориентированного проектирования твердого объекта Feather.

Техническая перспектива разработчика 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.

Перспектива дизайнера 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.

Перспектива команды

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

Также на странице есть ссылка на интересную презентацию от Пита Ханта из Facebook, где он рассказывает о компонентах, а не о шаблонах, и разделяет проблемы в языковом приложении, а не разделяет проблемы структуры, то есть шаблоны, css и javascript и т.п.

Что касается выделения ваших проблем на языке вашего приложения, это может включать использование различных шаблонов для разделения или разделения вашего кода в модульную форму, которая может быть протестирована модулем и т. Д.

Таким образом, чтобы подвести итог, разделение проблем может зависеть от вашей роли или точки зрения, как уже упоминалось где.