【问题标题】:C# Auto-Implemented Properties - Using Inside ClassC# 自动实现的属性 - 使用内部类
【发布时间】:2016-03-12 20:38:21
【问题描述】:

我正在寻找有关使用自动实现属性时的最佳做法的建议。

如果我不需要引用类中的属性,我总是使用它们。但是,如果我确实需要访问类中的属性,我习惯于手动添加私有属性。

例如,如果我有一个名为 Person 且具有 firstName 和 lastName 属性的类,并且我不必在类中操作该数据,我会这样做:

public class Person
{
    public string firstName { get; set; }
    public string lastName { get; set; }
}

但是,如果我需要对这些属性做一些事情,我会这样做:

public class Person
{
    private string _firstName;
    public string firstName
    {
        get { return _firstName; }
        set { _firstName = value; }
    }

    private string _lastName;
    public string lastName
    {
        get { return _lastName; }
        set { _lastName = value; }
    }

    public void testMethod()
    {
        Debug.Print(_firstName + " " + _lastName);
    }

}

我的问题:这是一种好的做法吗?

【问题讨论】:

  • 你应该可以直接使用类中的属性
  • 你的理由是什么?为什么不直接使用类中的自动属性呢?您是否担心性能?
  • 如果要覆盖属性,请使用“virtual”关键字声明要覆盖的属性
  • @GrahamS 是的。我推断访问公共财产意味着程序必须通过内部财产的吸气剂。我在想,既然可以直接访问,为什么还要这样做?
  • 我会说,如果您的程序对时间非常关键,以至于属性所需的额外 deref 是性能问题,那么您可能不应该从 C# 开始!

标签: c#


【解决方案1】:

不,没有意义。当您需要做的不仅仅是设置/获取支持字段时,您应该转向完全实现的属性。

目前情况:

Debug.Print(FirstName + " " + LastName); //convention says use UpperCamel for props

绝对没问题,引入支持字段只会给您的代码带来不必要的噪音。

如果您想进行一些验证:

public string LastName
{
    get { return _lastName; }
    set { 
        if(value.Contains("!")){
            throw new Exception("names can't contain '!'");
        }
        _lastName = value; }
}

现在您有充分的理由放弃自动实现的属性。

如果您只是想避免第二次查找的开销,请不要担心。很有可能这永远不会导致性能问题,如果确实如此,您将通过测量代码时序来发现。试图以牺牲清晰度为代价编写最高效的代码是一个糟糕的目标,并且会导致代码混乱。每次都希望清晰,当您的程序运行缓慢时,您可以返回并找出导致它的原因。研究表明,它极有可能不是您所期望的,因此尝试猜测并不是一种经济的追求。

【讨论】:

  • 没错,当你得到价值并直接分配它时,它看起来也很奇怪。
  • 同意简单、清晰、可读的代码是一个比过早优化更重要的目标。请记住,使用两种不同的方式来设置值可能会在以后导致混淆。
  • 好的,感谢您的回复spender 和@GrahamS。我怀疑在这件事上的表现将永远是一个实际问题。它主要是它的校长。这感觉像是一个额外的步骤。我的观点是明确的。而 JITter 的重点回答了我一开始的目的。令人失望的是,有些人认为适合否决这个问题。毕竟,这是一个问题,而不是建议,投反对票会阻止人们提出此类问题并学习更好地编码。
  • @Sparked 我删除了关于 JITter 的观点,因为我不确定。需要更多研究。
  • @Sparked 不确定为什么它被否决了。对我来说似乎是一个合理的问题。我自己也有同样的想法。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2014-03-16
  • 2018-11-28
  • 1970-01-01
  • 2010-09-28
  • 1970-01-01
  • 2021-06-04
  • 2021-04-14
相关资源
最近更新 更多