Question

这是示例代码，未遵循单一责任原则

public class EmailSender
{
  public void SendEmail(string customerID, 
                       string emailNotificationType)
  {
    //STEP1: load customer details
    //STEP2: get email content
    //STEP3: send email (using SmtpClient class)
  }

  public string GetEmailContent(Customer customer, 
                 string emailNotificationType)
   {
    // Build the email notification content
   }
}

我同意，如果我需要执行以下操作，它将引起问题

-> Changes in the way, you are loading customer details.

-> Changes to the email content because of requirement enhancements / changes.

-> If there any change in the way you are sending the email instead of using SmtpClient class or something like that.

因此，我们需要应用“单一责任原则”来分隔类别。我完全同意这一原则。假设我需要创建

这样的三个类

EmailSender-仅专注于发送电子邮件 CustomerRepository-仅专注于获取客户数据 EmailContentBuilder-解析电子邮件内容

但是说，如果我有一个像CustomerDao这样的Dao，那么到目前为止，我在与以下类相同的类中具有与CustomerDao相关的所有CRUD操作

CustomerDao类
   -add（）
   -update（）    -get（）
   -getAll（）
   -update（）

我们需要在此处应用SingleResponsibilityPrinciple吗？如果是这样，如何申请CustomerDao类？

谢谢，
哈里

Answer 1

您不想申请DAO，因为它只会做一件事。

good example

sourse

模式和原理很重要，但是如果使用不正确，它们可能会带来一个简单的问题，就像没有它们一样复杂。

不应严格理解SRP。一个对象应该承担的责任很少，而不是“一个”。 CustomerDao 在这里仅负责客户的持久性，因此它只负责一项。

Answer 2

尽管其名称SRP表示为“ A class should have only one reason to change”。 DAO发生更改的原因有一个：在数据库表和业务对象之间的映射发生更改时，DAO不会违反SRP。

举个例子：业务逻辑发生了变化，因此我们需要向对象中添加更多数据：我们向业务对象中添加字段，向数据库表中添加列，当然我们需要更改映射。然后，我们可能会更改单个DAO类的get / add / update方法。

为了清楚地理解该原理，我建议您阅读SOLID原理的原始资料：Robert Matin的书Agile Software Development, Principles, Patterns, and Practices。

道课的单一责任原则

2 个答案: