Question

今天我和某人争吵了。

我在解释拥有丰富的域模型而不是贫血域模型的好处。并通过一个看起来像

的简单类来演示我的观点

public class Employee
{
    public Employee(string firstName, string lastName)
    {
        this.FirstName = firstName;
        this.LastName = lastname;
    }

    public string FirstName { get private set; }
    public string LastName { get; private set; }
    public int DaysOfHolidays { get; private set; }

    public void AddHolidays(int numberOfdays)
    {
        // do stuff
    }
}

当他为贫穷的模型方法辩护时，他的一个论点是：＆＃34;我是SOLID的信徒。您违反了单一责任原则，因为您既代表数据又在同一类中执行逻辑。＆＃34;

我发现这个说法真的很令人惊讶，因为遵循这个推理，任何具有一个属性和一个方法的类都违反了SRP，因此OOP通常不是SOLID，函数式编程是通往天堂的唯一途径。

我决定不回答他的许多论点，但我很好奇社区对这个问题的看法。

如果我回复了，我会先指出上面提到的悖论，然后指出SRP高度依赖于你想要考虑的粒度级别，如果你把它拿得足够远，那么任何类都包含超过1个属性或1个方法违反了它。

你会说什么？

Answer 1

单一责任原则仅关注特定的一段代码（在OOP中，通常我们所说的类）是否对一个功能负责。我认为你是朋友说功能和数据无法合作并没有真正理解这个想法。如果Employee还包含有关他的工作场所的信息，他的车有多快，以及他的狗吃什么类型的食物，那么我们就会遇到问题。

由于本课程仅涉及Employee，我认为公平地说它并没有公然违反SRP，但人们总是会有自己的意见。

我们可以改进的一个地方是将员工信息（如姓名，电话号码，电子邮件）与他的假期分开。 这在我看来并不意味着方法和数据不能混合，这只意味着假期信息可能在一个单独的地方。

Answer 2

我认为如果此类继续同时代表Employee和EmployeeHolidays，则该类可能会违反SRP。

实际上，如果是我的Peer Review，我可能会让它通过。如果添加了更多的Employee特定属性和方法，并且添加了更多特定于假日的属性，我可能会建议拆分，同时引用SRP和ISP。

OOP是否违反了单一责任原则？

2 个答案: