TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Better Java

17 点作者 bqe大约 11 年前

3 条评论

ajanuary大约 11 年前
Using public fields could be a bad idea if on classes that are exposed to third parties because it prevents you from changing it to a calculated field while keeping compatibility. However, this is going to be a very small number of classes.<p>Personally I have a small Tuple class I use for small immutable data holder objects that automatically implements hashCode and equals:<p><pre><code> public final class DataHolder extends Tuple2&lt;String, Integer&gt; { public DataHolder(String data, Integer value) { super(data, value); } public String data() { return get(0); } public Integer value() { return get(1); } } </code></pre> Obviously there&#x27;s a bunch of limitations: you can&#x27;t use primitive data types, and it doesn&#x27;t really scale past 3 or 4 fields, and can get hairy when you have multiple fields of the same type. It&#x27;s easy to graduate once you get to that point though.
skybrian大约 11 年前
I disagree on Util classes. They&#x27;re fine so long as they&#x27;re as well-tested as regular code and divided up by the libraries they depend on. (Put all your IO utils in one place, all your database utils in another, and so on.) Guava has lots of nice utility methods for Maps, Lists, streams, and so on.
评论 #7769690 未加载
Fishkins大约 11 年前
Mostly good advice. I&#x27;m surprised he talked about Joda Time and Java 8 without mentioning Joda Time is (essentially) included in Java 8.