Разница между заботой и ответственностью (т.е. разница между SRP и SoC)?

SRP - у каждого класса должна быть только одна ответственность (т. е. причина для изменения).
Разделение проблем - это процесс разбиения компьютерной программы на отдельные функции, которые пересекаются в функциональность как можно меньше. Обеспокоенность - это любой интерес или предмет в программе. (Обеспокоенность == особенность системы.)

а) Насколько я понимаю, единственная разница между ними заключается в том, что SRP пытается разделить обязанности на разные классы и SoC пытается разделить проблемы на разные модули?!

б) Если предположение согласно a) верно, в чем разница между проблемой и ответственностью (помимо того факта, что ответственность существует на более низком уровне абстракции)?

Спасибо


design-patterns single-responsibility-principle separation-of-concerns
person user702769    schedule 14.10.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вот как я их вижу - один и тот же принцип, обычно упоминаемый на разных уровнях абстракции.

person eulerfx    schedule 15.10.2012

arrow_upward
1
arrow_downward

Хороший вопрос. :) Отказ от ответственности: только мои мысли. Раньше я не думал об этом различии. Я не думаю, что между этими двумя концепциями есть большая разница.

Однако вот что я могу сказать: я знаю только о сквозных проблемах. Хотя основная идея проблемы - это, как вы выразились, любая часть интереса или направленность программы, превращаются ли проблемы в обязанности, если они не пересекаются?

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

В некотором роде, кто несет ответственность за добавление товара в корзину? (Скажем, CartService) Будет ли он привлечен к ответственности, если история AddItemToCart не удалась? да. Будет ли он привлечен к ответственности в случае сбоя LogAddItemActivity? Нет. История AddItemToCart связана с регистрацией данных. Это. Можно ли отделить его от деятельности, за которую отвечает CartService? Модули и классы - это абстракции на разных уровнях.

person Atul    schedule 15.10.2012