好吧,我有一个可读取Excel文件作为模板的类。
我正在阅读有关单一职责原则的一些知识,并决定我需要重构我的课堂,因为它所做的不只是一件事。
我只是不确定我是否在这里做了很多事情?
public WebElement waitForElementVisibilityByCss(String css, int timeInSeconds) {
return (new WebDriverWait(getDriver(), timeInSeconds)).until(
ExpectedConditions.visibilityOfElementLocated(By.cssSelector(css)));
}
答案 0 :(得分:1)
乍一看,这对我来说看起来不错。
关键是要在类/方法中具有有意义的量的“责任”。只需阅读类的名称并查看公共方法,就应该清楚该类可以为您做什么 ,以及如何与该类交互以实际得到这些结果。
除此之外,方法应该做一些易于通过单元测试进行测试的事情。
考虑所有上述想法:是的,这看起来不错。
其中:我假设您的公共静态实用程序方法在多个类中使用,只有这样,它们才应进入不同的类。唯一值得考虑的事情:所有方法和类都需要公开吗?整体解决方案的外部用户(从其他程序包中调用),该客户端代码是否真的需要 all 这些公共方法?含义:仅公开外部客户代码应该使用的内容!
答案 1 :(得分:1)
关于OOP,您的设计可能会得到改进。在您对OOP充满信心之后,它是否符合SRP和SOLID的想法应该排第二(或第三)。
让我大吃一惊的是班级名称。其中三个描述的是动作而不是“事物”,第四个是带有静态方法的“ Utils”类,如果我们坚持使用OOP,这是一个很大的禁止。
因此,让我们首先选择正确的名称。如果您的域是关于Excel的,则您的类应为:ExcelFile
,Sheet
,Row
,Cell
等。您已经有一些,这很好,但是所有对象需要来自您的域,尤其是域中的“事物”。
如果有这些,请考虑他们必须做什么(职责),以便最终获得所需的东西。不是他们必须拥有的数据,而是他们可能提供的功能。例如,我可以想象ExcelFile
有一个名为writeTo(File file)
的方法,或者Cell
有isEmpty()
等,
您做得很好,如果您的逻辑最后是单线的,则类似:
ExcelFile.readFrom(...).addInformation(...).writeTo(...);
您应该能够从代码中重新读取需求。
如果到了这一步,那么然后遍历代码并查看某个对象是否承担着太多的责任就可以进行重构了。