Motivation
动机
In this context, a responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one responsibility and if in the future we need to make one change we are going to make it in the class which handles it. When we need to make a change in a class having more responsibilities the change might affect the other functionality related to the other responsibility of the class.
在本文中，责任被认为是更改问题的理由。本原则要求如果我们有2个原因要修改类，我们就需要将这个功能分割成两个类。每个类负责一个职责，如果将来我们需要做更改，就需要在这个职责的类中修改它。当我们修改一个多职责的类时，很可能会影响这个类中关联其他职责的功能。
The Single Responsibility Principle is a simple and intuitive principle, but in practice it is sometimes hard to get it right.
单一职责原则是一个简单易懂的规则，但是在实践中却很难正确使用。
Intent
目的
A class should have only one reason to change.
一个类只应该有一个更改的理由。
Example
示例
Let's assume we need an object to keep an email message. We are going to use the IEmail interface from the below sample. At the first sight everything looks just fine. At a closer look we can see that our IEmail interface and Email class have 2 responsibilities (reasons to change). One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols. Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.
假设我们需要一个对象来保存邮件消息，下面我们将使用IEmail接口来举例。乍看上去一切都很好，但是仔细看我们发现IEmail接口和Email类有2个职责（更改的理由）。一个职责是类使用的邮件协议，如pop3或者imap，如果必须支持其他协议，对象则需要被序列化成其他形式，代码也就需要添加对新协议的支持。另一个职责是内容Content区域，即使内容是字符串，可能将来我们也需要支持HTML或者其他格式。
If we keep only one class, each change for a responsibility might affect the other one:
- Adding a new protocol will create the need to add code for parsing and serializing the content for each type of field.
- Adding a new content type (like html) make us to add code for each protocol implemented.
如果我们只使用一个类，每次为了一个职责的更改都可能影响其他职责：
- 添加新的协议将需要添加代码来分析和序列化每个区域的内容。
- 添加新的内容类型（如html）将需要为每种实现的协议添加代码。
1 // single responsibility principle - bad example 2 3 interface IEmail { 4 public void setSender(String sender); 5 public void setReceiver(String receiver); 6 public void setContent(String content); 7 } 8 9 class Email implements IEmail { 10 public void setSender(String sender) {// set sender; } 11 public void setReceiver(String receiver) {// set receiver; } 12 public void setContent(String content) {// set content; } 13 }
We can create a new interface and class called IContent and Content to split the responsibilities. Having only one responsibility for each class give us a more flexible design:
- adding a new protocol causes changes only in the Email class.
- adding a new type of content supported causes changes only in Content class.
我们可以创建一个新的接口IContent和类Content来分割职责。每个类只有一个职责为我们提供了更灵活的设计：
- 添加新协议只会更改Email类。
- 添加新的内容类型支持指挥修改Content类。
1 // single responsibility principle - good example 2 interface IEmail { 3 public void setSender(String sender); 4 public void setReceiver(String receiver); 5 public void setContent(IContent content); 6 } 7 8 interface Content { 9 public String getAsString(); // used for serialization 10 } 11 12 class Email implements IEmail { 13 public void setSender(String sender) {// set sender; } 14 public void setReceiver(String receiver) {// set receiver; } 15 public void setContent(IContent content) {// set content; } 16 }
Conclusion
结论
The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of responsibilities is done only when the full picture of how the application should work is well understand.
单一职责原则提供了一个在应用设计阶段识别类的好方法，它提醒你去思考类所有可能变化的方式。只有对应用程序的全貌能够很好的理解时，才能建立良好的职责划分。
原文地址：https://www.oodesign.com/single-responsibility-principle.html