我的朋友之间有一个讨论。 我们有一个动作类,负责进行密码控制和其他操作。做这个;有两种方法可以执行此操作 哪一个更好,更适合OOP:
public void dummy()
{
/**
* Something else
*/
if(!isPasswordValid(pass))
{
domainObject.setErrorMessage("Password is not valid!");
}
}
private boolean isPasswordValid(String pass) {
/**
* Check Pass and Return
*/
return false;
}
或
public void dummy() {
/**
* Something else
*/
checkAndSetPass(pass);
}
private void checkAndSetPass(String pass) {
boolean result = false;
/**
* Check Pass and Set result
*/
if (result) {
domainObject.setErrorMessage("Password is not valid!");
}
}
答案 0 :(得分:5)
如果该功能有"和"其名称中的单词很可能违反了Single Responsibility Principle。它似乎在你的第二个版本中是真的。在这种情况下,第一个版本似乎更好。
答案 1 :(得分:2)
SOLID(单一责任,开放式闭合,Liskov替换,接口隔离和依赖性反转)是Michael Feathers为"前五个原则"引入的助记符缩写词。由Robert C. Martin在21世纪初命名,代表了面向对象编程和设计的五个基本原则 读 SOLID_(object-oriented_design)
在你的第二种方法中BartoszKP说它是单一的责任原则。显然,第二种方法不是一种好的面向对象设计。
答案 2 :(得分:0)
SOLID原则更多的是关于类,但我认为思维方式对函数也有效,那么函数应该具有函数名所暗示的一个责任更好,所以我更喜欢第一种方法因为我认为第二种方法违反了单一责任原则。
答案 3 :(得分:0)
您的解决方案可能会产生多个“OOP适用性问题”。您公开问题和解决方案的方式几乎是不面向面向对象的解决方案。您正在考虑行动和运营。在OOP中,典型的第一个想法是更多地关于识别/选择你的演员(对象)和他们的沟通(API或非私人方法使用)。
话虽如此,看看你提出的两个选择,再加上你对你的阶级责任的看法,一个更广泛的编程实践是危险的,单一责任原则(如BartoszKP所指出的方法责任的答案)。您的课程应该代表比“和 其他操作”更单一和更窄的内容。