语言-编程原则SOLID-SRP

Single Responsibility Pricinple

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.(当我们需要在具有更多职责的类中进行变更时，变更可能会影响与类的其他职责相关的其他功能。)
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类有两个职责（改变的原因）。 一个是在某些电子邮件协议中使用该类，如pop3或imap。 如果必须支持其他协议，则应以另一种方式序列化对象，并添加代码以支持新协议。 另一个将用于内容字段。 即使内容是字符串，也许我们希望在将来支持HTML或其他格式。
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）使我们为每个实现的协议添加代码。
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.	单一职责原则是在应用程序设计阶段识别类的一种好方法，它提醒您思考一个类可以发展的所有方式。 只有当应用程序应该如何工作的完整画面才能很好地理解时，才能将责任分开。
// single responsibility principle - good example interface IEmail {             public void setSender(String sender);             public void setReceiver(String receiver);             public void setContent(IContent content); } interface Content {             public String getAsString(); // used for serialization } class Email implements IEmail {             public void setSender(String sender) {// set sender; }             public void setReceiver(String receiver) {// set receiver; }             public void setContent(IContent content) {// set content; } }	// single responsibility principle - bad example interface IEmail {             public void setSender(String sender);             public void setReceiver(String receiver);             public void setContent(String content); } class Email implements IEmail {             public void setSender(String sender) {// set sender; }             public void setReceiver(String receiver) {// set receiver; }             public void setContent(String content) {// set content; } }

一句话总结： 当我们去更改一个类时，只有一个理由去更改，就像文中举例的那样， email 类中在更改时理由只是添加不同的协议，如果又加上更改内容，那么就违反了该原则，我在网上查了一下，为什么要坚持这种原则，是为了增加程序的健壮性，举个例子，如果在程序中实现了两件事，当我们更改其中一件事的时候，就会影响另外一件事。