Java 类和方法 问题
作为一个从头开始学习 Java、懂一点 Python 的人,我一直想知道 Java 中的所有访问修饰符(public、static、protected...)是怎么回事。我知道它们的意思,但为什么要使用它们呢?
这只是困扰我的事情,因为每当我编写一个新类并编写实例变量时,我不断地问自己是否希望这个变量是私有的、公共的、最终的等?我通常得出的结论是我不关心大多数变量和方法。在某些情况下,我知道我需要从另一个类调用该方法,但为什么不将所有方法公开呢?是因为在大型项目中你不能相信另一个开发人员不会开始翻找并弄乱你的代码吗?
As someone learning Java from scratch, who knows a little Python, I have been wondering whats with all the access modifiers (public, static, protected...) in Java. I know what they mean, but why use them?
It's just something that's been bugging me, because whenever I write a new class and I write the instance variables I constantly have to ask myself do I want this variable to be private, public, final etc? I usually come to the conclusion I dont care for the majority of varibles and methods. There are a few instances where I know I will need to call the method from another class, but why not just make all methods public? Is it because in large projects you cant trust another developer isn't going to start rummaging around and messing up your code?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
在每种情况下都使用最小可见性修饰符。例如,几乎在所有情况下字段都应该是私有的。
方法可以是:
这些都与 API 设计相关 - 您希望 API 公开哪些功能,不公开哪些功能。也就是说,哪些方法是您的实现的内部方法,哪些方法应该可供使用您的类来完成其工作的类使用。
所有这一切的优点是,您可以更改私有/包私有方法,除了您自己的类/包依赖它们之外,不需要任何其他人。让他们公开会让你支持他们。不仅当您设计像集合框架这样的 API 时,情况也是如此。当您在自己的项目中设计自己的 API 时也是如此。类必须了解更少的方法(因此更容易更改和支持)。
观看 Joshua Bloch 的有关 API 设计的演示文稿(特别是从 29:00 开始)
Use the minimal visibility modifier in each case. For example fields should be private in almost all cases.
Methods can be:
These all relate to API design - what functionality you want your API to expose and what not. That is - which methods are internal to your implementation, and which should be usable by classes that use your class to do their job.
The advantage of all this is that you can change private/package-private methods without anyone else but your own class/package relying on them. Making them public ties you to supporting them. This is true not only when you are designing an API like the collections framework. It's also true when you design your own API inside your own project. Classes have to be aware of much less methods (and hence are easier to change and support).
See this presentation by Joshua Bloch on API design (specifically from 29:00)
访问修饰符使程序员可以以 OO 方式进行编程,并使用数据封装来编写密封(或尽可能接近)的 API。
同意,这并不总是令人满意的。这就是为什么还有其他选择。
The access modifiers are so programmers can program in an OO way and use data encapsulation to write airtight (or as close as possible) APIs.
Agreed, its not always desirable. Thats why there are other options.
这是一个面向对象的概念。首先,例如,“final”是一个修饰符,它将使该变量成为“常量”,那么如果您需要常量,则必须使用它。当您开始编写现实生活项目时,您将看到这种类型封装的优势。不要低估它。
一个例子是,当您编写一个可能在未来发生变化的方法时。
然后,您的客户将调用 save();而不关心它被保存在哪里
It's an OO concept. First of all, for example, "final" is a modifier that will make that variable a "constant", then if you need a constat you have to use it. When you start coding real life projects you will see the advantage of having this type of encapsulation. Don't understimate it.
A example is when your coding a method that can, for example, change in the future.
Then, your clients will call to save(); without taking care where it gets saved
例如,当您希望能够更新一个库而不需要对代码进行太多更改时,它非常有用。公共方法通常会保留,而私有方法可以更改。如果库作者将所有内容公开,库用户可能会意外地使用此类特定于实现的方法,从而使更新库变得更加困难。
It is, for example, useful when you have a library that you want to be able to update without changing too much in your code. Public methods normally stay while private ones can change. If the library author would make everything public, library users could accidentially use such implementation-specific methods, making updating the library harder.
关键在于您的 API 暴露了多少,以及当您更改它时会破坏多少内容。
私有
代码可以随时更改,并且您知道您只会影响该文件中您自己的代码。默认(包私有),您仍然只影响您自己的代码(某些包欺骗可能除外),但您必须检查更多内容。
protected
:其他人的代码可能正在使用它,但由于它仅限于子类,他们通常可以相当轻松地更新其代码。公共
代码可能被其他人的代码广泛使用。更改此设置可能会迫使其他人在整个项目中修改他们的代码。如果您知道其他人正在使用您的代码,您可能不应该更改这些方法,直到您发布了一些标记为@deprecated
的版本,以便这些人可以更改以更新他们的代码提前打破。It's all about how much of your API is exposed, and therefore how much is going to break when you change it.
private
code can be changed any time you like and you know you'll only be affecting your own code in that one file.default (package private) you're still affecting only your own code (with possible exception of certain package trickery), but you'll have to check more of it.
protected
: other peoples' code may be using it, but since it's limited to subclasses they can usually update their code fairly easily.public
code may be in extensive use by other peoples' code. Changing this may force other people to modify their code all throughout their own project. If you know other people are using your code you probably shouldn't change these methods until you've released a few versions with them marked as@deprecated
so that those people have a change to update their code in advance of it breaking.