属性从不为空c＃(Property never null c#)

属性从不为空c＃(Property never null c#)

重构代码时，我想出了如下的实例

private string _property = string.Empty; public string Property { set { _property = value ?? string.Empty); } }

稍后在一个方法中，我看到以下内容：

if (_property != null) { //... }

假设_property只由Property的setter设置，这个代码是多余的吗？

有什么办法，通过反射魔术或其他方法， _property可以永远是空的？

When refactoring code, I come up with instances like the following

private string _property = string.Empty; public string Property { set { _property = value ?? string.Empty); } }

Later on in a method I see the following:

if (_property != null) { //... }

Assuming that _property is only set by the setter of Property, is this code redundant?

I.e is there any way, through reflection wizardry or other methods that _property can ever be null?

最满意答案

假设_property只由Property的setter设置，这个代码是多余的吗？

确实，这是多余的。 这是Properties的实际目的。 我们不应该直接访问类的字段。 我们应该使用Property来访问它们。 因此，在相应的setter中，我们可以嵌入任何逻辑，并且我们可以保证每次我们尝试设置一个值时，这个逻辑会再次被验证。这个论证甚至适用于类的方法。 在一个方法中，我们必须使用属性而不是实际的字段。 而且，当我们想要读取一个字段的值时，我们应该使用相应的getter。

通常，属性增强了封装的概念，这是面向对象编程OOP的支柱之一。

很多时候，当我们想要设置一个值时，没有任何逻辑应该应用。 以下面的例子为例：

public class Customer { public int Id { get; set; } public string FirstName { get; set; } public string LastName { get; set; } }

我们已经宣布了代表客户的类别。 一个Customer对象应该有三个属性Id ， FirstName和LastName 。

一个直接的问题，当有人读这个类时，为什么有人在这里使用属性？

答案也是一样的，它们提供了封装机制。 但是让我们考虑一下，从长远来看，这对我们有什么帮助。 假设有一天有人决定客户的名字应该是长度小于20的字符串。如果上面的类已经被声明如下：

public class Customer { public int Id; public string FirstName; public string LastName; }

那么我们应该在每个我们创建的实例中检查FirstName的长度！ 否则，如果我们选择了属性声明，我们可以轻松使用数据注释

public class Customer { public int Id { get; set; } [StringLength(20)] public string FirstName { get; set; } public string LastName { get; set; } }

就是这样。 另一种方法可能如下：

public class Customer { public int Id { get; set; } private string firstName; public string FirstName { get { return firstName } set { if(value!=null && value.length<20) { firstName = value; } else { throw new ArgumentException("The first name must have at maxium 20 characters", "value"); } } } public string LastName { get; set; } }

考虑上述两种方法，必须重新访问所有代码库并进行检查。 物业赢得的结果很清楚。

Assuming that _property is only set by the setter of Property, is this code redundant?

Exactly, it is redundant. This is the actual purpose of Properties. We shouldn't access the fields of a class directly. We should access them using a Property. So in the corresponding setter, we can embed any logic and we can rest assure that each time we try to set a value this logic would be verified once more.This argument holds even for the methods of a class. In a method we must use the properties and not the actual fields. Furthermore, when we want to read the value of a field, we should make use of the corresponding getter.

In general, properties enhances the concept of encapsulation, which is one of the pillars of object oriented programming OOP.

Many times there isn't any logic that should be applied when we want to set a value. Take for instance the following example:

public class Customer { public int Id { get; set; } public string FirstName { get; set; } public string LastName { get; set; } }

We have declared a class for representing a Customer. A Customer object should have three properties an Id, a FirstName and a LastName.

An immediate question, when someones read this class is why should someone make use of properties here?

The answer is again the same, they provide a mechanism of encapsulation. But let's consider how can this help us in the long run. Let's say that one day someone decides that the first name of a customer should be a string of length less than 20. If the above class had been declared as below:

public class Customer { public int Id; public string FirstName; public string LastName; }

then we should check for the length of FirstName in each instance we had created ! Otherwise, if we had picked the declaration with the properties, we could just easily make use of Data Annotations

public class Customer { public int Id { get; set; } [StringLength(20)] public string FirstName { get; set; } public string LastName { get; set; } }

and that's it. Another approach it could be the following:

public class Customer { public int Id { get; set; } private string firstName; public string FirstName { get { return firstName } set { if(value!=null && value.length<20) { firstName = value; } else { throw new ArgumentException("The first name must have at maxium 20 characters", "value"); } } } public string LastName { get; set; } }

Consider both of the above approaches with having to revisit all your codebase and make this check. It's crystal clear that properties win.