Write-Only properties, what’s the point? [duplicate]

by

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.

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

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

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.

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.

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

Do not provide set-only properties.

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…

More Related Contents:

  1. What is the difference between a field and a property?
  2. Communicate between two windows forms in C#
  3. How to get the list of properties of a class?
  4. Set object property using reflection
  5. Public Fields versus Automatic Properties
  6. How can I evaluate C# code dynamically?
  7. What are Automatic Properties in C# and what is their purpose?
  8. Difference between Property and Field in C# 3.0+
  9. Does C# have extension properties?
  10. How can I find a specific element in a List?
  11. C# thread safety with get/set
  12. Why is it impossible to override a getter-only property and add a setter? [closed]
  13. Is the C# compiler smart enough to optimize this code?
  14. What’s the difference between encapsulating a private member as a property and defining a property without a private member?
  15. C# Iterate through Class properties
  16. c# foreach (property in object)… Is there a simple way of doing this?
  17. C# property and ref parameter, why no sugar?
  18. C# add validation on a setter method
  19. Overloading getter and setter causes a stack overflow in C# [duplicate]
  20. Should you access a variable within the same class via a Property?
  21. Conditional “Browsable” Attribute
  22. How Can I add properties to a class on runtime in C#?
  23. Checking for null before ToString()
  24. Thread Safe Properties in C#
  25. C# Get property value without creating instance?
  26. Properties.Settings.Default.Save(); -> Where is that file
  27. WCF chokes on properties with no “set “. Any workaround?
  28. Adding custom attributes to an element in XAML?
  29. How do static properties work in an asp.net environment?
  30. How can I get the value of a string property via Reflection?

Leave a Comment