我以前经常用Python编写代码。现在，出于工作原因，我使用Java编写代码。我从事的项目相当小，也许Python会更好地工作，但是有使用Java的非工程性正当理由（我无法详述）。

Java语法没问题；这只是另一种语言。但是，除了语法外，Java还具有被视为“正确”的文化，一套开发方法和实践。现在，我完全无法“培养”这种文化。因此，我将不胜感激正确方向的解释或指点。

我开始的堆栈溢出问题中提供了一个最小的完整示例：https：//stackoverflow.com/questions/43619566/returning-a-result-with-several-values-the-java-way/43620339

我有一个任务-解析（从单个字符串）并处理一组三个值。在Python中，它是一个单行（元组），在Pascal或C中，它是一个五行记录/结构。

根据答案，可以在Java语法中使用struct的等效项，在广泛使用的Apache库中使用struct的等效项-但是“正确”的实现方法实际上是通过为值创建一个单独的类，并完成吸气剂和二传手。有人很乐意提供一个完整的例子。它是47行代码（嗯，其中一些行是空白）。

我知道，庞大的开发社区可能并非“错误”。因此，根据我的理解，这是一个问题。

Python实践优化了可读性（按照这种哲学，导致了可维护性），然后提高了开发速度。C惯例针对资源使用进行了优化。Java实践针对什么进行了优化？我最好的猜测是可伸缩性（一切都应准备好以百万计的LOC项目的状态），但这是一个非常微不足道的猜测。

Java语言

我相信所有这些答案都试图通过将意图归因于Java的工作方式而忽略了重点。Java的冗长性并非源于面向对象，因为Python和许多其他语言也都具有更短的语法。Java的冗长性也不来自于对访问修饰符的支持。相反，这只是Java的设计和发展方式。

Java最初是用OO稍微改进后的C语言创建的。因此，Java具有70年代时代的语法。此外，Java在添加功能方面非常保守，以保持向后兼容性并使其经受住时间的考验。Java在2005年添加了诸如XML文字的流行功能时，当时XML一直风靡一时，而该语言本来会因为没有人关心的幽灵功能而and肿，并在10年后限制了它的发展。因此，Java根本缺少很多现代语法来简洁地表达概念。

但是，没有什么基本的方法可以阻止Java采用该语法。例如，Java 8添加了lambda和方法引用，从而在许多情况下大大降低了冗长性。Java可以类似地添加对紧凑数据类型声明（例如Scala的case类）的支持。但是Java根本没有这样做。请注意，自定义值类型即将出现，此功能可能会引入新的语法来声明它们。我想我们会看到的。

Java文化

企业Java开发的历史很大程度上将我们带入了当今的文化。在90年代末/ 00年代初，Java成为服务器端业务应用程序的一种非常流行的语言。那时，这些应用程序大多是临时编写的，并包含了许多复杂的问题，例如HTTP API，数据库和处理XML提要。

到了20世纪90年代，很明显，许多应用程序具有许多共同点和框架来管理这些问题，例如Hibernate ORM，Xerces XML解析器，JSP和Servlet API以及EJB变得流行。但是，尽管这些框架减少了在它们设置为自动化的特定域中工作的精力，但它们仍需要配置和协调。当时，无论出于何种原因，编写框架来迎合最复杂的用例都是很流行的，因此这些库的设置和集成都很复杂。随着时间的推移，它们随着功能的积累而变得越来越复杂。Java企业的发展逐渐变得越来越多地将第三方库集成在一起，而不再需要编写算法。

最终，繁琐的企业工具配置和管理变得十分痛苦，以至于出现了框架（最著名的是Spring框架）来管理管理。从理论上讲，您可以将所有配置放在一个位置，然后配置工具将配置零件并将它们连接在一起。不幸的是，这些“框架框架” 在整个蜡球之上增加了更多的抽象性和复杂性。

在过去的几年中，越来越多的轻量级库变得越来越流行。但是，随着重型企业框架的发展，整代Java程序员都已经成熟。他们的角色模型（开发框架的模型）编写了工厂工厂和代理配置Bean加载程序。他们必须每天配置和集成这些怪兽。结果，整个社区的文化都遵循了这些框架的榜样，并且往往过度设计。

对于您提出的其他人没有提出的观点之一，我相信我有一个答案。

Java从不进行任何假设，从而优化了编译时程序员的错误检测

通常，Java倾向于仅在程序员已经明确表达其意图之后推断有关源代码的事实。Java编译器从不对代码做任何假设，而只会使用推理来减少冗余代码。

这种理念背后的原因是程序员只是人。我们编写的内容并不总是我们打算实际执行的程序。Java语言试图通过迫使开发人员始终显式声明其类型来缓解其中的某些问题。这只是仔细检查所编写的代码是否确实达到了预期目的的一种方式。

其他一些语言通过检查前置条件，后置条件和不变量来进一步推动该逻辑的发展（尽管我不确定它们是在编译时执行的）。对于程序员来说，这些甚至是更极端的方式，可以使编译器再次检查自己的工作。

在您的情况下，这意味着为了使编译器保证您实际上返回的是您认为要返回的类型，您需要将该信息提供给编译器。

在Java中，有两种方法可以做到这一点：

1. 使用Triplet<A, B, C>的返回类型（这确实应该是java.util，我真的不能解释为什么它不是。尤其是自JDK8介绍Function，BiFunction，Consumer，BiConsumer，等...这似乎只是Pair和Triplet至少会是有意义的。但是，我离题）

2. 为此，请创建您自己的值类型，在其中正确命名和键入每个字段。

在这两种情况下，编译器都可以保证您的函数返回其声明的类型，并且调用者可以意识到每个返回字段的类型是什么，并相应地使用它们。

某些语言确实同时提供了静态类型检查和类型推断，但这为微妙的类型不匹配问题类打开了大门。如果开发人员打算返回某个类型的值，但实际上却返回了另一个类型，而编译器仍然接受该代码，因为碰巧该函数和调用者都碰巧只能同时使用可应用于预期值的方法和实际类型。

在Typescript（或流类型）中考虑类似这种情况，其中使用类型推断而不是显式键入。

function parseDurationInMillis(csvLine){
    // here the developer intends to return a Number, 
    // but actually it's a String
    return csv.firstField();
}

// Compiler infers that parseDurationInMillis is String, so it does
// string concatenation and infers that plusTwoSeconds is String
// Developer actually intended Number
var plusTwoSeconds = 2000 + parseDurationInMillis(csvLine);

当然，这是一个愚蠢的琐碎情况，但由于代码看起来正确，因此它可能更加微妙，并导致难以调试问题。用Java完全避免了这种问题，这就是整个语言的设计目的。

请注意，遵循正确的面向对象原则和领域驱动的建模，链接问题中的持续时间分析案例也可以作为java.time.Duration对象返回，这比上述两种情况都更加明确。

Java和Python是我使用最多的两种语言，但我来自另一个方向。也就是说，在开始使用Python之前，我对Java领域很了解，因此我可能会提供帮助。我认为，“为什么这么重”这个更大的问题的答案可以归结为两点：

• 两者之间的开发成本就像长气球动物气球中的空气一样。您可以挤压气球的一部分，而另一部分则膨胀。Python倾向于挤压早期部分。Java压缩后一部分。
• Java仍然缺少一些功能，可以减轻一些负担。Java 8在这方面起了很大的作用，但是这种文化尚未完全消化这些变化。Java可以使用其他一些东西，例如yield。

Java“优化”了高价值软件，该软件将由大型团队维护多年。我曾经用Python编写东西并在一年后看它的经验，对自己的代码感到困惑。在Java中，我可以查看其他人的代码的小片段，并立即知道它的作用。在Python中，您无法真正做到这一点。正如您似乎意识到的那样，这并不是一个更好的选择，而是它们具有不同的成本。

在您提到的特定情况下，没有元组。一种简单的解决方案是创建一个具有公共价值的类。Java刚问世时，人们经常这样做。这样做的第一个问题是维护麻烦。如果您需要增加一些逻辑或线程安全性或想要使用多态性，则至少需要触摸与该“元组式”对象进行交互的每个类。在Python中，有诸如此类的解决方案，__getattr__因此并不是那么可怕。

虽然有一些不良习惯（IMO）。在这种情况下，如果您想要一个元组，我会问为什么要将它设为可变对象。您只需要使用getter（附带说明，我讨厌get / set约定，但这就是它的意思。）我确实认为裸类（是否可变）在Java的私有或程序包私有上下文中很有用。 。也就是说，通过将项目中的引用限制为该类，可以稍后根据需要进行重构，而无需更改类的公共接口。这是一个如何创建简单的不可变对象的示例：

public class Blah 
{
  public static Blah blah(long number, boolean isInSeconds, boolean lessThanOneMillis)
  {
    return new Blah(number, isInSeconds, lessThanOneMillis);
  }

  private final long number;
  private final boolean isInSeconds;
  private final boolean lessThanOneMillis;

  public Blah(long number, boolean isInSeconds, boolean lessThanOneMillis)
  {
    this.number = number;
    this.isInSeconds = isInSeconds;
    this.lessThanOneMillis = lessThanOneMillis;
  }

  public long getNumber()
  {
    return number;
  }

  public boolean isInSeconds()
  {
    return isInSeconds;
  }

  public boolean isLessThanOneMillis()
  {
    return lessThanOneMillis;
  }
}

这是我使用的一种模式。如果您不使用IDE，则应该开始。它将为您生成吸气剂（如果需要，也可以生成吸气剂），所以这并不是那么痛苦。

如果我不指出的是，已经有这似乎满足你的大部分需求的类型我会觉得失职这里。抛开这些，您使用的方法不太适合Java，因为它发挥了弱点，而不是长处。这是一个简单的改进：

public class Blah 
{
  public static Blah fromSeconds(long number)
  {
    return new Blah(number * 1000_000);
  }

  public static Blah fromMills(long number)
  {
    return new Blah(number * 1000);
  }

  public static Blah fromNanos(long number)
  {
    return new Blah(number);
  }

  private final long nanos;

  private Blah(long nanos)
  {
    this.nanos = nanos;
  }

  public long getNanos()
  {
    return nanos;
  }

  public long getMillis()
  {
    return getNanos() / 1000; // or round, whatever your logic is
  }

  public long getSeconds()
  {
    return getMillis() / 1000; // or round, whatever your logic is
  }

  /* I don't really know what this is about but I hope you get the idea */
  public boolean isLessThanOneMillis()
  {
    return getMillis() < 1;
  }
}

在您对Java过于生气之前，请阅读您在其他文章中的回答。

您的抱怨之一是需要创建一个类来返回一些值作为答案。我认为这是一个有效的担忧，表明您的编程直觉是正确的！但是，我认为其他答案由于坚持您所致力于的原始痴迷反模式而没有实现。而且Java使用多个原语的便利性不像Python那样简单，在Python中，您可以本地返回多个值并将它们轻松分配给多个变量。

但是，一旦您开始考虑ApproximateDuration类型对您有什么作用，您就会意识到，它的范围并不局限于“仅仅一个看似不必要的类以返回三个值”。此类所代表的概念实际上是您的核心领域业务概念之一 -需要能够以近似的方式表示时间并进行比较。它必须是应用程序核心通用语言的一部分，并具有良好的对象和域支持，以便可以对其进行测试，模块化，可重用和有用。

您的代码是将近似的持续时间（或持续时间有误差的总和，还是您所表示的持续时间）加在一起完全是程序性的吗？我建议，围绕近似持续时间求和的良好设计将指示在可以测试的类中的任何消耗代码之外进行此设计。我认为使用这种域对象将在您的代码中产生积极的连锁反应，从而帮助您摆脱逐行的程序步骤来完成单个高级任务（尽管有很多责任），而转向单一职责类摆脱了不同关注点的冲突。

例如，假设您了解更多有关持续时间求和和比较正常工作实际需要的精度或小数位数的信息，并且发现需要一个中间标记来指示“大约32毫秒错误”（靠近平方1000的根，因此在1到1000之间进行对数对数）。如果您将自己绑定到使用基元表示此代码的代码，则必须在代码中查找您拥有的每个位置is_in_seconds,is_under_1ms并将其更改为is_in_seconds,is_about_32_ms,is_under_1ms。到处都会改变一切！安排一个班级来负责记录误差范围，以便可以在其他地方使用它，这可以使您的消费者无需了解什么误差范围很重要或如何组合的细节，而是让他们只指定相关的误差范围在这一刻。（也就是说，当您在类中添加新的错误裕度级别时，不会强制更改其错误裕度正确的使用方代码，因为所有旧的错误裕度仍然有效）。

结束语

随着您逐渐接近SOLID和GRASP的原理以及更高级的软件工程，关于Java繁重的抱怨似乎消失了。

附录

我将完全免费且不公平地补充一点，C＃的自动属性和在构造函数中分配仅获取属性的能力有助于进一步清理“ Java方式”所需的有点凌乱的代码（具有显式的私有支持字段和getter / setter函数） ：

// Warning: C# code!
public sealed class ApproximateDuration {
   public ApproximateDuration(int lowMilliseconds, int highMilliseconds) {
      LowMilliseconds = lowMilliseconds;
      HighMilliseconds = highMilliseconds;
   }
   public int LowMilliseconds { get; }
   public int HighMilliseconds { get; }
}

这是上述内容的Java实现：

public final class ApproximateDuration {
  private final int lowMilliseconds;
  private final int highMilliseconds;

  public ApproximateDuration(int lowMilliseconds, int highMilliseconds) {
    this.lowMilliseconds = lowMilliseconds;
    this.highMilliseconds = highMilliseconds;
  }

  public int getLowMilliseconds() {
    return lowMilliseconds;
  }

  public int getHighMilliseconds() {
    return highMilliseconds;
  }
}

现在，这真是太干净了。请注意不变性的非常重要和有意的使用-这对于这种特殊的具有价值的课程来说似乎至关重要。

因此，此类也是a struct，值类型的一个不错的选择。一些测试将显示切换到结构是否具有运行时性能优势（可能）。

Python和Java均根据其设计者的理念针对可维护性进行了优化，但是对于如何实现这一点，他们有非常不同的想法。

Python是一种多范式语言，它优化了代码的清晰度和简洁性（易于读写）。

Java是（传统上）基于单范例类的OO语言，它优化了显式性和一致性 -甚至以更冗长的代码为代价。

Python元组是具有固定数量字段的数据结构。带有显式声明的字段的常规类可以实现相同的功能。在Python中，提供元组作为类的替代品是很自然的，因为它可以极大地简化代码，尤其是由于内置了对元组的语法支持。

但这与提供这种快捷方式的Java文化并不完全匹配，因为您已经可以使用显式声明的类。无需引入其他类型的数据结构，只是节省了一些代码行并避免了一些声明。

Java倾向于使用最少的特殊情况语法糖来统一应用的单个概念（类），而Python提供了多种工具和大量语法糖，使您可以针对任何特定目的选择最方便的方法。

不要寻找做法；如最佳实践BAD中所述，这通常是一个坏主意，模式好吗？。我知道您并没有要求最佳实践，但我仍然认为您会在其中找到一些相关的要素。

寻找问题的解决方案比实践更好，并且您的问题不是在Java中快速返回三个值的元组：

• 有数组
• 您可以将一个数组作为一个列表中的列表返回：Arrays.asList（...）
• 如果您想保留尽可能少的样板（且不带龙目岛），则可以：

class MyTuple {
    public final long value_in_milliseconds;
    public final boolean is_in_seconds;
    public final boolean is_under_1ms;
    public MyTuple(long value_in_milliseconds,....){
        ...
    }
 }

在这里，您有一个不可变的对象，只包含您的数据，并且是公共的，因此不需要获取方法。请注意，但是，如果您使用某些序列化工具或持久性层（如ORM），则它们通常使用getter / setter（并且可以接受参数以使用字段而不是getter / setter）。这就是为什么这些做法被广泛使用的原因。因此，如果您想了解实践，最好了解它们为什么在这里，以便更好地使用它们。

最后：我使用吸气剂是因为我使用了很多序列化工具，但是我都不编写它们。我使用lombok：我使用IDE提供的快捷方式。

一般而言，关于Java习惯用语：

Java拥有所有类的类有多种原因。据我所知，主要原因是：

Java对于初学者来说应该很容易学习。事情越明确，就越难以错过重要的细节。较少发生的魔术对于初学者来说很难掌握。

对于您的特定示例：一个单独类的参数行是这样的：如果这三件事彼此之间有足够的关联，并且它们作为一个值返回，则值得将其命名为“事物”。为以通用方式构造的一组事物引入名称意味着定义一个类。

您可以使用Lombok之类的工具来简化样板：

@Value
class MyTuple {
    long value_in_milliseconds;
    boolean is_in_seconds;
    boolean is_under_1ms;
}

关于Java文化，可以说很多事情，但是我认为在您现在正面临的情况下，有一些重要方面：

1. 库代码只编写一次，但使用频率更高。虽然可以最大程度地减少编写库的开销，但是从长远来看，以使使用库的开销降至最低的方式进行编写可能更值得。
2. 这意味着自我记录类型非常有用：方法名称有助于清楚地说明正在发生的事情以及您从对象中得到的结果。
3. 静态类型化是消除某些错误类别的非常有用的工具。它当然不能解决所有问题（人们喜欢开玩笑说Haskell，一旦您使类型系统接受您的代码，那可能是正确的），但是它使得很容易使某些错误的事情变得不可能。
4. 编写库代码是关于指定合同的。为参数和结果类型定义接口可以使合同的界限更加明确。如果某个东西接受或产生一个元组，则不必说这是您实际上应该接收还是产生的元组，并且对这样的泛型类型的约束很少（它甚至具有正确数量的元素吗？他们是您期望的类型？）。

具有字段的“结构”类

正如其他答案所提到的，您可以只使用带有公共字段的类。如果将它们定型，则将获得一个不可变的类，并使用构造函数对其进行初始化：

   class ParseResult0 {
      public final long millis;
      public final boolean isSeconds;
      public final boolean isLessThanOneMilli;

      public ParseResult0(long millis, boolean isSeconds, boolean isLessThanOneMilli) {
         this.millis = millis;
         this.isSeconds = isSeconds;
         this.isLessThanOneMilli = isLessThanOneMilli;
      }
   }

当然，这意味着您与特定的类相关联，任何需要产生或使用解析结果的内容都必须使用该类。对于某些应用程序，这很好。对于其他人，这可能会引起一些痛苦。许多Java代码都是关于定义合同的，通常会将您带入接口。

另一个陷阱是，使用基于类的方法时，您将暴露字段，并且所有这些字段都必须具有值。例如，即使isLessThanOneMilli为true，isSeconds和millis始终必须具有某些值。当isThanOneMilli为true时，对Millis字段的值的解释应该是什么？

“结构”作为接口

使用接口中允许使用的静态方法，实际上相对容易地创建不可变的类型，而没有大量的语法开销。例如，我可能会像这样实现您正在谈论的结果结构：

   interface ParseResult {
      long getMillis();

      boolean isSeconds();

      boolean isLessThanOneMilli();

      static ParseResult from(long millis, boolean isSeconds, boolean isLessThanOneMill) {
         return new ParseResult() {
            @Override
            public boolean isSeconds() {
               return isSeconds;
            }

            @Override
            public boolean isLessThanOneMilli() {
               return isLessThanOneMill;
            }

            @Override
            public long getMillis() {
               return millis;
            }
         };
      }
   }

我绝对同意，这仍然是很多样板，但是也有很多好处，而且我认为那些开始回答您的一些主要问题。

使用这种解析结果的结构，可以非常清楚地定义解析器的协定。在Python中，一个元组与另一个元组并没有真正的区别。在Java中，静态类型可用，因此我们已经排除了某些类型的错误。例如，如果您要使用Python返回一个元组，并且想要返回该元组（millis，isSeconds，isLessThanOneMilli），则可能会意外地执行以下操作：

return (true, 500, false)

当你的意思是：

return (500, true, false)

使用这种Java接口，您将无法编译：

return ParseResult.from(true, 500, false);

完全没有 你必须做：

return ParseResult.from(500, true, false);

通常，这是静态类型语言的好处。

这种方法也开始使您能够限制可以获取的值。例如，在调用getMillis（）时，您可以检查isLessThanOneMilli（）是否为true，如果是，则抛出IllegalStateException（例如），因为在这种情况下没有有意义的millis值。

很难做错事

在上面的接口示例中，您仍然会遇到问题，因为它们具有相同的类型，因此可能会意外交换isSeconds和isLessThanOneMilli参数。

在实践中，您实际上可能真的想利用TimeUnit和持续时间，以便得到类似以下的结果：

   interface Duration {
      TimeUnit getTimeUnit();

      long getDuration();

      static Duration from(TimeUnit unit, long duration) {
         return new Duration() {
            @Override
            public TimeUnit getTimeUnit() {
               return unit;
            }

            @Override
            public long getDuration() {
               return duration;
            }
         };
      }
   }

   interface ParseResult2 {

      boolean isLessThanOneMilli();

      Duration getDuration();

      static ParseResult2 from(TimeUnit unit, long duration) {
         Duration d = Duration.from(unit, duration);
         return new ParseResult2() {
            @Override
            public boolean isLessThanOneMilli() {
               return false;
            }

            @Override
            public Duration getDuration() {
               return d;
            }
         };
      }

      static ParseResult2 lessThanOneMilli() {
         return new ParseResult2() {
            @Override
            public boolean isLessThanOneMilli() {
               return true;
            }

            @Override
            public Duration getDuration() {
               throw new IllegalStateException();
            }
         };
      }
   }

这越来越成为一个很多更多的代码，但是你只需要编写一次，和（假设你已经正确记录的东西），谁落得人使用你的代码没有什么结果意味着猜了，不能偶然地做那些result[0]刻薄的事情result[1]。您仍然可以非常简洁地创建实例，并且从其中获取数据也不是那么困难：

  ParseResult2 x = ParseResult2.from(TimeUnit.MILLISECONDS, 32);
  ParseResult2 y = ParseResult2.lessThanOneMilli();

请注意，您实际上也可以使用基于类的方法执行类似的操作。只需为不同情况指定构造函数。但是，仍然存在将其他字段初始化为什么的问题，并且无法阻止对它们的访问。

另一个答案提到Java的企业类型性质意味着在很多时候，您是在组合其他已经存在的库，或者编写供其他人使用的库。你的公共API不应该需要大量的时间咨询文件破译结果类型，如果能够避免它。

您只需编写一次这些结构，但是您会多次创建它们，因此您仍然希望进行简洁的创建（您会得到）。静态类型可确保您从中获取的数据符合您的期望。

现在，尽管如此，仍然有一些地方可以让简单的元组或列表有意义。返回数组的内容可能会减少开销，如果是这种情况（并且开销很大，您可以通过分析确定），则在内部使用简单的值数组可能很有意义。您的公共API可能仍应具有明确定义的类型。

问题是您将苹果与桔子相提并论。您询问了如何模拟返回多个值，而不是给出一个带有无类型元组的快速脏python示例的示例，实际上您收到了实际上的一线回答。

接受的答案提供了正确的业务解决方案。无需使用临时的快速变通方法，您第一次需要抛弃并正确实现时就需要对返回值进行任何实际操作，而是一个POJO类，它与大量库兼容，包括持久性，序列化/反序列化，仪器和任何可能的东西。

这一点也不长。您唯一需要编写的就是字段定义。可以生成setter，getter，hashCode和equals。因此，您的实际问题应该是：为什么不会自动生成getter和setter而是一个语法问题（有人会说是语法糖问题）而不是文化问题。

最后，您想过要加速一点根本不重要的事情。与维护和调试系统所花费的时间相比，编写DTO类所花费的时间微不足道。因此，没有人会优化以减少冗长。

这是有助于您观察的三个不同因素。

元组与命名字段

也许是最琐碎的-在其他语言中，您使用了元组。讨论元组是否是一个好主意并不是真正的重点-但是在Java中，您确实使用了较重的结构，因此这是一个有点不公平的比较：您可以使用对象数组和某种类型转换。

语言语法

声明这个类会更容易吗？我并不是说要公开字段或使用地图，而是像Scala的案例类那样，它提供了您描述的设置的所有好处，但更加简洁：

case class Foo(duration: Int, unit: String, tooShort: Boolean)

我们可以做到这一点-但要付出代价：语法变得更加复杂。当然，在某些情况下，甚至在大多数情况下，甚至在未来5年内的大多数情况下，都值得这样做-但需要进行判断。顺便说一句，这是您可以自行修改的语言（例如lisp）的优点-并且请注意由于语法的简单性，这如何成为可能。即使您实际上并没有修改语言，简单的语法也可以启用更强大的工具。例如，很多时候我都错过了Java可用的一些重构选项，但是Scala却没有。

语言哲学

但是最重​​要的因素是语言应该支持某种思维方式。有时可能会让人感到压抑（我经常希望支持某些功能），但是删除功能与拥有它们一样重要。你能支持一切吗？当然可以，但是您最好编写一个编译每种语言的编译器。换句话说，您将没有语言-您将拥有语言的超集，并且每个项目基本上都会采用一个子集。

当然，编写与语言哲学背道而驰的代码也是可能的，而且正如您所观察到的那样，结果通常很难看。在Java中仅具有几个字段的类类似于在Scala中使用var，将prolog谓词退化为函数，在haskell中执行unsafePerformIO等。Java类并不是轻巧的-它们不在那里传递数据。当某些事情看起来很困难时，退后一步，看看是否还有另一种方法通常是富有成果的。在您的示例中：

为什么持续时间与单位分开？有很多时间库可让您声明一个持续时间-诸如Duration（5，seconds）（语法会有所不同），然后它们将使您以更强大的方式执行所需的任何操作。也许您想将其转换-为什么要检查result [1]（或[2]？）是否为“小时”并乘以3600？对于第三个论点-它的目的是什么？我猜想在某个时候您将不得不打印“少于1毫秒”或实际时间-这是时间数据所固有的一些逻辑。即您应该有一个这样的课程：

class TimeResult {
    public TimeResult(duration, unit, tooShort)
    public String getResult() {
        if tooShort:
           return "too short"
        else:
           return format(duration)
}

}

或您实际上想要对数据做的任何事情，从而封装了逻辑。

当然，在某些情况下，这种方式可能行不通-我并不是说这是将元组结果转换为惯用的Java代码的神奇算法！在某些情况下，它很难看而且很糟糕，也许您应该使用其他语言-这就是为什么毕竟有那么多的原因！

但是我对为什么类在Java中是“重型结构”的观点是，您不是要把它们用作数据容器，而是要用作自包含的逻辑单元。

据我了解，核心原因是

1. 接口是抽象类的基本Java方法。
2. Java只能从方法中返回一个值-对象或数组或本机值（int / long / double / float / boolean）。
3. 接口不能包含字段，只能包含方法。如果要访问字段，则必须通过一种方法-因此是getter和setter。
4. 如果方法返回接口，则必须具有一个实现类才能实际返回。

这使您“必须编写一个类以返回任何非平凡的结果”，这反过来又很沉重。如果您使用类而不是接口，则可以只具有字段并直接使用它们，但这将您绑定到特定的实现。

我同意JacquesB的回答

Java（传统上）是基于单范例类的OO语言，它针对显式性和一致性进行了优化

但是明确性和一致性不是要优化的最终目标。当您说“针对可读性优化了python”时，您立即提到最终目标是“可维护性”和“开发速度”。

当您具有显式性和一致性时，以Java方式完成了什么？我的看法是，它已经发展成为一种语言，声称可以提供可预测的，一致的，统一的方式来解决任何软件问题。

换句话说，对Java文化进行了优化，以使管理人员相信他们了解软件开发。

或者，就像一个很聪明的人很久以前说的那样，

判断语言的最佳方法是查看其支持者编写的代码。“ Radix enim omnium malorum est cupiditas”-Java显然是面向金钱的编程（MOP）的示例。正如SGI的Java首席支持者告诉我的那样：“亚历克斯，你必须去赚钱的地方。” 但是我不是特别想去哪里有钱-通常在那儿闻起来不太香。

（此答案不是特别针对Java的解释，而是解决了“（繁重的）实践可以优化什么？”这一一般性问题。）

考虑以下两个原则：

1. 当您的程序做正确的事情时，这很好。我们应该使编写正确的程序变得容易。
2. 当程序执行错误的操作时，这很不好。我们应该使编写做错事情的程序更加困难。

试图优化其中一个目标有时可能会妨碍另一个目标（即，使做错事情变得更加困难，也可能使做正确的事情变得更加困难，反之亦然）。

在任何特定情况下进行哪种权衡取决于应用程序，所讨论的程序员或团队的决定以及（组织或语言社区的）文化。

例如，如果程序中的错误或几个小时的中断可能导致人员伤亡（医疗系统，航空航天）或什至只是金钱（如Google广告系统中的数百万美元），那么您将做出不同的权衡（不是不仅使用您的语言，而且还涉及工程文化的其他方面），而不是使用一次性脚本：它可能倾向于“繁重”的一面。

其他可能使您的系统更“沉重”的示例：

• 当您有许多团队多年来从事大型代码库开发时，一个大问题就是某人可能会错误地使用别人的API。用错误的顺序调用参数的函数，或者在未确保其期望的前提条件/约束的情况下调用的函数，可能会造成灾难性的后果。
• 作为一个特殊的例子，假设您的团队维护一个特定的API或库，并希望对其进行更改或重构。用户对代码使用方式的“约束”越多，更改代码就越容易。（请注意，这里最好有实际的保证，那就是没有人会以异常的方式使用它。）
• 如果开发是由多个人或团队分散进行的，那么让一个人或团队“指定”接口并让其他人实际实现它似乎是一个好主意。为了使它起作用，您需要能够在实现完成时获得一定程度的信心，即实现实际上与规范匹配。

这些只是一些示例，旨在让您了解使事情“繁重”（并且使您更难于快速地编写一些代码）确实是故意的。（甚至可能会争辩说，如果编写代码需要付出很多努力，这可能会使您在编写代码之前进行更仔细的考虑！当然，这种说法很快就会变得荒谬。）

例如：Google的内部Python系统往往使事情变得“繁重”，以致您不能简单地导入其他人的代码，而必须在BUILD文件中声明依赖项，要导入其代码的团队需要将其库声明为对您的代码可见，等等。

注意：以上所有都是关于事情何时变得“沉重”的。我绝对不声称Java或Python（语言本身或它们的文化）在任何特定情况下都具有最佳的权衡；这是您要考虑的。关于这种权衡的两个相关链接：

• 埃里克·奥斯海姆（Erik Osheim）的一篇很棒的文章，关于动态类型语言的吸引力是什么？—朝相反的方向，试图解释为什么有人可能更喜欢Python之类的语言。
• 回答本网站用户Newtopian到的“Java面向对象”和“Python的OOP”之间的差异？

Java文化已经随着时间的流逝而发展，它受到来自开放源代码和企业软件背景的重大影响-如果您真的考虑过，这是一个奇怪的组合。企业解决方案需要重型工具，而开源则要求简单。最终结果是Java位于中间位置。

影响该建议的部分原因是，在Python和Java中，可读性和可维护性是非常不同的。

• 在Python中，元组是一种语言功能。
• 在Java和C＃中，元组都是（或将是）一个库功能。

我仅提及C＃，因为标准库具有一组Tuple <A，B，C，.. n>类，并且如果该语言不直接支持它们，则这是一个很好的例子，说明了元组多么笨拙。在几乎每种情况下，如果您选择了很好的类来处理问题，您的代码就会变得更具可读性和可维护性。在链接的Stack Overflow问题中的特定示例中，其他值将很容易表示为返回对象上的已计算getter。

C＃平台所做的一个有趣的解决方案提供了一个令人满意的中间立场，那就是匿名对象（在C＃3.0中发布）的想法，这种想法非常容易解决。不幸的是，Java还没有类似的东西。

在修改Java语言功能之前，最易读和可维护的解决方案是拥有一个专用对象。这是由于该语言的限制可以追溯到1995年开始。原始作者计划了许多语言功能，而这些功能从未实现过，而向后兼容性则是Java随时间演变的主要限制之一。

我认为在这种情况下使用类的核心问题之一是，在一起的东西应该保持在一起。

我已经对方法参数进行了另一种讨论：考虑一个简单的方法来计算BMI：

CalculateBMI(weight,height)
{
  System.out.println("BMI: " + (( weight / height ) x 703));
}

在这种情况下，我会反对这种风格，因为体重和身高是相关的。当它们不是时，该方法“传达”这是两个单独的值。您何时会用一个人的体重和另一个人的身高来计算BMI？这是没有道理的。

CalculateBMI(Person)
{
  System.out.println("BMI: " + (( Person.weight / Person.height ) x 703));
}

更加有意义，因为现在您可以清楚地说明身高和体重来自同一来源。

返回多个值也是如此。如果它们明确连接，则返回整洁的小包装并使用对象（如果它们未返回多个值）。

坦率地说，这种文化是Java程序员最初倾向于来自大学，那里教授面向对象的原理和可持续的软件设计原理。

正如ErikE在回答中用更多的话说的那样，您似乎并没有编写可持续的代码。我从您的示例中看到的是，存在一个非常尴尬的问题缠结。

在Java文化中，您将倾向于了解可用的库，这将使您获得比现成的编程更多的功能。因此，您将需要针对在硬核工业环境中尝试过并经过测试的设计模式和样式进行特殊处理。

但是正如您所说，这并非没有缺点：今天，使用Java已有10多年的时间，我倾向于使用Node / Javascript或Go进行新项目，因为两者都可以加快开发速度，而微服务风格的体系结构则可以通常就足够了。从Google最初大量使用Java的事实来看，但它一直是Go的创始者，我想他们可能也在这么做。但是，即使我现在使用Go和Javascript，我仍然使用多年使用和理解Java所获得的许多设计技能。