只写属性，有什么意义呢？ [英] Write-Only properties, what's the point?

问题描述

我明白你为什么会想使用下面的语法使用只读属性：

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; }
}

这个例子可能不是最好的，因为我觉得在一个只读变量结合的只读属性大放异彩，但那是题外话。我不明白的是为什么使用下面的语法使用只写属性：

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; }
}

这是只读属性如何在各种书籍和教程介绍。如果设置了变量，您应在概念上读它的部分的一点，至少在内部类，而是由accesssing阅读它甚至在内部类中，你会做这样 _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 */ }
    }
}

唉。这是好多了：

Ugh. This is much better:

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#.

编辑：更多...理念我相信类服务功能的目的：他们提供了一个容器举行和处理相关数据。就拿我们用户类为例 - 这个类将举行，涉及到系统的用户的信息的所有作品。我们收集所有这些数据段，给他们一个名称：用户的。这样，我们使用类来创建的抽象的。 用户是一种抽象，让我们来思考所有数据的各个部分组成一个用户（密码，姓名，生日等）。

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框架设计准则类库开发官方推荐 - >
成员设计准则 - >
物业设计

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

不要设置为仅属性。

如果不能提供属性getter，使用一种方法来实现
  代替的功能。该方法的名称应与集开始
  紧接着做什么本来属性名称...

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...

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