Question

我对Java风格有疑问。我已经编程Java多年了，但主要是出于我自己的目的，在那里我不必担心风格，但我只是没有找到一份工作，我必须专业地使用它。我问，因为我要让人们第一次真正查看我的代码，我想看起来我知道自己在做什么。嘿。

我正在开发一个其他人会在我的工作中使用的图书馆。其他代码使用我的库的方式主要是实例化主类，也可以调用一两个方法。他们不必使用我的任何数据结构，或者我在后台使用的任何类来完成任务。我可能会成为维护这个库的主要人物，但是其他人可能偶尔会查看代码。

因此，当我编写这个库时，我只使用了大多数字段的默认无修饰符访问级别，甚至还有其他类偶尔会读取并可能直接从/向这些字段写入。由于这是在我的包中，这似乎是一种可行的方法，因为这些字段不会从包外看到，并且似乎没有必要将事物设为私有并提供getter和setter。除了我之外，没有人会在我的包中编写代码，这是封闭源代码等。

我的问题是：对于其他Java程序员来说，这看起来是不好的风格吗？即使我确切地知道将要获得什么以及设置我的字段，我是否应该提供getter和setter？我不担心别人会写一些会破坏我的代码的东西吗？

Answer 1

即使在封闭源代码包中，封装也是一个好主意。

想象一下，你的包中的一堆类正在访问一个特定的属性，你意识到你需要缓存该属性，或者记录对它的所有访问，或者从实际存储的值切换到你的值即时生成。你必须改变许多真正不应该改变的课程。您将类的内部工作暴露给其他不需要了解这些内部工作的类。

Answer 2

我会坚持一种共同的风格（在这种情况下提供setter / getters）。为什么？

当您与其他人合作或为第三方提供图书馆时，这是一种很好的做法
许多Java框架都假设getter / setter约定，并且不能查找这些/暴露它们/查询它们。如果不这样做，那么Java对象将从这些框架和库中关闭。
如果您使用setter / getters，您可以轻松地重构它们背后的内容。仅使用这些字段会限制您执行此操作的能力。

采用“仅适合我”的方法真的很诱人，但很多惯例都存在，因为东西会利用它们，和/或出于某种原因是好的做法。我会尝试尽可能地遵循这些。

Answer 3

我不认为好的语言应该具有除私人之外的任何访问级别 - 我不确定我是否看到了这种好处。

另一方面，也要小心吸气剂和制定者 - 他们有很多陷阱：

他们倾向于鼓励糟糕的OO设计（你通常想要让你的对象为你做一些事情，而不是根据它的属性行事）
这种糟糕的OO设计导致与您的对象相关的代码散布在不同的对象周围，并且经常导致重复。
setters使你的对象变得可变（如果可以的话，总是很好的避免）
setter和getter暴露你的内部结构（如果你有一个int的getter，以后很难将它改为double - 你必须触摸它所访问的每个地方并确保它可以处理一个double而不会溢出/导致错误，如果您刚刚要求您的对象操作该值，那么唯一的更改将是您对象的内部。

Answer 4

大多数Java开发人员更愿意看到getter和setter。

没有人可能在您的软件包中开发代码，但其他正在使用。通过公开显式公共接口，您可以保证外部消费者按预期使用您的界面。

如果公开公开课程的内部实施：

不可能阻止消费者不恰当地使用课程
对进入/退出点失去控制;任何公共领域都可能随时发生变异
增加内部实施与外部消费者之间的耦合

维持吸气剂和孵化器可能需要更多时间，但提供更多安全性：

您可以随时重构您的代码，只要您不破坏公共API（getter，setter和公共方法）
单元测试封装良好的类更容易 - 您测试公共接口就是这样（只是您对“黑匣子”的输入/输出）
继承，组合和界面设计都会变得更有意义，并且更容易使用解耦类进行设计
决定你需要在设置之前为mutator添加一些验证吗？一个好地方是在一个二传手。

由您自行决定是否值得增加时间。

Answer 5

我不太关心样式本身（或任何类型的教条），而是一系列getter / setter方法带来的可维护性的便利性。如果您（或其他人）以后需要更改与更改其中一个属性相关联的行为（记录更改，使其成为线程安全，清理输入等），但已经在许多其他属性中直接修改它们在你的代码中，你会希望你使用getter和setter方法。

Answer 6

由于你是唯一一个在闭源软件包/库中编写代码的人，我认为你不应该过多担心风格 - 只做最适合你的事情。

然而，对我来说，我尽量避免直接访问字段，因为它会使代码更难以维护和阅读 - 即使我是唯一的维护者。

Answer 7

风格是一个惯例问题。只要它是一致的，就没有正确的答案。

我不是骆驼的粉丝，但在Java世界中，camelStyle规则至上，所有成员变量都应该是私有的。

getData();
setData(int i);

遵循Sun的官方Java代码约定（ cough Oracle），你应该没问题。

http://java.sun.com/docs/codeconv/

Answer 8

我非常不愿意使用除私有字段之外的任何内容进行代码审查，除了受保护的字段以外，为了子类的利益。它不会让你看起来很好。

当然，我认为从Java专家的角度来看，你可以证明偏离风格是合理的，但由于这是你第一次使用Java的专业工作，你并不是真正处于这个位置。

所以直接回答你的问题：“看起来这样的风格会不好？”是的，它会。

你的决定合理吗？只有你真的相信这段代码不会去任何地方。在典型的商店中，可能有机会重用代码，将事物分解为实用程序类等。如果没有重大更改，此代码将不是候选者。其中一些更改可以通过IDE自动执行，并且基本上风险较低，但如果您的库处于稳定，测试并在生产中使用的位置，那么稍后封装将被视为比所需更大的风险。 / p>

Answer 9

简而言之，你说“我在问，因为我要让人们第一次真正检查我的代码，我想看起来我知道我在做什么”。因此，更改您的代码，因为它确实使您看起来不知道自己在做什么。

你提出它的事实表明你知道它可能看起来很糟糕（这是一件好事），而且确实如此。正如已经提到的那样，为了权宜之计，你正在打破OO设计的基础。这只会导致脆弱且通常无法维护的代码。

Answer 10

打破封装是一个坏主意。所有字段都应该是私有的。否则，类本身不能确保保留自己的不变量，因为其他类可能会以错误的方式意外修改字段。

拥有所有领域的getter和setter也是一个坏主意。具有getter和setter的字段与公共字段几乎相同 - 它公开了类的实现细节并增加了耦合。使用这些getter和setter的代码很容易违反OO原则，代码变得程序化。

应编写代码，使其跟随Tell Don't Ask。例如，您可以通过Object Calisthenics练习来练习它。

Answer 11

即使这很痛苦，如果您打算在JSP（特别是表达式语言），OGNL或其他模板语言等环境中使用您的对象，那么使用getter和setter编写属性是一个很大的胜利。如果你的对象遵循良好的旧Bean约定，那么很多东西将在以后“正常工作”。

Answer 12

我发现getter和setter是更好的编程方式，而不仅仅是编码约定问题。没有人知道未来，所以今天我们可以写一个简单的字符串，但明天我们可能要在区号和数字之间加上“ - ”，在这种情况下，如果我们定义了getPhonenumber（）方法，我们可以做这样的美化非常容易。所以我想，我们总是应该遵循这种编码风格以获得更好的可扩展性。

Answer 13

有时我会使用public final属性w / o get / setter来获取只携带一些数据的短生命对象（并且在设计时绝不会做任何其他事情）。

一旦这样，我真的很喜欢Java暗示使用property关键字创建的getter和setter ......

Answer 14

正如JacobM已经指出的那样，使用封装是一个好主意，即使对于封闭源也是如此。但是，如果您的代码充当其他应用程序的库，则无法阻止其他应用程序访问为内部使用而定义的类。换句话说，您不能（？）强制限制公共类X只能由我的应用程序中的类使用。

这是我喜欢Eclipse插件架构的地方，你可以说我的插件中的哪些包可以在运行时依赖插件访问。 JSR 277旨在为JDK带来这种模块化功能，但它现在已经死了。在这里阅读更多相关信息， http://neilbartlett.name/blog/2008/12/08/hope-fear-and-project-jigsaw/

现在唯一的选择似乎是OSGi。

Answer 15

尽管我很清楚在任何情况下在任何地方都使用getter和setter的共同压力，并且代码审查过程让我别无选择，但我仍然不相信这种想法的通用性。

对于数据承载类来说，其原因是经过十多年的发展，对于我而言，从来没有一个案例可以写很多不同于在setter中设置变量并在getter中读取变量的东西。已经花费在生成，理解和维护这个似乎没有任何意义的货物崇拜代码上。

数据类是结构或记录，而不是类。它本身不做任何事情。其他班级正在对此进行更改。它根本不应该有任何功能，更不要说设置器或获取器中的功能了。对于可能没有方法的多字段数据记录，Java可能需要一个单独的关键字。

从另一方面来看，现在的过程似乎已经走到了很远，从开始甚至是第一次加入新团队开始就将吸气剂和塞脂剂放进去很有意义。重要的是不要与团队冲突。

Java getter / setter样式问题

15 个答案: