SRP - 每个类应该只有一个职责（即更改的理由）
关注点分离是将计算机程序分解为不同功能的过程功能重叠少 尽可能。关注点是程序中的任何兴趣或关注点。 （关注==系统特性。）
a) 据我了解，两者之间的唯一区别是 SRP 试图将 职责 分成不同的 类 和 SoC 试图将关注 分成不同的模块？！
b) 如果 a) 下的假设是正确的，关注和责任之间有什么区别（除了 em>责任存在于较低的抽象级别）？
谢谢
【问题讨论】：
标签： design-patterns separation-of-concerns single-responsibility-principle
这就是我对它们的看法 - 相同的原则，通常在不同的抽象级别引用。
【讨论】：
好问题。 :) 免责声明：只是我的想法。我之前没有考虑过区别。我认为这两个概念之间没有太大区别。
但是，我想说的是： 我只知道横切问题。尽管正如您所说，关注点的基本概念是程序中的任何兴趣或关注点，但如果关注点不是跨领域的，它们会成为责任吗？
我认为原理是一样的。甚至我的理解也和你一样。 在购物车系统中，将商品添加到购物车可以被视为一个问题……这是用例应该做的主要事情。所涉及的类并不真正关心日志记录、安全性等。即使没有日志记录，也可以将项目添加到类中。但是对于购物车或服务必须公开添加项目的功能，否则用例将失败。 同样，对于日志记录用例，如果记录器未能记录活动，则意味着日志记录用例不起作用，即使该项目已添加到购物车。
有点像，将商品添加到购物车是谁的责任？ （比方说 CartService）如果 AddItemToCart 故事失败，它会被追究责任吗？是的。如果 LogAddItemActivity 失败会追究责任吗？不。 AddItemToCart 故事是否与日志记录活动有关。这是。它可以与 CartService 负责的活动分开吗？ 模块和类是不同层次的抽象。
【讨论】：