Java OOP静态实用程序方法帮助!

时间:2010-12-14 22:32:51

标签: java methods static instance

我最近在User类中做了一个看起来像这样的方法;

  public static boolean checkUN(String username) {
  boolean check = false;
  ResultSet rs;
  String dbQuery;
  SQLController db = new SQLController();
  db.setUp();
  dbQuery = "SELECT * FROM User WHERE User_name ='" + username + "'";
  try {
   db.setUp();
   rs = db.readRequest(dbQuery);
   if (rs.next()) {
    check = true;
   }
  } catch (Exception e) {
   e.printStackTrace();
  }
  db.terminate();
  return check;
 }

我打算在用户能够继续下一步注册之前进行验证检查。

当我向老师展示时,她说可以,因为我将它作为一种多功能方法。但是,她后来改变了主意,说我应该将其更改为实例方法,然后创建一个新的User对象来进行验证。

哪种方式更有效?

user.checkUsername(jTextUN.getText());

和实例方式 (假设我改变了方法,删除了静态和输入参数);

User user = new User();
user.setUsername(jTextUN.getText());
user.checkUsername();

干杯!

3 个答案:

答案 0 :(得分:2)

我可能会创建某种UserValidator类并创建一个包含您的方法的实例。

答案 1 :(得分:2)

首先,我不喜欢涉及创建新User对象然后在其上调用checkUsername()的解决方案,原因如下:

  • 如果没有存在给定用户名的有效用户,则不应该有任何代表该用户的User对象...因为它们不存在。这不是一个严格的规则,因为有时您可能需要一个User对象代表您即将创建的用户或其他类似的对象,但在这里我发现它不自然。
  • 它违反了对数据对象可以做什么的期望。创建new User()然后让checkUsername()根据用户的用户名返回不同的值会令人惊讶。

现在,我知道你在上课,所以这可能超出了你的学习范围,但更进一步:

这两种解决方案对我来说都不是很好,因为它们都会将使用它们的任何代码紧密地耦合到数据库中,这使得代码难以测试。

对此的一般解决方案是包装会使使用它的组件难以在界面中测试的代码,如下所示:

public interface UserService {
  boolean checkUsername(String username);
  ...
}

然后你可以创建一个与数据库对话的UserService实现,而需要使用该代码的类可以在它们的构造函数中注入它的实现:

public class UserServiceClient {
  private final UserService userService;

  public UserServiceClient(UserService userService) {
    this.userService = userService;
  }

  ...
}

这是依赖注入的原则。除了使代码更加灵活之外,它还允许您提供UserService的虚假实现以进行测试。如果您想在checkUsername返回true时测试某个类中发生的情况以及返回false时会发生什么,您可以使用始终返回true的虚假实现或总是返回false。您不必担心设置数据库连接或确保存在正确的数据或确保在测试后正确重置数据库状态,同样重要的是,当不需要执行数据库时,测试速度要快得多通信。

你可能想要做的另一件事就是在两种方法之间的某个地方就是拥有一个User对象来存储用户的数据(但不能与数据库或任何此类事物本身通信)并在UserService

中添加这样的方法
User getUser(String username);

此方法将为具有给定用户名的用户返回User对象(如果存在),否则返回null。您也可以将checkUsername实现为

return getUser(username) != null;

答案 2 :(得分:1)

嗯,第二种方式是更具可扩展性和更直观的(如果你想稍后改变的话),所以我推荐它。但第一种方法是直接解决问题,如果“用户”的概念以后不再扩展(使用新方法),那么任何一个都应该没问题。