blocks|key|3747801|text|问题在于统一访问原则。稍后您可能需要修改foo，以便通过方法获得它，而不是修复它。如果您公开了字段而不是getter，则需要中断您的API。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3747802|entityMap^0|K|3|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

The problem is the uniform access principle. You may later need to modify <code>foo</code> so that it's obtained through a method instead of being fixed, and if you exposed the field instead of a getter, you'll need to break your API.

blocks|key|1848001|text|我会做你认为最简单和最清晰的事情。如果您有一个仅由有限数量的类使用的数据值类。尤指软件包的本地类。然后，我将避免使用getter/getter，而使用包的本地或公共字段。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1848002|如果你有一个希望其他模块/开发人员使用的类，那么从长远来看，遵循getter/setter模型可能是一种更安全的方法。|1848003|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I would do what you believe is simplest and clearest. If you have a data value class which is only used by a restricted number of classes. esp a package local class. then I would avoid getter/setters and use package local or public fields.

If you have a class which you expect other modules/developers to use, following a getter/setter model may be a safer approach in the long run.

blocks|key|1848039|text|现在还不清楚是否有人会通过API使用你的代码。如果您稍后需要验证输入，那么您也将错失验证输入的机会。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1848040|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It is not very clear if someone is going to use your code through an API.
You are also missing an opportunity to validate the input, if you are going to require some later.

blocks|key|3747934|text|这个答案被省略了：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3747935|好呀|3747936|interface+Immu+{+String+getA()+;+String+getB+(+)+}

Immu+immu+(+final+String+a+,+final+String+b+)
{
+++++++/*+validation+of+a+and+b+*/
+++++++return+new+Immu+(+)
+++++++{
++++++++++++++public+String+getA+(+)+{+return+a+;+}

++++++++++++++public+String+getB+(+)+{+return+b+;+}
+++++++}
}|code-block|syntax|javascript|3747937|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

This answer is obviated:

Why not

<pre><code>interface Immu { String getA() ; String getB ( ) }

Immu immu ( final String a , final String b )
{
 /* validation of a and b */
 return new Immu ( )
 {
 public String getA ( ) { return a ; }

 public String getB ( ) { return b ; }
 }
}
</code></pre>

blocks|key|155763|text|我在home项目中对类使用public-final-field+(反？)模式，这些类基本上是带有构造函数的不可变数据结构，如果需要，还可以使用equals()、hashCode()、toString()等绝对基础。(我避免使用"struct“这个词，因为它有各种不同的语言解释。)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|155764|我不会把这种方法带到别人的代码库(工作，公共项目等)，因为它可能会与其他代码不一致，并且像在罗马或最不令人惊讶的原则优先。|155765|也就是说，对于Daniel+C.Sobral和aioobe的回答，我的态度是，如果类设计因为不可预见的发展而成为问题，那么在IDE中私有字段和添加访问器只需30秒，修复损坏的引用不会超过5到10分钟，除非有数百个引用。任何失败的结果都会得到单元测试，它应该放在第一个位置。|155766|编辑:+Effective非常坚决地反对这个想法，同时指出它在不可变字段上“危害较小”。|155767|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I use the public-final-field (anti?)pattern on home projects for classes which are basically an immutable data structure with a constructor, along with absolute basics like equals(), hashCode(), toString(), etc. if required. (I'm avoiding the word "struct" because of the various different language interpretations of it.) 

I wouldn't bring this approach to someone else's codebase (work, public project, etc) because it would likely be inconsistent with other code, and principles like When In Rome or Least Surprise take priority.

That said, with regard to Daniel C. Sobral's and aioobe's answers, my attitude is that if the class design becomes a problem because of unforeseen developments, it's the work of 30 seconds in an IDE to privatise the fields and add accessors, and no more than 5 or 10 minutes to fix broken references unless there are hundreds of them. Anything that fails as a result gets the unit test it should have had in the first place.:-)

[Edit: Effective Java is quite firmly against the idea, while noting that it's "less harmful" on immutable fields.]

blocks|key|3462725|text|我发现这个帖子希望得到一些实际的论点，但我在这里看到的答案对我没有太大帮助。经过进一步的研究和思考，我认为必须考虑以下几点：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3462726|对于不可变的类型，|3462727|public+final看起来是最干净的。访问器可以改变headaches.|unordered-list-item|offset|length|style|CODE|3462728|There的可变类型，即使这不是故意的--在并发环境中，这可能会导致很多|3462729|没有参数的构造函数。如果你需要工厂方法(例如LMAX+Disruptor)，这一点很重要。以类似的方式，通过反射实例化对象变得更加complicated.|3462730|Getters，setter可能会产生副作用。使用public+final清楚地告诉程序员没有发生隐藏的魔术，对象天生就是哑巴：)|3462731|您不能向访问器返回包装器或派生类实例。不过，在为该字段赋值时，您应该知道这一点。在我看来，容器类不应该关心返回给谁的内容。|3462732|3462733|如果您处于开发中期，并且没有指导方针阻止您，并且项目是孤立的，或者您可以控制所有涉及到的项目，我建议您对不可变类型使用public+final。如果您稍后决定需要getter，Eclipse提供了Refactor+->+Encapsulate+Field...，它可以自动创建这些getter并调整对该字段的所有引用。|3462734|entityMap^0|0|0|0|C|0|0|0|P|C|0|0|0|1N|C|2Q|8|32|K|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Z|8|@$G|10|H|11|I|J]]|9|@]|A|$]]|$1|K|3|L|5|F|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|14|8|@$G|15|H|16|I|J]]|9|@]|A|$]]|$1|Q|3|R|5|F|7|17|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|19|8|@$G|1A|H|1B|I|J]|$G|1C|H|1D|I|J]|$G|1E|H|1F|I|J]]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|W|$]]

I found this thread hoping for some actual arguments, but the answers I've seen here didn't help me all that much. After some more research and thinking I think the following has to be considered:

<ul>
<li><code>public final</code> looks cleanest for immutable types.</li>
<li>Mutable types could be altered by accessors even if this is not intended - in concurrent environments this could lead to a lot of headaches.</li>
<li>There can be no no-arguments constructor. This is importent if you need factory methods (e.g. for LMAX Disruptor). In a similar way instantiating your objects via reflection becomes more complicated.</li>
<li>Getters and setters can have side effects. Using <code>public final</code> clearly tells the programmer that no hidden magic is occuring and the object is inherently dumb :)</li>
<li>You can't return a wrapper or a derived class instance to the accessor. Then again, this is something you should know about when the field is assigned its value. In my opinion container classes should not be concerned about what to return to whom.</li>
</ul>

If you're mid development and no guideline is stopping you and the project is isolated or you have control over all involved projects I'd suggest using <code>public final</code> for immutable types. If you decide you need getters later on, Eclipse offers <code>Refactor</code> -> <code>Encapsulate Field...</code> which automatically creates these and adjusts all references to the field.

blocks|key|1848229|text|忘记封装、不变性、优化和所有其他重要的词吧。如果你想写好的java代码，我建议你仅仅使用getter，因为它是java友好的，最重要的是，它节省了大量的时间来搜索原因。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1848230|例如，您可能不希望在编写代码时使用流，但后来您发现|1848231|listOfImmus.stream().map(immu+->+imm.foo).collect(Collectors.toSet());+//+with+field
listOfImmus.stream().map(Immu::getFoo).collect(Collectors.toSet());++++//+with+getter

Supplier<String>+s+=+()+->+immu.foo;++//+with+field
Supplier<String>+s+=+immu::foo;+//+with+getter

//+final+fields+are+hard+to+mock+if+not+impossible.+
Mockito.when(immuMock.getFoo()).thenReturn("what+ever");

//one+day,+your+code+is+used+in+a+java+Beans+which+requires+setter+getter..
¯\_(ツ)_/¯|code-block|syntax|javascript|1848232|这个列表可能很长，也可能很短，也可能对你的用例没有任何意义。但是你必须花时间说服你自己(或者你的代码审查者)，为什么你可以或者应该反对java的正统。|1848233|最好只编写getter/setter，然后把时间花在更有用的事情上:比如抱怨java|1848234|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Forget about encapsulation, immutability, optimization and all other big words. If you are trying to write good java code, I would recommend you just use getter simply because it is java friendly, and most importantly it saves ton of time googling why. 

For example, you probably would not expect using streams when you write the code, but later you found

<pre class="lang-java prettyprint-override"><code>listOfImmus.stream().map(immu -&gt; imm.foo).collect(Collectors.toSet()); // with field
listOfImmus.stream().map(Immu::getFoo).collect(Collectors.toSet()); // with getter

Supplier&lt;String&gt; s = () -&gt; immu.foo; // with field
Supplier&lt;String&gt; s = immu::foo; // with getter

// final fields are hard to mock if not impossible. 
Mockito.when(immuMock.getFoo()).thenReturn("what ever");

//one day, your code is used in a java Beans which requires setter getter..
¯\_(ツ)_/¯

</code></pre>

This list can be long or short or may be none of them makes any sense to your use case. But you have to spend time convincing yourself (or your code reviewers) why you can or should rebel against java orthodoxy. 

It is better to just write the getter/setter and spent the time for something more useful: like complaining java

blocks|key|156227|text|对于这样小的任务，使用public+final可能很好，但它不能被改编为标准的实践，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|156228|考虑一下下面的情况。|156229|Public+class+Portfolio+{
+++public+final+String[]+stocks;
}|code-block|syntax|javascript|156230|当然，这个对象是不可变的，它被初始化为vis构造函数，然后被直接访问。我必须告诉你它的问题所在吗？这是显而易见的！|156231|考虑你的客户编写如下代码-|156232|Portfolio+portfolio+=+PortfolioManager.get(“Anand”);
Portfolio.stocks[0]+=+“FB”;
portfolio.calculate();|156233|这可行吗？你的客户端库能够操纵你的对象的状态，或者更确切地说，能够在你的运行时表示中破解。这是一个巨大的安全风险，当然像声纳这样的工具会预先捕捉到它。但是只有当你使用getter-setter时，它才是可管理的。|156234|如果您正在使用getter，那么您可以很好地编写|156235|+++Public+class+Portfolio+{
++++++private+final+String[]+stocks;
++++++public+String[]+getStocks()+{
++++++++++return+Arrays.coptOf(this.stocks);
++++++}
+++}|156236|这可以防止您受到潜在的安全威胁。|156237|查看上面的示例，如果您使用数组，则强烈建议您使用public+final+。在这种情况下，它不能成为标准。像我这样的人，不会使用不能成为所有数据类型的统一标准的代码实践。你呢？|offset|length|style|BOLD|CODE|156238|entityMap^0|0|0|0|0|0|0|0|0|0|0|O|C|O|C|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|16|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|17|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|18|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|19|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|1A|8|@]|9|@]|A|$G|H]]|$1|O|3|P|5|6|7|1B|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1C|8|@]|9|@]|A|$]]|$1|S|3|T|5|F|7|1D|8|@]|9|@]|A|$G|H]]|$1|U|3|V|5|6|7|1E|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1F|8|@$Y|1G|Z|1H|10|11]|$Y|1I|Z|1J|10|12]]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|14|$]]

Using public final may be fine for such small job, but it cannot be adapted as a standard practice, 

Consider the situation below. 

<pre><code>Public class Portfolio {
 public final String[] stocks;
}
</code></pre>

Of course, being immutable, this object is initialized vis constructor, and then accessed directly. Do I have to tell you the problem in it? It’s evident!

Consider your client writing the code like below - 

<pre><code>Portfolio portfolio = PortfolioManager.get(“Anand”);
Portfolio.stocks[0] = “FB”;
portfolio.calculate();
</code></pre>

Is this doable? Your client libraries are able to manipulate the state of your objects, or rather able to hack within your runtime representation. This is a huge security risk, and of course tools like SONAR catch it upfront. But its manageable only if you are using getter-setters.

If you are using getters, you can very well write

<pre><code> Public class Portfolio {
 private final String[] stocks;
 public String[] getStocks() {
 return Arrays.coptOf(this.stocks);
 }
 }
</code></pre>

This prevents you from potential security threat.

Looking at the above example, using <code>public final</code> is strongly discouraged if you are using arrays. In such case, it cannot become a standard. A person like me, will refrain from using a code practice that cannot become a uniform standard across all data types. What about you?

blocks|key|156275|text|从Java+16开始，您可以使用记录。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|156276|public+record+Immu(String+foo,+String+bar)+{}|code-block|syntax|javascript|156277|记录的所有属性都自动是最终的，并且它自动具有像equals(…)和toString()这样的方法以及构造函数。|offset|length|style|CODE|156278|属性的getter与属性具有相同的名称，在本例中，它们是foo()和bar()。|156279|这些方法可以被重写，更多信息请访问in+the+documentation。|156280|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.oracle.com/en/java/javase/16/language/records.html^0|0|0|N|9|X|A|0|S|5|Y|5|0|H|K|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|10|8|@$I|11|J|12|K|L]|$I|13|J|14|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|15|8|@$I|16|J|17|K|L]|$I|18|J|19|K|L]]|9|@]|A|$]]|$1|O|3|P|5|6|7|1A|8|@]|9|@$I|1B|J|1C|1|1D]]|A|$]]|$1|Q|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

Since Java 16, you can use records.
<pre><code>public record Immu(String foo, String bar) {}
</code></pre>
All of a record's attributes are automatically final and it automatically has methods like <code>equals(…)</code> and <code>toString()</code> and the constructor.
The getters of the attributes have the same name as the attributes, in this case, they are <code>foo()</code> and <code>bar()</code>.
The methods can be overridden, more information is <a href="https://docs.oracle.com/en/java/javase/16/language/records.html" rel="nofollow noreferrer">in the documentation</a>.

I need a small Container-Class for storing some Strings which should be immutable. As String itself is an immutable type, I thought of something like that:

<pre><code>public final class Immu
{
 public final String foo;
 public final String bar;

 public Immu(final String foo, final String bar)
 {
 this.foo = foo;
 this.bar = bar;
 }
}
</code></pre>

Many people seem to object using public fields at all and use Getters instead. IMHO this would be just boilerplate in this case, because String itself is immutable.

Other thoughts I may be missing on this one?

Immutable Type: public final fields vs. getter

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我需要一个小的容器类来存储一些应该是不可变的字符串。因为String本身是一个不可变的类型，所以我想到了这样的东西：public final class Immu{  public final String foo;  public final String bar;  public Immu(final String...

问不可变类型: public final字段与getter
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问不可变类型: public final字段与getterEN