C# – ny reason to have a property with no getter

cproperties

My manager has asked me if it is good practice to use a property with a setter, but no getter.

public class PropertyWrapper
{   
    private MyClass _field;

    public MyClass Property
    {
        set { _field = value; } 
    }

    public string FirstProperty
    {
        get { return _field.FirstProperty; } 
    }

    public string SecondProperty
    {
        get { return _field.SecondProperty; } 
    }
}

He would be using other properties to expose properties from a private field, set by this setter.

My suggestion was to just use a private field and set it in the constructor, which works fine in this scenario. If I needed to have a constructed object first (maybe even using polymorphism) I would still prefer a Load method, rather than a getter-less property.

But I'm interested. We're both very concerned by best-practices and try to make sure our code is standarised. Does anyone have any official articles about getter-less properties? Or better still – an example of this usage in the .NET Framework itself?

Best Answer

Official article: 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. For example, AppDomain has a method called SetCachePath instead of having a set-only property called CachePath.

Related Solutions

C# – Why is this property Getter virtual

It's virtual because it implements an interface method. Interface implementation methods are always virtual as far as the CLR is concerned.

C# – Overriding fields or properties in subclasses

Of the three solutions only Option 1 is polymorphic.

Fields by themselves cannot be overridden. Which is exactly why Option 2 returns the new keyword warning.

The solution to the warning is not to append the “new” keyword, but to implement Option 1.

If you need your field to be polymorphic you need to wrap it in a Property.

Option 3 is OK if you don’t need polymorphic behavior. You should remember though, that when at runtime the property MyInt is accessed, the derived class has no control on the value returned. The base class by itself is capable of returning this value.

This is how a truly polymorphic implementation of your property might look, allowing the derived classes to be in control.

abstract class Parent
{
    abstract public int MyInt { get; }
}

class Father : Parent
{
    public override int MyInt
    {
        get { /* Apply formula "X" and return a value */ }
    }
}

class Mother : Parent
{
    public override int MyInt
    {
        get { /* Apply formula "Y" and return a value */ }
    }
}

Best Answer

Related Solutions

C# – Why is this property Getter virtual

C# – Overriding fields or properties in subclasses

Related Topic