当前位置：文江博客话题详情

代码标准 - 即使从未使用过getter/setter，也更好吗？

发布于 2025-02-02 19:16:32 字数 123 浏览 2 评论 0原文

IDE建议将Getter/Setter添加到私有字段。它从未使用过，并且到达场地仅来自班级。

首选的编码样式是什么？保持从未使用的方法？

我特别询问有关Java/Kotlin的问题，但这是一个普遍的问题

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

在你怀里撒娇 2025-02-09 19:16:34

您需要了解一些区别，以便自己回答这个问题，因为这取决于很多事情。太多要要求的东西要写下：

对于整个答案，考虑代码层之间的区别很重要。如果您在思考层时您想象的项目是否很小并且仅由您自己编写，那么这些层是否会有点困难。因此，不要这样做 - 考虑一下Microsoft Word作为产品。它是由许多人撰写的，多年来 - 整个部门和开发团队。这有点模块化（有一个“邮件合并”系统与“可用字体”下拉列表完全不相互作用）。

首先，整个`私有`字段，`public` getters/setters首先是什么？

场是高度僵化的构造。如果您“公开”它们（将其公开），那么您没有可用的粒度。您可以扭曲的唯一旋钮是：

您可以使一个场地无法改变每个人 - 您不能更改它，也不能改变其他任何人。（为此，将其标记为final）。

就是这样。您不能做任何其他事情。您无法对访问权进行更多的细粒度控制（例如允许代码“附近”更改它，但不能进一步更改代码），您也不能像字段写入/读取一样运行某些代码。也许您需要更多的粒度。请记住，我们正在尝试编写将在有100名程序员的环境中生存10年的代码，其中大多数在许多不同的团队中都不会持续10年。因此，想象一下您想：

使其成为每个人都可以阅读的字段，但只有“您的”代码（也就是说，在代码库的这个特定角落工作的程序员知道这个特定角落的规则和需求）应该得到改变。
使其成为每个人都必须阅读的字段，和写入，但是，如果不是“您的”代码进行写作，则应发出日志行。
使其成为一个没有人能写作的领域（甚至不是您 - 它是在对象创建时初始化的，就是这样，使我们更容易推理Abou，这就是为什么我们自己“戴上戴上”自己：当您需要维护10年的代码时，某些事情关闭并拥有执行这些的编译器非常有用），并且“局外人” can 可以阅读，但是您想对阅读进行一些调整，例如，当您的“当前日期”替换值是空白的。

等等。

更重要的是，时间：有时您开始只想向所有人展示一个领域，但是后来您意识到：哦，等等，我们需要发出一条日志线。或者：糟糕，如果值为空白，我们需要返回当前日期。

如果您只制作一个字段public，那么您：

没有任何粒度。
即使您现在还可以，也无法以后更新代码并添加需要这种粒度的东西；并非没有将字段变成getter/setter对，也不是不是向后兼容：您需要将邮件发送给那些100个开发人员或开始重构其代码，这是一项巨大的工作。

因此，即使您现在看不到任何要点或目的，即现在给您粒度权力，它仍然是，建议只制作该字段私有并添加Geters and Setter：这样，如果以后在某些当前不可预见请求（例如：记录以下内容），请登录该字段，请！），您可以添加该功能必须要求所有其他100个开发人员进行更改并编辑所有分支机构，这是一项艰巨的任务。

Yagni

在编程世界中的格言是Yagni-您不需要它。

Yagni是危险的野兽 - 它适用于半本地努力。

Yagni的基本原理是：代码是一个流动的概念，您应该毫不犹豫地进行改进，尤其是如果您想不出这种方式会破坏任何现有用法。因此，鉴于您的开发过程应该设置为以使添加内容很容易，请不要添加内容，直到您需要 - 毕竟，即使您当前不需要它，也可能永远不需要它而且您现在只是出于没有充分的理由堵塞代码。 如果有人需要它，则可以毫无疑问地添加它。

Yagni的问题在于谓词：Yagni基于以下观点：进行更改是快速而无痛的。

想象一下这种情况：Microsoft Office开发人员决定编写自己的字体渲染系统，因为Windows提供的内容在HIDPI屏幕上看起来很糟糕。因此，他们花费大量时间和研究，并大大发行了新版本。每个人都喜欢它。

操作系统团队来了，MS Office团队决定将新的字体渲染引擎“移交” OS团队。为了避免有2个团队将资源花在维护它上，下一个版本的MS Office只能使用包括新管道的新版本的OS运行，因此，MS Office团队删除了字体从中 - 现在是操作系统的工作。

哎呀，任何yagni现在都是一个很大的问题：如果有可能的事物可预见，MSOFFICE团队需要他们不添加的东西（或者Windows OS团队将Yagni应用于API，他们将其暴露于应用程序中以进行字体渲染的内容），则然后，MS Office团队需要打电话给另一个国家的Windows OS团队，进行其他源控制，并具有完全不同的版本使用管道，并要求他们进行更改。这一切都需要2年才能完成。

衬里/式造型器是工具，而且相当愚蠢的是，

有关样式或有关更改建议的任何警告就是这样的建议。这些工具不是完美的，并且绝对会不时提出非常愚蠢的事情。您应该永远不要在了解为什么给出并应遵循哪些情况下进行建议，并且您应该随时告诉林语/造型机，如果他们错了，请嗡嗡作响。

一些开发商店制定了绝对主义者规则（“您永远无法签入使我们的林格工具失败的代码 - 我们的git提交挂钩之前！”），但是这些商店被误导了：他们似乎认为，如果您只能严格应用足够的应用，因此，该代码的样式规则将写得很好，没有错误和性能。这显然是完全错误的。您应该绝对帮助程序员（甚至可能会轻轻地强制执行）来帮助自己，并利用可用的工具来编写更好的代码，但是可以这么说，您不能击败鸟来唱歌。

因此，请注意，有时候，关于样式建议的最好的事情就是忽略它。

回到您的问题上

，现在您知道当我提出这些问题时我在开车，这自然会导致您回答自己的问题：

该领域甚至是首先要暴露的吗？您可能“暴露”的任何东西都可能由与您相对远距离删除的代码（不同的团队，不同的时间，不同的上下文）使用，并且一旦公开它，您就必须继续支持它 - 任何您所做的更改都无法从根本上更改/删除您暴露的内容。因此，也许只有一个私有没有getters和setter的字段是最好的起点：
如果您确定公开它是没有意义的，那就不要。只需将它们作为私有字段，此源文件中的代码可以编辑它们，而其他代码甚至不能假定存在此字段 - 他们对此一无所知。
如果您确定揭露它是很有意义的；这是班级的重点，然后与公共Getter一起制作一个私人领域（如果您愿意，Setter-您打算让它变得可变？） - 即使您看不到任何需要特别的需要塞在那个getter中。 Java程序员期望通过Geters和setter从其他源文件访问属性，并且您可以保持稍后更改内容而不会破坏兼容性的灵活性。
如果您不确定，那就想一想Yagni：这是将要暴露到远的API，它将影响无法轻易修改代码库的人吗？然后，对不起，您将不得不考虑更多并做出决定。但是，很可能您不是编写这种代码，任何可能想访问此内容的人都可以很容易地更改代码：它将是您，或者是在同一源树中工作的同事。在这种情况下，不要考虑太久 - 在谨慎的一边，不要让人呆滞。如果某人以后需要EM，那么，让他们打电话 - 在他们现在拥有的用例中受益，他们更有可能做出明智的决定，而没有您的好处。

There are a few distinctions that you need to know about to answer this question yourself - as it depends on a ton of things; far too much to ask for and for you to write down:

For this entire answer it's important to think about the distinction between layers of code. These layers can be a bit hard to think about if the project you're imagining when thinking about layers is something small and written just by yourself. So don't do that - think about, say, Microsoft Word as a product. It's written by many people, over many years - entire departments and dev teams. It's somewhat modular (there's the "Mail Merge" system that doesn't interact, at all, with the 'show available fonts' dropdown).

What's the whole `private` fields, `public` getters/setters all about in the first place?

Fields are highly inflexible constructs. If you 'expose' them (make it public), then there is no granularity available to you. The only knobs you can twiddle with is:

You can make a field unchangable for everybody - you can't change it, nor can anybody else. (To do this, mark it final).

That's it. You can't do anything else 'to' it. You can't have more fine grained control about access (such as allowing code 'nearby' to change it, but not code further out), you can't run some code as field writes/read happen either. Perhaps you need more granularity. Keep in mind that we're trying to wrote code that will survive 10 years in an environment with 100 programmers, most of whom won't last the entire 10 years, in many different teams. So, imagine you wanted to:

Make it a field that everybody gets to read, but only 'your' code (that is, the programmers working on this particular corner of the codebase who are aware of this particular corner's rules and needs) should get to change.
Make it a field that everybody gets to read, and write, but, if its not 'your' code doing the writing, a log line should be emitted.
Make it a field that nobody gets to write (not even you - it is initialized at object creation, that's it, makes it easier to reason abou, that's why we 'handcuff' ourselves: When you need to maintain code for 10 years, limiting certain things off and having a compiler that enforces these is quite useful), and 'outsiders' can read, but you want to tweak the read a bit, for example, substitute 'the current date' when the value is blank.

And so on.

Even more importantly, is time: Sometimes you start out just wanting to expose a field to everybody right now, but later on you realize: Oh, wait, we need to emit a log line. Or: Oops, we need to return the current date if the value is blank.

If you just make a field public, you:

Do not have any of that granularity.
Even if you're okay with that now, you can't later on update your code and add stuff that needs this granularity; not without turning the field into a getter/setter pair, and that is not backwards compatible: You need to send a mail to those 100 developers or start refactoring their code which is a huge undertaking.

Hence, even if you don't see any point or purpose in giving you the granularity powers right now, it's still advised to just make that field private and add getters and setters: That way if later on some currently not forseeable request comes in (such as: Log the writes to this field, please!), you can add that feature without having to ask all other 100 developers to pull the change and edit all their branches, which is a huge undertaking.

YAGNI

A maxim in the programming world is YAGNI - You aren't gonna need it.

YAGNI is a dangerous beast - it applies -solely- to semi-local endeavours.

The basic principle of YAGNI is: Code is a flowing concept, and you should never hesitate to make improvements, especially if you can't think of a way this would break any existing usage. Hence, given that your development processes should be set up such that adding stuff is easy, don't add stuff until you need it - after all, if you add stuff even if you don't currently need it, maybe you never need it and you're now just clogging up the code for no good reason. IF somebody needs it, they can trivially add it then.

The problem with YAGNI is that predicate: YAGNI is based on the notion that making a change is quick and painless.

Imagine this scenario: The Microsoft Office development crew decides to write their own font rendering system, because what windows delivers just looks bad on HiDPI screens. So, they spend a ton of time and research on this and with much fanfare release a new version. Everybody loves it.

The OS team comes aknocking and the MS Office team decides to 'hand over' the new font rendering engine to the OS team. In order to avoid having 2 teams spend the resources on maintaining it, the next version of MS Office is pegged to only run on a new version of the OS that includes the new pipeline, and thus, the MS Office team removes the font rendering engine from it - it's now the OS's job.

Whoops, any YAGNI is now quite a big problem: If there's something foreseeable and obvious the MSOffice team needed that they didn't add (or if the Windows OS team applied YAGNI to the API they expose to apps to do font rendering stuff), then the MS Office team needs to give a call to the Windows OS team that's in another country, working on other source control, and having entirely different versioning pipelines, and ask them for a change. It'll take 2 years before it's all said and done.

Linters/stylcheckers are tools, and fairly stupid ones at that

Any warning about style or suggestion about changes are just that - suggestions. These tools aren't perfect, and will absolutely suggest very silly things from time to time. You should never apply style advice until you understand why it is given and under what circumstances it should be followed, and you should feel free to tell linters/stylecheckers to buzz off if they are wrong.

Some dev shops put out absolutist rules ('you can NEVER check in code that fails our linter tool - we have git commit hooks that enfore this!'), but those shops are misguided: They seem to think that if only you rigorously apply enough style rules, that code will therefore be well written, bug free, and performant. This is obviously entirely false. You should absolutely help programmers (and might lightly enforce this even) to help themselves and avail themselves of the tools available to write better code, but you can't beat the bird to make it sing, so to speak.

Thus, be aware that sometimes the best thing to do about a style suggestion - is to ignore it.

Back to your question

So, now you know what I'm driving at when I ask these questions, which naturally lead you to answering your own question:

Is the field even meant to be exposed in the first place? Anything you 'expose' is likely to be used by code that's relatively far removed from you (different team, different time, different context), and once you expose it, you have to continue to support it - any changes you make can't fundamentally change/remove what you exposed. So, perhaps just having a private field with no getters and setters is the best place to start:
If you're sure it makes no sense to expose it, then don't. Just leave them as private fields, the code in this source file can edit them, and other code cannot even assume this field exists - they should know nothing about it.
If you're sure it makes perfect sense to expose it; it is the very point of the class, then make a private field with public getter (and if you want, setter - do you intend for it to be mutable or not?) - even if you don't see any need to do special stuff in that getter. Java programmers expect to access properties from other source files via getters and setters and you keep the flexibility to change things later without breaking compatibility.
If you're not sure, then think about YAGNI: Is this an API that is going to be exposed so far and wide it'll affect people who cannot easily modify the codebase? Then, sorry, you're going to have to think some more and make a decision. But most likely you're not writing that kind of code, and anybody who might want to access this thing could change the code fairly easily: It'll be you, or a colleague working in the same source tree. In which case, don't think about it too long - err on the side of caution and don't make getters and setters. If someone needs em later, well, let them make the call - with the benefit of that use case they now have, they'll be more likely to make a well informed decision than you can, without that benefit.

回复收藏 0 原文

~没有更多了~