了解自动实现的属性

发布于 2024-07-06 19:02:40 字数 820 浏览 7 评论 0原文

我有一个使用自动实现的属性的简单类:

Public Class foo
{
    public foo() { }  

    public string BarName {get; set;}
}

显然,我在整个类中使用了变量 BarName,现在需要在设置属性值时添加逻辑(它必须全部大写,请看图)。 这是否意味着我现在需要为 BarName 创建一个私有变量(例如 _BarName),并将整个类中使用的当前 BarName 变量更改为 _BarName?

Public Class foo
{
    public foo() {}  

    private string _BarName = "";
    public string BarName 
    { 
        get {return _BarName;}
        set {_BarName = Value.ToString().ToUpper();}
    }
}

我试图确保我理解使用自动实现的属性的含义,以及当/如果我需要更改某些内容时它将带来什么。 我假设重构(如上所示)不是 重大变化,因为属性基本上保持不变; 只需在类中做一些工作即可保持这种状态并添加所需的逻辑。

另一个可能更有意义的例子是,当使用setter或getter时我需要调用一些方法; 比改变值还要多。

这似乎是对设置属性的代码行和行的公平权衡。

I have the simple class using auto-implemented properies:

Public Class foo
{
    public foo() { }  

    public string BarName {get; set;}
}

I obviously use the variable BarName throughout my class and now need to add logic when the property value is set (it must be all upper case, go figure). Does this mean that I need to now create a private variable for BarName , e.g. _BarName, and change the current BarName variable used throughout my class to _BarName?

Public Class foo
{
    public foo() {}  

    private string _BarName = "";
    public string BarName 
    { 
        get {return _BarName;}
        set {_BarName = Value.ToString().ToUpper();}
    }
}

I am trying to make sure I understand the implications of using auto-implemented properties, and what it will entail down the road when/if I need to change something. I am assuming that the refactoring, as shown above, is not a breaking change because the property is basically staying the same; it just took a little work inside the class to keep it that way and add the needed logic.

Another example, which may be more meaningful is that I need to call some method when a setter or getter is used; more then changing the value.

This seems a fair trade off the the lines and lines of code to setup properties.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

ζ澈沫 2024-07-13 19:02:40

这是否意味着我现在需要
为 BarName 创建一个私有变量

并更改当前的BarName
我的班级中使用的变量

不要更改类中的其余代码以使用您创建的新私有变量。 BarName 作为一个属性,旨在隐藏私有变量(除其他外),以​​避免对代码的其余部分进行彻底的更改。

我假设重构如下
如上所示,这不是重大更改
因为房产基本上是
保持不变; 只花了一个
保持这种状态只需做很少的工作
添加所需的逻辑。

正确的。

Does this mean that I need to now
create a private variable for BarName

Yes

and change the current BarName
variable used throughout my class

Do not change the rest of the code in your class to use the new private variable you create. BarName, as a property, is intended to hide the private variable (among other things), for the purpose of avoiding the sweeping changes you contemplate to the rest of your code.

I am assuming that the refactoring, as
shown above, is not a breaking change
because the property is basically
staying the same; it just took a
little work to keep it that way and
add the needed logic.

Correct.

北恋 2024-07-13 19:02:40

你不需要改变任何东西。 自动实现的属性只是语法糖。 编译器正在幕后为您生成私有变量和获取/设置逻辑。 如果您添加自己的 getter/setter 逻辑,编译器将使用您的代码而不是自动生成的代码,但就该属性的用户而言,没有任何变化; 任何引用您的财产的代码都将继续有效。

You don't need to change anything. Auto-implemented properties are just syntactic sugar. The compiler is generating the private variable and get/set logic for you, behind the scenes. If you add your own getter/setter logic the compiler will use your code instead of its auto-generated code, but as far as the users of that property are concerned, nothing has changed; any code referencing your property will continue to work.

温柔女人霸气范 2024-07-13 19:02:40

使用自动属性时,您无法直接访问底层“支持”变量,也无法访问属性 getter 和 setter 中实现的实际逻辑。 您只能访问该属性(因此在整个代码中使用 BarName)。

如果您现在需要在 setter 中实现特定逻辑,则不能再使用自动属性,而需要以“老式”方式实现属性。 在这种情况下,您需要实现自己的私有支持变量(至少对我来说,首选方法是将私有支持变量命名为与属性相同的名称,但首字母小写(在本例中,支持变量)然后,您将在 getter/setter 中实现适当的逻辑,

您认为这不是重大更改(从自动属性移动到“正常”属性应该是正确的)。永远不要成为重大更改,因为您不会更改公共接口(公共属性的名称或可访问性)。

When using automatic properties you don't get direct access to the underlying "backing" variable and you don't get access to the actual logic that gets implemented in the property getter and setter. You only have access to the property (hence using BarName throughout your code).

If you now need to implement specific logic in the setter, you can no longer use automatic properties and need to implement the property in the "old fashioned" way. In this case, you would need to implement your own private backing variable (the preferred method, at least for me, is to name the private backing variable the same name as the property, but with an initial lowercase (in this case, the backing variable would be named barName). You would then implement the appropriate logic in the getter/setter.

In your example, you are correct that it is not a breaking change. This type of refactoring (moving from automatic properties to "normal" properties should never be a breaking change as you aren't changing the public interface (the name or accessibility of the public property).

‖放下 2024-07-13 19:02:40

如果您知道要验证该对象,请不要使用自动属性。 这些对象可以是域对象等。就像如果您有一个 Customer 类,那么使用私有变量,因为您可能需要验证姓名、出生日期等。但是如果您使用的是 Rss 类,那么只使用自动属性就可以了因为没有执行任何验证,并且该类仅用于保存一些数据。

Don't use automatic properties if you know that you are going to validate that object. These objects can be domain objects etc. Like if you have a Customer class then use private variables because you might need to validate the name, birthdate etc. But if you are using a Rss class then it will be okay to just use the automatic properties since there is no validation being perform and the class is just used to hold some data.

天气好吗我好吗 2024-07-13 19:02:40

您对重构的看法是正确的,它确实不应该破坏任何东西。

您是否确实需要遍历类中对属性名称的引用并将其更改为引用私有字段将取决于内部代码是否需要访问数据的底层表示形式,而不是数据的呈现方式该阶层的消费者。 在大多数情况下,你可以不去管它。

在您的简单示例中,明智的做法是保持足够的独立性,并确保类内部的任何代码都不会破坏设置器中正在执行的转换/格式化。

另一方面,如果 getter 做了一些魔法,将字段的内部表示更改为消费者查看数据所需的方式,那么也许(在某些情况下)类中的内部代码需要访问该字段。

您需要查看类中对自动属性的每次访问,并决定是否应该接触该字段或使用该属性。

You are correct about the refactoring and it really shouldn't break anything.

Whether or not you actually need to go through the references within the class to the property name and change those to refer to the private field would depend on whether the internal code needed to access the underlying representation of the data rather than how it was presented to consumers of the class. In most cases you could leave well enough alone.

In your simple example it would be wise to leave well enough alone and ensure that no code internal to the class could subvert the conversion/formatting being performed in the setter.

If on the other hand the getter was doing some magic to change the internal representation of the field into the way consumers needed to view the data then perhaps (in some cases) the internal code within the class would need to access the field.

You would need to look at each occurrence of the access to the auto-property in the class and decide whether it should be touching the field or using the property.

多孤肩上扛 2024-07-13 19:02:40

自动属性只是语法糖,编译器实际上为其创建了私有成员,但由于它是在编译时生成的,因此您无法访问它。

稍后,如果您想为属性实现 getter 和 setter,那么您只能为其创建一个显式私有成员并添加逻辑。

Automatic properties are just syntactic sugar, the compiler in fact creates the private member for it, but since it's generated at compile time, you cannot access it.

And later on, if you want to implement getters and setters for the property, only then you create a explicit private member for it and add the logic.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文