【问题标题】:Correct way to get a value?获得价值的正确方法?
【发布时间】:2013-10-01 18:50:08
【问题描述】:

作为我 AP 课程的一部分,我正在学习 java,并且在从事一个项目时,我想知道以下哪种方法是返回值的最佳方式?

   public double getQuarters(){
    return quarters;
}

     public void getQuarters(){
    System.out.println(quarters);
}

***注意:我现在第二个选项不是“技术上”返回一个值,但它仍然显示我的值,所以为什么要打扰?

【问题讨论】:

  • 使用常识选项。最好在需要时学习。当需要出现时,常识会再次引导您做出正确的选择。

标签: java return void


【解决方案1】:
 public double getQuarters(){
    return quarters;
}

使用这个记录器封装quarters,隐藏它不被其他程序访问。这意味着,您必须将其声明为private quarters。让我们看看第二个选项:

 public void getQuarters(){
    System.out.println(quarters);
}

但是,这似乎是错误的,因为 getQuarters 没有返回任何内容。因此,将其重构为更有意义

     public void printQuarters(){
         System.out.println(quarters);
     }

【讨论】:

  • 根据它与对象其余部分的相关性,我可能会将其放在toString() 方法中。但是,认识到该方法应该反映目的是什么,这一点值得称赞。
【解决方案2】:

如果您只需要在调用此方法时显示值,并且您对控制台输出没问题,那么您的System.out.println 方法将完成这项工作。但是,实际返回变量的函数在语义上更加正确和有用。

例如,虽然您可能只需要打印当前项目的变量,但如果您稍后回来并决定将变量输出到文件中怎么办?如果您使用 println 语句编写了 getQuarters 函数,则需要重写整个内容。另一方面,如果您将函数编写为返回,则无需更改任何内容。您所要做的就是为文件输出添加新代码,并在需要的地方使用函数。

因此,返回函数更加通用,尽管在较大的代码项目中更是如此。

【讨论】:

    【解决方案3】:

    返回值到程序中的特定点,以便程序可以使用它来运行。

    您在程序中的特定点打印值,以便您作为最终用户可以看到您为某些功能返回了什么值。

    根据功能——例如,你的——quarters 的结果在程序中不再被考虑;它所做的只是将一个值打印到屏幕上,而应用程序没有 [clean|easy] 方法可以将其取回以使用它。

    如果您的程序需要该值才能运行,那么它必须return。如果需要调试,可以在需要的地方使用System.out.println()

    但是,您将多次使用return 语句。

    【讨论】:

      【解决方案4】:

      你的答案是正确的。第二种方法根本不返回任何值,因此虽然您可能能够看到输出,但您的程序却不能。第二种方法对于测试甚至命令行应用程序仍然有用,但它应该被命名为类似 printQuarters 的名称。

      【讨论】:

        【解决方案5】:

        您回答了自己的问题。对于“最佳”一词的大多数定义,您应该使用第一个选项。

        但是,您的问题确实涉及访问器和修改器的面向对象编程主题。在您的示例中,“getQuarters”是一个访问器。通常最好使用访问器来检索您的值。这是遵守Open/Closed Principle 的一种方式。

        此外,Java 社区为此提供了 coding convention,许多工具和库都依赖于遵循这些约定的代码。

        【讨论】:

          【解决方案6】:

          选项 1 要好得多。

          1. 可以轻松进行单元测试。
          2. 如果规范发生变化,有时您想打印结果,有时将其放入数据库,该怎么办?选项 1 将获取值的逻辑与如何处理它分开。现在,对于单一方法 getQuarters 没什么大不了的,但最终您可能会拥有 getDimes、getEuros 等...
          3. 如果季度可能存在错误情况,例如值非法,该怎么办?在选项 1 中,您可以返回一个“特殊”值,例如 -1.0,或者抛出一个异常。然后客户决定做什么。

          【讨论】:

          • 我不是 TDD 狂热分子,但 TDD 告诉我们,关注单元测试永远为时过早。
          • 好吧,很明显我们有一个反例! ;-) 抱歉,这评论只是在开玩笑。这是一个同意不同意的情况,但我只需要在这种情况下支持我相当强烈的意见,并投反对票。
          • Stackoverflow 投票和评分最近一直困扰着我,有时我认为这很糟糕,或者只是还不错。答案得到了很多赞成票,等等。但我从来没有想过一个支持更容易测试的代码的答案会永远得到反对票。我很震惊。
          • 好吧,我不会给予任何重视,因为这只是某个陌生人的意见。只是将其视为个人意见而不是客观判断。在这种情况下,我认为您所说的并没有错,但是当初学者甚至难以理解返回值的概念时,提出它只是错误的时间!我的一小部分意见反对将 TDD 视为教条。许多惊人的好+有用的代码已经并且仍然以非TDD方式编写。一世。 e. TDD 没有提供符号语言相对于汇编程序的优势。
          • 总之,如果这不是你回答的第一点,我觉得没有理由给我的 2 美分投反对票。请建设性地或不屑一顾地对待这件事,但请不要轻视。
          猜你喜欢
          • 1970-01-01
          • 2020-01-22
          • 2016-07-22
          • 2014-11-15
          • 2018-11-03
          • 1970-01-01
          • 2021-04-08
          • 2014-12-23
          • 2020-02-23
          相关资源
          最近更新 更多