Question

我不太了解Java Bean的本质。好吧，至少我是如何看待它们在一些通过我们商店的代码库中使用的。

我发现了这个问题：

那里接受的答案让程序员看起来好像滥用Java Bean（我真的不怀疑），但是我觉得这种情况经常发生，故意，我觉得我还在遗漏一些东西。

我看到的代码如下：

public class FooBean {
  private int a;
  private int b;
  private int c;

  public int getA() { return a; }
  public int setA(int x) { a = x; }

  // etc...
}

没有进一步的结构或控制比吸气剂和制定者。是否存在某种超级棒的编译器技巧，包括反射，getter和setter，以及是否需要一些非常笨拙（但编译器优化）的静态关联数组？

或许我完全错过了这一点。：\

干杯！

修改

绝对不会在这里宣传公共领域的想法。

Answer 1

实际上，是的，还有魔力在继续。

这是一个非常愚蠢的模式，但GUI bean（所有组件都是）旨在由GUI构建器进行反射分析。公共集合/获取字段旨在成为用户在构建GUI时可以进行处理的“属性”。

编辑：为了防御太阳，我应该说尽管这个模式非常令人讨厌，因为所有人都复制了它并开始在非bean代码中使用它，它确实允许人们整合类不使用任何外部元数据的GUI构建器。您不需要编辑器的任何XML文件或属性文件，它就像扩展Button并将新对象放到托盘上一样简单。

这种模式已在其他地方使用，正如您所注意到的，它与拥有公共字段几乎相同。我认为这是设置java时创建的最糟糕的模式之一，但没有其他明显的解决方案（我认为整个概念是由第一批尝试在java发布之前构建第一个GUI构建器的人所强调的）。 / p>

现在有一个更好的解决方案：使用注释标记私有字段，反射工具仍然可以分析它们并将它们绑定到构建器控件。这将是一个很好的清洁工具，并不会使你的所有对象都容易受到外部状态变化的影响。

Answer 2

正如您所指出的，Java Beans是一个相当简单的编码约定。

有用的部分是它们完全是一种惯例。这允许构建基于（当时）新颖想法的辅助工具，例如确切地指定getter和setter的名称，以及期望特定方法将存在而不需要归因于接口。这样就可以灵活地做任何你想做的事情，但仍允许你使用GUI来组装bean。

此时，完全内省是常态，其他语言已经形成了获取/设置功能，以及许多其他方式来做Beans所做的事情，我认为这是一个时间已经过去的想法。

Answer 3

人们确实过度使用愚蠢的吸气剂/安装者，毫无疑问。

但是，想象一下，当你意识到，在未来2年内你需要经历多少痛苦您必须在setEmail(string email);方法中删除字符串中的空间，并且所有代码都很难耦合使用公共字段而不是方法调用。

记住面向对象设计的主要规则之一“代码面向接口，而不是实现”。访问类的公共字段肯定是后者，并且将使重构代码更难。

Answer 4

你没有错过这一点。 Getters / Setter很丑陋，但它们被嵌入到许多工具中，这些工具对类/方法/字段名称（例如spring）做出假设（除了它们明显的封装价值之外）它们实际上已经成为一个接近的要求，除非你是在非常有限的私人环境中工作。

Answer 5

如果您想覆盖对数据的访问权限，例如记录/安全性或返回与原始类不同的值，那么'getters'和'setters'就很棒。

Answer 6

没有setter你无法检查不变量：

public void setFoo(Foo foo) { 
     if (foo == null) {
          throw new InvalidFoo();
     }

     this.foo = foo;
}

与公众成员你不能这样做。第二点，在setter中你可以触发其他bean可以监听的事件。最后但同样重要的是，您可以强制执行正确的类型检查（正如您在问题中指出的那样）。

Java Bean：过度的关联数组？

6 个答案: