Java静态方法需要实现

2023年5月24日 215次阅读

我必须完成的任务已经交付,但在我的脑海中仍然存在一个问题.

我定义了以下界面：

package dao;

import java.sql.SQLException;

/**
 * Get / save / delete a single instance from the db in RESTful fashion on the object
 * @author kimg
 *
 * @param <T>
 */
public interface IDao<T> {

    public void fetch(int id); 
    public void save() throws SQLException; 
    public void delete() throws SQLException; 

}

目的是让所有表示为数据库表实体的pojo实现这些方法,因此pojo的用户知道如何根据模式处理实例.我从Backbone(Javascript)采用了这种方法.

但是,还有其他方法我喜欢在Pojo类本身上强加类方法(静态).最明显的方法是：

List<Person> list = Person.fetchAll(); 
List<Person> list = Person.fetchAll(offset, limit); 
int i = Person.countAll(); 
...

我发现默认情况下定义这些方法提供了很大的好处,但没有任何东西迫使开发人员实现它们,因为默认情况下不能强加静态方法.此外,类的用户无法确定他们是否能够使用他们原本期望通过合同预期的静态方法(如果是接口);方法名称中的任何拼写错误,省略任何方法都可能导致平滑的应用程序工作流程中断.

抓住这个陷阱最优雅的解决方案是什么？

最佳答案

I’ve found that having these methods defined by default offers great benefit, yet nothing forces a developer to implement them, as static methods can’t be imposed by default.

如果这些方法非常有用,那么开发人员是否希望实现它们？至少如果他们意识到所需的模式和实施它们的有用性？

Also, users of the classes can’t know for sure that they’ll be able to use the static methods that they would otherwise expect by contract (in case of an interface)

这是无关紧要的,因为静态方法不是虚拟的.用户确实知道他们想要调用其静态方法的类型是否确实具有该方法.如果他们忘了那么编译器会很乐意告诉他们.

any typo in the method name, omitting any method can cause the smooth app workflow to break.

我不确定我是否跟着你.如果你在谈论开发人员未能实现这些静态方法或者错误地执行这些方法,那么这就是代码审查的目的.您还可以编写自动化测试,以反映验证方法的存在.我真的没有看到这是一个更大的问题,而不是使用所需签名实现的方法,但实现不正确.

同样,静态方法不是虚拟的.每个静态方法调用的用户在编译时都知道正在调用哪个方法,因此是否可以使用这种方法.如果他们想要一个特定的方法并且没有它,那么他们可以选择添加它,自己添加它,或者不添加它.

What would be the most elegant solution to catch this pitfall?

记录任何此类期望.让项目管理人员强制执行(如果他们拒绝这样做,那么也许它毕竟不是那么重要).使用代码审查.编写自动化测试,也许是反思测试.

点赞