只写属性，有什么意义?

问题描述

我理解您为什么要使用以下语法使用只读属性:

I understand why you would want to use a read-only property using the following syntax:

private int _MyInt;
public int MyInt
{
  get { return _MyInt; }
}

这个例子可能不是最好的例子，因为我认为只读属性与 readonly 变量结合起来确实很出色，但这不是重点.我不明白的是为什么使用以下语法使用只写属性:

This example probably isn't the best one because I think that read-only properties really shine in conjunction with a readonly variable, but that's beside the point. What I don't understand is why use a write-only property using the following syntax:

private int _MyInt;
public int MyInt
{
  set { _MyInt = value; }
}

这是在各种书籍和教程中描述只读属性的方式.如果您设置变量，您将从概念上在某个点读取它，至少在类内部读取它，但即使在类内部读取它，您也可以通过访问 _MyInt 我觉得这违反了属性试图强制执行的封装精神.相反，您为什么不直接使用具有不同访问权限的属性的全部功能来访问它:

This is how read-only properties are described in various books and tutorials. If you set the variable, you would conceptually read it at some point, at least internally to the class, but to read it even internally within the class you would do so by accesssing _MyInt which I feel violates the spirit of encapsulation which properties try to enforce. Instead, why wouldn't you just use the full power of the property with different access modifies for accessing it as such:

private int _MyInt;
public int MyInt
{
  set { _MyInt = value; }
  private get { return _MyInt; }
}

当然可以直接写

public int MyInt { set; private get; }

你仍然得到封装，但限制其他类访问，所以它仍然只写给外部类.

You still get the encapsulation, but restrict other classes from access, so its still write-only to outside classes.

除非在某些情况下，您真的想分配给变量但从未真正访问过它，在这种情况下，我肯定会好奇何时会出现这种需求.

Unless there is a case where you honestly would want to assign to a variable but never actually access it, in which case I would definitely be curious about when this need would arise.

推荐答案

我从未遇到过针对只写属性的有效用例.老实说，如果只写属性有一个有效的用例，我认为可以肯定地说该解决方案设计得很差.

I have never come across a valid use-case for a write-only property. Honestly, if there is a valid use-case for a write-only property I think it is safe to say that the solution is poorly designed.

如果您需要只写"语义，您应该使用一种方法.例如，另一个用户发现了一个使用只写属性来设置密码的用户对象示例.这是一个糟糕的设计:

If you need "write-only" semantics you should use a method. For instance, another user has found an example of a user object that uses a write-only property to set a password. This is a bad design:

class User
{
    public string Password
    {
        set { /* password encryption here */ }
    }
}

呃.这好多了:

class User
{
    public void SetPassword(string password)
    {
        /* password encryption here */
    }
}

看，读/写属性是一组旨在伪装成字段的方法.它们的外观和感觉就像一个领域.正是出于这个原因，只读属性才有意义，因为我们习惯于拥有可以读取但不能更改的字段和变量.但是，没有相应的字段或变量构造可写但不可读.

See, a read/write property is a set of methods that are designed to masquerade as a field. They look and feel like a field. It is for this reason that a read-only property makes sense because we are used to having fields and variables that we can read but cannot change. However there isn't a corresponding field or variable construct that is writable but not readable.

这就是为什么我认为创建一个使用只写属性的 API 是不好的做法.它与我认为的 C# 属性语法的主要目标背道而驰.

This is why I believe that creating an API that employs write-only properties is bad practice. It runs counter-intuitive to what I believe is the main goal of the property syntax in C#.

更多哲学...我相信类服务于一个功能性目的:它们为相关数据提供了一个容器来保存和操作.以我们的 User 类为例 - 该类将保存与系统中的用户有关的所有信息.我们收集所有这些数据并给它们一个名称:user.通过这种方式，我们使用类来创建抽象.User 是一种抽象，它允许我们对构成用户的所有单独数据(密码、姓名、生日等)进行推理.

More philosophy... I believe that classes serve a functional purpose: they provide a container for related data to be held and manipulated. Take our User class for example - this class will hold all pieces of information that pertain to a user in the system. We collect all these pieces of data and give them a single name: user. In this way we use classes to create abstractions. User is an abstraction that allows us to reason about all the individual pieces of data that comprise a user (password, name, birthday, etc.).

现在有好的抽象和坏的抽象.我相信只写属性是糟糕 抽象，因为您允许某人输入数据而不是读取数据.你为什么要禁止这个?很可能是因为传入的信息以某种方式进行了转换，使传递者无法读取.

Now there are good abstractions and there are bad abstractions. I believe that write-only properties are bad abstractions because you are allowing someone to input data and not read it. Why would you disallow this? Most likely because the information that has been passed in has been transformed in some way that makes it unreadable to the passer.

所以这意味着一个只写属性根据定义必须创建调用者看不到的副作用(因为如果他们能看到它们，那么就没有理由让属性写-只要).C# 语言中用于设置具有副作用的值的最佳构造是方法.

So this means that a write-only property by definition must create side-effects that the caller cannot see (because if they could see them then there would be no reason to make the property write-only). The best construct in the C# language for setting a value with side-effects is the method.

我强烈建议不要使用只写属性，因为您的 API 的使用者会发现它们令人困惑和沮丧.即使您找到了此语法的有效用例，也不能证明它的使用是合理的.

I would highly recommend not using write-only properties because consumers of your API will find them confusing and frustrating. Even if you find a valid use-case for this syntax it doesn't justify its use.

这是 .Net Framework 的官方建议 开发类库的设计指南 ->成员设计指南 ->属性设计

Here is official recommendation from .Net Framework Design Guidelines for Developing Class Libraries ->Member Design Guidelines ->Property Design

不要提供仅设置属性.

如果无法提供属性getter，则使用方法实现而是功能.方法名称应以 Set 开头其次是属性名称...

If the property getter cannot be provided, use a method to implement the functionality instead. The method name should begin with Set followed by what would have been the property name...

这篇关于只写属性，有什么意义?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！