房地产的动机是什么？

Question

我有点困惑为什么语言有这些。 我是一名 Java 程序员，在我职业生涯的起步阶段，所以 Java 是我自从真正开始掌握 Java 以来编写的唯一语言。

所以在 Java 中我们当然没有属性，我们编写 getThis() 和 setThat(...) 方法。

拥有房产我们能得到什么？

谢谢。

编辑：另一个查询：具有属性的语言中出现哪些命名约定？

Answer 1

哪一种对你来说看起来更自然？

// A
person.setAge(25)
// B
person.age = 25;
// or
person.Age = 25; //depending on conventions, but that's beside the point

大多数人都会回答B。

这不仅仅是语法糖，在做反射的时候也有帮助； 您实际上可以区分数据和操作，而无需借助方法的名称。

对于那些不熟悉属性的人来说，这里有一个 C# 示例：

class Person
{
    public int Age
    {
        set
        {
            if(value<0)
                throw new ArgumentOutOfRangeException();

            OnChanged();
            age = value;
        }

        get { return age; }
    }

    private int age;
    protected virtual void OnChanged() { // ... }
}

此外，大多数人总是使用属性而不是稍后提升公共成员，这与我们总是使用 get/set 的原因相同； 无需重写绑定到数据成员的旧客户端代码。

Answer 2

语法

button.Location += delta;

比： 好得多：

button.setLocation(button.getLocation() + delta);

Answer 3

编辑：

下面的代码假设您正在手动完成所有操作。 在我的示例世界中，编译器将生成简单的 get/set 方法并将所有直接变量访问转换为这些方法。 如果没有，则必须重新编译客户端代码，这就达不到目的的很大一部分。

原文：

属性的主要论点是，如果您从变量转到方法，它就不需要重新编译代码。

例如：

public class Foo
{
    public int bar;
}

如果我们后来决定验证“bar”，我们需要这样做：

public class Foo
{
    private int bar;

    public void setBar(final int val)
    {
        if(val <= 0)
        {
            throw new IllegalArgumentException("val must be > 0, was: " + val);
        }

        bar = val;
    }

    public int getBar()
    {
        return (bar);
    }
}

但是添加 set/get 方法会破坏所有代码。 如果它是通过属性完成的，那么您将能够在事后添加验证，而不会破坏客户端代码。

我个人不喜欢这个想法 - 我更喜欢使用注释并自动获取简单的 set/get 的想法，并能够根据需要验证您自己的 set/get 实现（但我不喜欢隐藏方法来电）。

Answer 4

两个原因：

1. 干净/简洁的语法； 它
2. 更清楚地向类的用户指示状态（属性）和行为（方法）之间的区别。

Answer 5

在 Java 中，getter 和 setter 本质上是属性。

在其他现代语言（c#）等中，它只是使语法更易于使用/理解。

它们是不必要的，并且在大多数情况下都有解决方法。

这确实是一个偏好问题，但如果您使用的语言支持它们，我建议使用它们:)

Answer 6

一开始我也很挣扎，但我真的开始欣赏他们了。 在我看来，属性允许我以自然的方式与公开的数据进行交互，而不会丢失 getter/setter 方法提供的封装。 换句话说，我可以将我的属性视为字段，但如果我选择不这样做，则不会真正暴露实际字段。 借助 C# 3.0 中的自动属性，对于大多数字段来说，它会变得更好 - 我希望允许消费者读取/写入数据 - 我需要编写的内容甚至更少：

public string Prop { get; set; }

在我想要部分可见性的情况下，我可以限制正是我想要的轻松配件。

public string Prop { get; private set; }

所有这些都可以通过 getter/setter 方法来完成，但措辞要高得多，而且用法也不太自然。

Answer 7

面向对象编程的一般规则是永远不要更改现有的接口。 这确保了虽然调用该对象的对象的内部内容可能发生变化，但不需要知道这一点。

其他语言中的属性是伪装成特定语言功能的方法。 在 Java 中，属性仅通过约定来区分。 虽然一般来说这是可行的，但在某些情况下它会限制您。 例如，有时您会使用 hasSomething 而不是 getSomething 的 isSomething。

因此它允许名称的灵活性，而依赖的工具和其他代码仍然可以区分。

此外，代码可以更加紧凑，并且 get 和 set 按设计分组在一起。

Answer 8

在《面向对象的软件构造 2》中，Bertrand Meyer 将此称为“统一访问原则”，其总体思想是，当属性从简单属性（即整数）变为派生属性（函数）时，调用），使用它的人不必知道。

您不希望使用您的代码的每个人都必须从

int x = foo.y;

进行更改 到

int x = foo.y();

这破坏了封装，因为你没有改变你的“接口”，只是改变了你的“实现”。

Answer 9

您还可以创建派生字段和只读/只写字段。 我在我使用过的语言中看到的大多数属性不仅允许您分配简单的字段，还允许为属性分配完整的功能。

Answer 10

属性提供了一种简单的方法，可以将对象中一组逻辑背后的细节抽象为对外的单个值。

虽然您的属性一开始可能只是一个值，但这种抽象将接口解耦，以便以后可以在影响最小的情况下更改其详细信息。

一般的经验法则是，抽象和松散耦合是好事。 属性是实现两者的模式。

Answer 11

语言级别的属性是一个坏主意。 他们没有良好的约定，并且在代码中隐藏了性能缺陷。

Answer 12

一切都与绑定有关

曾经有一段时间，我认为属性只是语法糖（即通过让开发人员少输入一点来帮助开发人员）。 随着我进行越来越多的 GUI 开发，并开始使用绑定框架（JGoodies、JSR295），我发现语言级别的属性远不止语法糖。

在绑定场景中，您本质上定义了“对象 A 的属性 X 应始终等于对象 B 的属性 Y”的规则。 简写为：Axe <-> 现在

，想象一下您将如何用 Java 实际编写一个绑定库。 目前，绝对不可能直接将“x”或“y”引用为语言原语。 您只能将它们作为字符串引用（并通过反射访问它们）。 实质上，A.“x”<-> B."y"

当您重构代码时，这会导致巨大的问题。

还有其他注意事项，包括正确实施属性更改通知。 如果您查看我的代码，您会发现每个受祝福的 setter 至少需要 3 行来完成非常简单的事情。 另外，这 3 行中的一行还包含另一个字符串：

public void setFoo(Foo foo){
  Foo old = getFoo();
  this.foo = foo;
  changeSupport.firePropertyChange("foo", old, foo);
}

所有这些漂浮在周围的字符串完全是一场噩梦。

现在，想象一下，如果一个财产是该语言的一等公民。 这开始提供几乎无限的可能性（例如，想象一下直接使用 Property 注册一个侦听器，而不必使用 PropertyChangeSupport，并且必须将 3 个神秘方法添加到每个类中）。 想象一下能够将属性本身（不是属性的值，而是 Property 对象）传递到绑定框架中。

对于 Web 层开发人员，想象一个 Web 框架，它可以根据属性本身的名称构建自己的表单 id 值（类似于 registerFormProperties(myObject.firstname, myObject.lastname, someOtherObject.amount)，以允许对象的往返填充现在要做到这一点，您必须传递字符串，并且重构变得令人头痛（一旦您依赖字符串和反射来连接事物，重构实际上变得非常可怕。 ）

所以无论如何，对于我们这些通过绑定处理动态数据更新的人来说，属性是语言中非常需要的功能 - 不仅仅是语法糖。