设置、获取和计算数据的类是否遵循 SOLID 中的 S？答案

【问题标题】：Do classes that set, get and calculate data follow the S in SOLID?设置、获取和计算数据的类是否遵循 SOLID 中的 S？
【发布时间】：2021-03-19 09:27:36
【问题描述】：

假设我生活在一个每个汽车品牌都有不同税率的国家，并且我有一个名为 Car 的基类：

public class Car{
    public string CarType { get; set;}
    public int Year {get; set;}
    public abstract double calculateSalesTax();
}

是否可以添加一个抽象方法来计算销售税？或者这是否已经违反了 SOLID 原则？ SOLID 中 S 的常用准则是“如果在描述类时必须使用 AND 一词，则很可能违反了原则”。在这里，计算销售税的方法的实现似乎需要 AND。此类设置汽车的属性并计算其销售税。

所以如果我实现派生类

public class Volkswagen : Car{
    
    public override double calculateSalesTax(){
         //Something to calculate a VWs tax
    }
}

它已经打破了 SOLID 中的 S 吗？

【问题讨论】：

【解决方案1】：

SOLID 原则是很好的启发式方法，但它们可能有点模糊。它们可以作为思考的食粮，而不是绝对的规则。

Robert C. Martin 将单一职责原则 (SRP) 描述为：

一个班级应该只有一个改变的理由

SRP 和其他 SOLID 原则为您提供了一个提前思考的框架，但您无法预测未来。未来可能会出现计划外的变更原因。

不过，提前考虑一下，您将来必须更改这些课程的原因不止一个吗？

可以想象，您将来可能需要更改calculateSalesTax 方法，但您是否需要更改类的属性？

如果不是，则不违反 SRP。另一方面，如果您期望将来必须更改类的属性，以及calculateSalesTax方法，那么SRP就会被破坏.如果是这种情况，您应该考虑替代设计。

【讨论】：

【解决方案2】：

暴露来自同一模块的数据和逻辑违反了一个更基本的原则：definition of an object。

套用 Martin 的说法，一个对象隐藏了它的数据并暴露了它的行为。数据结构暴露数据并且没有行为。你把两者都暴露了，他将其称为混合体，这是两全其美的。

满足 SRP 还不是问题，因为根据 SRP 所指的定义，这不是一个对象。

【讨论】：