谁能给我一个单一职责原则的例子？我试图理解在实践中，一个班级承担单一职责意味着什么，因为我担心我可能每天都会违反这条规则。
【问题讨论】：
标签： oop definition solid-principles single-responsibility-principle design-principles
破解应用程序最有效的方法是创建GOD 类。这些是跟踪大量信息并承担多项职责的类。一项代码更改很可能会影响类的其他部分，因此会间接影响使用它的所有其他类。这反过来又会导致更大的维护混乱，因为除了添加新功能之外没有人敢做任何更改。
以下示例是定义Person 的 TypeScript 类，该类不应包含电子邮件验证，因为这与个人行为无关：
class Person {
public name : string;
public surname : string;
public email : string;
constructor(name : string, surname : string, email : string){
this.surname = surname;
this.name = name;
if(this.validateEmail(email)) {
this.email = email;
}
else {
throw new Error("Invalid email!");
}
}
validateEmail(email : string) {
var re = /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i;
return re.test(email);
}
greet() {
alert("Hi!");
}
}
我们可以通过从 Person 类中删除电子邮件验证的职责并创建一个新的 Email 类来改进上面的类：
class Email {
public email : string;
constructor(email : string){
if(this.validateEmail(email)) {
this.email = email;
}
else {
throw new Error("Invalid email!");
}
}
validateEmail(email : string) {
var re = /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i;
return re.test(email);
}
}
class Person {
public name : string;
public surname : string;
public email : Email;
constructor(name : string, surname : string, email : Email){
this.email = email;
this.name = name;
this.surname = surname;
}
greet() {
alert("Hi!");
}
}
确保一个类具有单一职责，使其默认情况下也更容易查看它的作用以及如何扩展/改进它。
【讨论】：
除非你要求更具体的东西，否则很难提供更多帮助。
单一职责是指一个类做一件特定的事情（职责），而不是试图做更多的事情，这也称为高凝聚力。
类通常不会以低凝聚力开始，但通常在几个版本和不同的开发人员添加到它们之后，你会突然注意到它变成了一些人所说的怪物或上帝类。所以应该重构这个类。
很难想出一个好的例子，但我最近能想到的一个是我们拥有的一个管理不同数据包处理阶段的类，一种Chain of Responsibility。此类的最初目的是维护一个阶段列表并协调对它们的调用 packetProcess()。好吧，最终每个人都在这个管理器类中添加了与处理阶段有关的任何东西（因为管理器类是访问这些阶段的一个容易的地方），尤其是阶段配置。 manager 类不再有单一职责，而是负责调用配置更改的阶段：因此减少了内聚。
我们最终不得不重构管理器类，删除所有阶段配置并将其放入工厂中，从而让管理器去做它打算做的事情。
【讨论】：
一个类应该只有一个改变的理由。
这个原则表明，如果我们有两个理由改变一个类，我们必须将功能分成两个类。每个类将只处理一项职责，如果将来我们需要进行一项更改，我们将在处理它的类中进行。
如果有两个不同的原因进行更改，可以想象两个不同的团队可能出于两个不同的原因处理相同的代码。每个人都必须部署自己的解决方案，在编译语言（如 C++、C# 或 Java）的情况下，可能会导致模块与其他团队或应用程序的其他部分不兼容。
这个原则与耦合和内聚的概念密切相关。耦合是指应用程序的不同方面如何紧密地联系在一起，而内聚是指特定类或包的内容可能密切相关。单个类的所有内容都紧密耦合在一起，因为该类本身是一个[单个单元][1]，必须完全使用或根本不使用。
我的博客文章：
http://javaexplorer03.blogspot.in/2016/12/single-responsibility-principle.html
【讨论】：