另外,我是found this,但它与SRP无关
好吧,乍一看,getterters和setter都没有违反Single Responsibility Principle,因为它们只具有“属于”当前类的逻辑.他们可以访问/编写“服务”一个目的的类成员.精细.
但是等等,我们首先定义基本术语：
数据访问=设置器和getter
数据处理=数据处理,CRUD,验证等操作
如果是这样,那么我们在一个类中有两个不同的职责,从而打破了SRP.
让我们暂时假设,为了不破坏SRP,我们将在不同的类中定义数据访问和数据操作.
class DA { // <- Data Access
public string getName() {
return this.name;
}
public string setName(name) {
this.name = name;
}
}
class DataHandler {
public DataHandler(da) { // <- Inject an instance of DA
this.da = da;
}
public bool validate() {
// validation stuff
}
}
它看起来很好,因为我们没有违反所述SRP.但是在这里我只有一个setter而且只有DA类中的getter.
现在的问题是：
1)即使我只有一个setter和getter,我是否应该总是创建另一个DA类,以便它不会破坏SRP？
2)确定者和吸气者是否真的打破了SRP,他们是否应该在任何一个班级中使用？
3)如果是这样,依赖注入始终是答案！？
制定者和吸气者是否打破了SRP？塞特斯和吸气者不是重点. SRP的要点是一个班级应该只有一个责任.
代表域对象是一项重大责任.执行此操作的对象通常称为“数据对象”.由于语言设计或惯例,数据对象通常具有setter和getter,但它们本身并不是一个单独的责任;他们只是管道.
将数据对象输入和输出持久存储是另一项重大责任.执行此操作的对象通常称为“数据访问对象”(DAO).不是数据对象的DAO可能不需要它所管理的数据对象类型的属性的setter和getter,尽管我可以想象一个非常糟糕的框架需要它们.与DAO一样,使用数据对象(显示它们,对它们进行序列化和反序列化,对它们执行计算等)并且不是数据对象本身的其他类型的对象可能不需要镜像数据对象的setter和getter.
因此,设置setter和getter表示您的对象是数据对象.如果它是一个数据对象,并且它也是一个DAO或者还有其他一些重大责任,它可能会违反SRP.
旁注：你提到验证.在典型的应用程序验证中,至少单个数据对象属于数据对象本身,因为表示域对象并强制域对象属性之间的个体正确性和关系几乎是相同的责任.
即使我只有一个setter和getter,我是否应该总是创建另一个DA类？
一般来说,是的.要点不是属性的数量;关键是表示和访问是两个不同的职责,属于不同的类.
典型的应用程序有许多域对象,因此如果将域对象与其访问权限分开是有意义的,那么对所有域对象(甚至是单属性对象)进行一致的操作是有意义的.
依赖注入总是答案吗？
这取决于您的架构和框架.您可能拥有不可变数据对象和DAO,其方法将它们作为参数;那里没有DI(尽管你可以将DAO注入使用它们的更高级别的组件中).您可能拥有使用数据对象实例化的DAO或具有DAO引用的数据对象(我见过但都不喜欢这两种模式);你可能需要DI那里.无论哪种方式,它与其余讨论没有太大关系.