只写属性是否有实际应用?

我不知道为什么我开始想这个,但现在我似乎无法停下来。

在C#中 – 也许还有很多其他的语言,我记得Delphi也曾经让你这样做 – 编写这个语法是合法的:

class WeirdClass { private void Hello(string name) { Console.WriteLine("Hello, {0}!", name); } public string Name { set { Hello(name); } } } 

换句话说,该属性有一个setter,但没有getter ,它是只写的

我想我想不出有什么理由说这是非法的 ,但是我从来没有真正看到过它,而且我看起来在野外有一些相当辉煌的代码。 这似乎是一种代码味道; 编译器似乎应该给我一个警告:

CS83417:属性“名称”似乎是完全无用和愚蠢的。 不好的程序员! 考虑用一种方法replace。

但是也许我只是没有做足够长的时间,或者一直在狭窄的领域里工作,以便看到有效使用这样的结构的例子。

是否有真实的只写属性的例子,要么不能被直接的方法调用取代,要么变得不那么直观?

只写属性实际上是非常有用的,我经常使用它们。 这完全是关于封装 – 限制对对象组件的访问。 您经常需要为需要在内部使用的类提供一个或多个组件,但没有理由让其他类可以访问它们。 这样做只会让你的课更容易混淆(“我使用这个getter还是这个方法?”),更可能是你的课可能被篡改或被其真实的目的绕过。

请参阅“为什么getter和setter方法是邪恶的”这个有趣的讨论。 我并不像文章的作者那样硬着头皮,但我认为这是一件好事。 我通常使用setter,但很less使用getter。

我对这个问题的第一个反应是:“ java.util.Random#setSeed方法怎么样?

我认为只写属性在几个场景中是有用的。 例如,当你不想公开内部表示( 封装 ),同时允许改变对象的状态。 java.util.Random是这种devise的一个很好的例子。

代码分析(又名FxCop)的确给你一个诊断:

CA1044 :Microsoft.Design:由于属性“WeirdClass.Name”是只写的,因此可以添加一个属性获取器,其中的可访问性大于或等于其设置器,或者将此属性转换为方法。

我在XNA项目中有类似于以下的代码。 正如你所看到的, Scale是只写的,它是有用的(合理的)直观的,读取属性( get )对它没有意义。 当然可以用一种方法来替代,但是我喜欢它的语法。

 public class MyGraphicalObject { public double ScaleX { get; set; } public double ScaleY { get; set; } public double ScaleZ { get; set; } public double Scale { set { ScaleX = ScaleY = ScaleZ = value; } } // more... } 

只要你不应该读你写的东西,写一些东西是有用的。

例如,在屏幕上绘制东西时(这正是Windows中的桌面窗口pipe理器的function):
你当然可以绘制到屏幕上,但是你永远不需要读回数据(更不用说期望得到和以前一样的devise了)。

现在,无论是只写属性是有用的(而不是方法),我不知道他们多久使用。 我想你可以想象一个具有“BackgroundColor”属性的情况,在这种情况下写入它将设置屏幕的背景颜色,但是读取是没有意义的(必然)。
所以我不确定这个部分,但总的来说,我只想指出,在只写数据的情况下存在用例,而不会读取它。

一个用于只写属性的用途是支持setterdependency injection,它通常用于可选参数。

假设我有一堂课:

 public class WhizbangService { public WhizbangProvider Provider { set; private get; } } 

WhizbangProvider不打算被外部世界访问。 我永远不想与service.Provider交互,这太复杂了。 我需要像WhizbangService这样的课程来充当门面。 然而,通过二传手,我可以做这样的事情:

 service.Provider = new FireworksShow(); service.Start(); 

这项服务开始了烟花汇演。 或者,也许你更愿意看一场水和灯光秀:

 service.Stop(); service.Provider = new FountainDisplay(new StringOfLights(), 20, UnitOfTime.Seconds); service.Start(); 

等等….

如果该属性是在基类中定义的,这将变得特别有用。 如果你为这个属性select构造函数,你需要在任何派生类中写一个构造函数重载。

 public abstract class DisplayService { public WhizbangProvider Provider { set; private get; } } public class WhizbangService : DisplayService { } 

这里,构造函数注入的替代方法是:

 public abstract class DisplayService { public WhizbangProvider Provider; protected DisplayService(WhizbangProvider provider) { Provider = provider ?? new DefaultProvider(); } } public class WhizbangService : DisplayService { public WhizbangService(WhizbangProvider provider) : base(provider) { } } 

这种方法在我看来更加混乱,因为你需要类的一些内部工作,特别是,如果你传递null给构造函数,你会得到一个合理的默认值。

就我而言,他们没有。 每次我使用只写属性作为快速入侵,我后来都后悔了。 通常我会得到一个构造函数或一个完整的属性。

当然,我试图certificate一个消极的,所以也许有一些我错过了。

我也不能停止想这个。 我有一个“只写”属性的用例。 我看不出有什么好办法。

我想构build一个C#属性,派生自ASP.NET MVC应用程序的AuthorizeAttribute。 我有一个服务(比如说,IStore)返回的信息,有助于决定是否应当授权当前用户。 因为构造函数注入不起作用

 public AllowedAttribute: AuthorizeAttribute { public AllowedAttribute(IStore store) {...} private IStore Store { get; set; } ... } 

使存储成为一个位置属性参数,但是IStore不是一个有效的属性参数types,编译器不会构build用它注释的代码。 我被迫退回到Property Setter Injection。

 public AllowedAttribute: AuthorizeAttribute { [Inject] public IStore Store { private get; set; } ... } 

除了属性设置器而不是构造器注入的所有其他坏事之外,该服务是只写属性。 足够糟糕的是,我不得不将暴露者暴露给不需要了解实现细节的客户端。 也不会让任何人有任何帮助让客户看清楚的地方。

我认为dependency injection的好处胜过这种情况下针对只写属性的指导方针,除非我错过了一些东西。

不,我可以想象任何不能被replace的情况,尽pipe可能有人认为它们更具可读性。

假设情况:

 CommunicationDevice.Response = "Hello, World" 

代替

 CommunicationDevice.SendResponse("Hello, World") 

主要工作将是执行IO副作用或validation。

有趣的是,VB .NET甚至为这种奇怪的属性获得了自己的关键字;)

 Public WriteOnly Property Foo() As Integer Set(value As Integer) ' ... ' End Set End Property 

尽pipe来自外部的许多“只写”属性实际上具有私有的获取者。

我最近在处理密码的应用程序工作。 (请注意,我并没有声称以下是一个好主意,我只是在描述我所做的。)

我有一个class级, HashingPassword密码,其中包含一个密码。 构造函数将密码作为参数并将其存储在私有属性中。 鉴于这些对象之一,您可以获取密码的盐渍散列,或检查给定的盐渍散列的密码。 当然,没有办法从HashingPassword对象中检索密码。

那么我还有其他的一些东西,我不记得那是什么东西。 让我们假装它是一个密码保护的香蕉。 Banana类有一个名为Password的set-only属性,它从给定的值创build一个HashingPassword并将其存储在Banana的私有属性中。 由于HashingPasswordpassword属性是私有的,所以没有办法为这个属性写一个getter。

那么为什么我有一个名为Password的set-only属性,而不是一个名为SetPassword的方法? 因为这是有道理的。 事实上,这个效果是设置Banana的密码,如果我想设置一个Banana对象的密码,我希望通过设置一个属性,而不是通过调用一个方法。

使用名为SetPassword的方法不会有任何主要的缺点。 但是我也没有看到任何显着的优势。

我知道这已经有很长一段时间了,但我碰到它并且有一个有效的(imho)用例:

当你从ajax发布参数给webapi调用时,你可以简单地尝试填写参数类的属性并包含任何validation。

 public int MyFancyWepapiMethod([FromBody]CallParams p) { return p.MyIntPropertyForAjax.HasValue ? p.MyIntPropertyForAjax.Value : 42; } public class CallParams { public int? MyIntPropertyForAjax; public object TryMyIntPropertyForAjax { set { try { MyIntPropertyForAjax = Convert.ToInt32(value); } catch { MyIntPropertyForAjax = null; } } } } 

在JavaScript方面,您可以简单地填写参数,包括validation:

 var callparameter = { TryMyIntPropertyForAjax = 23 } 

这在这个例子中是安全的,但是如果你处理userinput它可能不确定你有一个有效的int值或类似的东西。

在MVP模式中,通常在视图上使用setter编写一个属性(不需要getter) – 只要演示者设置内容,属性将使用该值更新某个UI元素。

看到这里的一个小示范:

 public partial class ShowMeTheTime : Page, ICurrentTimeView { protected void Page_Load(object sender, EventArgs e) { CurrentTimePresenter presenter = new CurrentTimePresenter(this); presenter.InitView(); } public DateTime CurrentTime { set { lblCurrentTime.Text = value.ToString(); } } } 

演示者InitView方法简单地设置属性的值:

  public void InitView() { view.CurrentTime = DateTime.Now; } 

那么,从技术上来说,只有一个Setter属性本身没有什么问题。 二传手可以做一些validation,也许其他一些方法 – 公开或私人 – 可以依靠它。

例如:

 class SomeClass { private int _someVar; SomeClass(int someVar) { if(someVar > 0) _someVar = someVar; } public int SomeVar { set { if(value > 0) _someVar = value; } } public string SomeFunction(){ return "This is an important function that uses _someVar " + _someVar; } } 

所以声明本身可能是合法和有效的。 虽然你的方法体是一个巨大的代码气味,但是这不是编译器关心的工作。