使用C＃的get set属性被认为是好习惯吗？

Question

我的问题很简单，就是使用C＃的get set属性被认为是好的，甚至比编写getter和setter方法更好？ 使用这些属性时，是否必须将类数据成员声明为公共？ 我问这是因为我的教授说数据成员永远不应该被公开，因为它被认为是不好的做法。

这个....

class GetSetExample
{
    public int someInt { get; set; }
}

vs 这......

class NonGetSetExample
{
    private int someInt;
}

编辑：

感谢大家！ 你的所有答案都帮助了我，我适当地向你投了你的答案。

Answer 1

这个：

class GetSetExample
{
    public int someInt { get; set; }
}

真的是这样的：

class GetSetExample
{
    private int _someInt;
    public int someInt {
        get { return _someInt; }
        set { _someInt = value; }
    }
}

get; set; get; set; 语法只是一种方便的简写，当getter和setter不做任何特殊操作时你可以使用它。

因此，您没有公开公共成员，您正在定义私有成员并提供get / set方法来访问它。

Answer 2

是的，由于多种原因，成员通常不应在良好的设计中公开宣布。 想想稍后继承该类的OOP。 有点难以覆盖一个字段。 :-)它还可以防止你直接访问内部。

简单化得到; 组; 设计是在C＃2.0中引入的。 它与支持它的私有成员声明所有内容基本相同（在Reflector等工具中反编译它）。

public int someInt{get;set;} 

直接等于

private int m_someInt;
public int someInt{
  get { return m_someInt; }
  set { m_someInt = value; }
} 

关于使用简化的getter / setter的重要一点是，当你想稍后用更多的内容填充实现时，你不会破坏ABI的兼容性。

不要担心getter / setter会通过间接方式降低代码的速度。 JIT有一个叫做内联的东西，使用getter / setter和直接字段访问一样高效。

Answer 3

是。 数据成员应该是私有的，自动属性允许它并以正确的方式提供公共访问。

但你应该小心。 理解上下文非常重要。 在线程应用程序中，更新一个属性跟随另一个相关属性可能会对一致性有害。 在这种情况下，以适当方式更新两个私有数据成员的setter方法更有意义。

Answer 4

在您的第一个示例中，C＃自动生成私有支持字段，因此从技术上讲，数据成员不会被声明为仅公共getter / setter。

Answer 5

因为对于公共数据成员，该数据成员可以更改或者可以从类中读取，并且您无法控制读/写操作可访问性，但是使用属性可以控制读/写流，例如考虑以下语句：

 public MyVar{private get; public set;}

意味着MyVar值只能在类内部进行更改，并且可以从类中读取（私有读取并公开读取），这对于公共数据成员来说是不可能的

Answer 6

在“纯粹的”面向对象的方法中，根本不公开对象的状态是不行的，这适用于在.NET中实现的属性以及Java / EJB的get_set_ properteis。 我们的想法是，通过公开对象的状态，您将创建对象的内部数据表示的外部依赖关系。 纯对象设计减少了与带参数的消息的所有交互。

回到现实世界：如果你试图在工作中实施如此严格的理论方法，你将被嘲笑出办公室或被殴打成纸浆。 属性非常受欢迎，因为它们是纯对象设计和完全暴露的私有数据之间的合理折衷。

Answer 7

这是非常合理的，你的教授（没有背景）是错误的。 但无论如何，使用“自动属性”，很好，无论是公共还是私有，你都可以这样做。

虽然根据我的经验，每当我使用一个时，我几乎不可避免地最终需要在那里写一些逻辑，因此不能使用汽车道具。

Answer 8

你的教授是对的。

考虑一下为什么应该避免“getter”的简单示例：程序中可能有1000次调用getX()方法，并且每个调用都假定返回值是特定类型。 例如， getX()的返回值可以放在局部变量中，并且变量类型必须与返回值类型匹配。 如果您需要以X类型发生变化的方式更改对象的实现方式，那么您就会陷入困境。 如果X曾经是一个int ，但现在必须是一个long ，你现在会得到1,000个编译错误。 如果通过将返回值强制转换为int来错误地修复问题，则代码将干净地编译但不起作用。 （返回值可能会被截断。）您必须修改围绕这1,000个调用中的每一个的代码以补偿更改。 我，至少，不想做那么多工作。

Holub On Patterns