solid原则_SOLID –单一责任原则-CSDN博客

solid原则

单一责任原则（SRP）规定：

改变班级的理由不应该只有一个以上。

我们可以将“改变的理由”与“阶级的责任”联系起来。因此，每个责任都是变革的轴心。此原理类似于设计具有高度凝聚力的类。因此，其想法是设计一个负责任的类，或者换句话说，就是要实现某种功能的类。我想在这里澄清一个责任并不意味着该类只有一个方法。可以通过类中的不同方法来实现职责。

为什么需要此原则？

想象一下，设计类承担多个责任/实现多个功能。没有人阻止您这样做。但是，请想象一下，您的类可以在开发时间的适当范围内在其内部创建多少依赖关系。因此，当系统要求您更改某些功能时，您实际上不确定它将如何影响该类中实现的其他功能。更改可能会或可能不会影响其他功能，但您确实不能冒险，尤其是在生产应用程序中。因此，您最终要测试所有相关功能。

您可能会说，我们拥有自动化测试，并且要检查的测试数量很少，但是可以想象一下随着时间的推移会产生什么样的影响。由于代码的粘性，使得这些更改变得累加，从而使其真正变得脆弱而僵硬。

纠正违反SRP的一种方法是将类功能分解为不同的类，每个类都向SRP确认。

阐明此原理的示例：

假设要求您实施UserSetting服务，用户可以在其中更改设置，但必须先对用户进行身份验证。一种实现方法是：

public class UserSettingService
{
  public void changeEmail(User user)
  {
    if(checkAccess(user))
    {
       //Grant option to change
    }
  }
  public boolean checkAccess(User user)
  {
    //Verify if the user is valid.
  }
}

一切看起来不错，直到您想在其他地方重用checkAccess代码，或者要更改checkAccess的完成方式，或者要更改批准电子邮件更改的方式。在后两种情况下，最终都将更改同一个类，在第一种情况下，还必须使用UserSettingService来检查访问权限，这是不必要的。

纠正此问题的一种方法是将UserSettingService分解为UserSettingService和SecurityService。并将checkAccess代码移至SecurityService。

public class UserSettingService
{
  public void changeEmail(User user)
  {
    if(SecurityService.checkAccess(user))
    {
       //Grant option to change
    }
  }
}

public class SecurityService
{
  public static boolean checkAccess(User user)
  {
    //check the access.
  }
}

另一个示例是：

假设有下载文件的要求–可能是csv / json / xml格式，需要分析文件，然后将内容更新到数据库或文件系统中。一种方法是：

public class Task
{
  public void downloadFile(location)
  {
    //Download the file
  }
  public void parseTheFile(file)
  {
    //Parse the contents of the file- XML/JSON/CSV
  }
  public void persistTheData(data)
  {
    //Persist the data to Database or file system.
  }
}

看起来不错，所有地方都一目了然。但是该类必须更新的次数呢？解析器代码的可重用性如何？或下载代码？就代码不同部分的可重用性和内聚性而言，这不是一个很好的设计。

分解Task类的一种方法是创建不同的类来下载文件-Downloader，用于分析文件-Parser以及持久保存到数据库或文件系统。

即使在JDK中，您也必须看到java.awt包中的Rectangle2D或其他Shape类确实没有关于如何在UI上绘制的信息。图形信息已嵌入在Graphics / Graphics2D程序包中。

可以在此处找到详细说明。

参考：来自我们的JCG合作伙伴 Mohamed Sanaulla的 SOLID-单一责任原则，来自“ Experiences Unlimited”博客。

相关文章：