什么是一类，一个责任原则？
我想了解一级，一个责任原则。 我找到了一些关于它的文章，但没有例子。 如果你能给我一个违反这个原则的课程的例子，这对我有帮助。
我熟悉一个方法应该只做一件事的想法，例如get和set方法。 它不能与One Class，One Responsibility相同 ，因为set和get方法都在类中实现。 那么这是否意味着该类违反了该规则，因为该类有责任设置和获取？
什么是一类，一个责任原则 ？
我不是这个设计模式的100％专家，但这就是我如何看待它 – 如果我创建一个对象，它只负责一件事。 如果它需要做其他事情，但与另一个对象有关，根据情况，我会使用inheritance或接口。
这个概念看起来相当简单; 确保特定对象（或方法）处理一个逻辑。 如果它处理更多，则需要另一个对象（或方法）。
原则正是它所说的，而不是更多。 一个class级应该只有一个责任。 但是，定义责任可能很困难。 一个示例可以是“DatabaseHandler”类，它处理应用程序中的所有数据库请求。
进一步阅读： 凝聚力 。
关于不混合责任的原则方面。
如果您有一个处理发票的InvoiceProcessor类，按业务规则进行计算，生成带有发票的PDF，处理数据库并向卖方注册额外的奖励积分，那么您就明确需要分离关注点。 在这种情况下，应该明确分离或甚至授权给其他类。
但是，一类 – 一个责任更加微妙和可怕。 如果您必须提供发票处理的解决方案，并且有多个目标可以实现，例如这些奖励积分，您可以使用违规function来实现多个目标：计算卖家的奖励积分和客户的折扣。
在较小的规模上：如果你有一个具有数据结构的类，如优先级队列或其他什么，同时将它与数据结构混合以缓存一个部分，使用List和Map，那么你就是一些为不同的问题操纵数据，甚至可能在缓存列表内寻址，以便数据结构交织在一起。 如果您有一个更改优先级并改变缓存状态的函数，那么将来很难理解这些进程。
我经常遇到需要实现某些不同方面的违规行为，并且它们是在一个类中完成的。 然后，API具有不同抽象级别或难以语义的调用。
类中的每一件事都应该与类应该负责的内容相关。
如果它是一个名为MailSender的类，它应该只知道如何发送邮件。 创建邮件内容的代码不应该在其中。
描述一个反例：
假设您编写了自己的Logger实用程序，并且因为它从简单开始（带有写入stdout的方法的单例），您决定将其所有function放入一个类中。 在使用它时，您会想到要添加的更多function：
-
登录的不同目的地（stderr，文件，队列，等等）
-
能够更改消息的格式
-
为不同类别提供单独的记录器
-
能够按日志级别过滤类别的消息
-
您希望能够在程序运行时更改日志记录级别
-
新的日志记录级别（ERROR，WARN，INFO，DEBUG等）
等等，并将每个function的实现添加到您开始使用的同一个类中。 您所做的每一项更改都意味着返回同一个class级，对其进行排序以查看相关内容，然后进行更改。 因为所有代码都集中在一个类中，并且方法包含实现不同function的代码，所以可能很难跟踪所有相关部分以进行更改，并且总是有可能更改可能会无意中影响其他某些function，因此某些预先存在的function现在可能会在某些情况下停止工作。 因此，您必须测试类中的所有function，更糟糕的是，所有function的所有组合，以便捕获这些错误。 这意味着测试将是不完整的，错误可以潜入。
现在看看像log4j这样的真实项目如何处理这些东西。 关注点分离，不同的类处理格式化，处理输出的编写方式，为类别提供记录器，以及所有这些部分之间的交互是明确定义的，结果是当你修补或替换一个部分时不会影响其他作品。 用户可以创建自己的类来添加他们需要的function（他们不需要知道有关日志框架的所有内容，他们只需要知道他们想要添加的特定类型的部分的合同）并将其插入，用户可以混合搭配不同的插件。 如果插件被破坏，那么破坏不会超出该插件，并且对单个部件的更改不会威胁整个项目的完整性。 如果合同管理各个部分的交互，则无需测试特定function的所有不同组合。 它的工作原理是因为它由各自承担单一责任的部分组成。
使用单一类方法你永远不会这样做，有人添加的每一项新function都将成为项目的一个分支。 单一责任原则和其他SOLID规则的要点是提供一种整体策略，使得能够以受控方式更改软件而不会破坏事物。