CODEWITHSUNDEEP
c#propertiesoverloading
end-user
end-user

Reputation: 2947

Overloading properties in C#

Ok, I know that property overloading is not supported in C# - most of the references explain it by citing the single-method-different-returntype problem. However, what about setters? I'd like to directly assign a value as either a string or object, but only return as a string.

Like this:

    public string FieldIdList
    {
        get { return fieldIdList.ToString(); }
        set { fieldIdList = new FieldIdList(value); }
    }

    public FieldIdList FieldIdList 
    {
        set { fieldIdList = value; }
    }
    private FieldIdList fieldIdList;

Why wouldn't this be allowed? I've also seen that "properties" simply create getter/setter functions on compile. Would it be possible to create my own? Something like:

    public void set_FieldIdList(FieldIdList value)
    {
        fieldIdList = value;
    }

That would do the same thing. Thoughts?

Upvotes: 17

Views: 26688

Answers (5)

Code Warrior
Code Warrior

Reputation: 117

If you need to overload a property, consider maybe inheriting from a base class and implementing different versions of that property for the sub classes.

Upvotes: -2

Reap
Reap

Reputation: 1245

You cannot overload C# properties as of C#7.

However, a redesign including your property is possible.

You can use a condition in your set block to call a private function, which can be overloaded.

public string FieldIdList
{
    get { return fieldIdList.ToString(); }
    set { fieldIdList = ChangeFieldList(value); }
}

private string ChangeFieldIdList(int i) {
    return i.ToString();
}

This example is just mean't to show a redesign consideration using private functions to be called within the set block.

Upvotes: 0

Dan Diplo
Dan Diplo

Reputation: 25349

If you want to be able to set a property as either a string or an object then you would just use object as the type of the property, since it's the base class (you can pass a string to a property that accepts an object). This doesn't seem particularly good design decision, but it can be done. Perhaps you need to explain further what you are trying to achieve?

Upvotes: 0

Jason Williams
Jason Williams

Reputation: 57922

One approach (you may argue amongst yourselves as to whether this is a good design choice or not) is to add a second property, which accesses the data in a different form.

However, as it is going to be parsing the string (doing significant work), it would be better not to use a property for this, but to add methods that allow you to get/set the data in a string form.

I'd go for fieldIdList providing ToString() and TryParse() interfaces - then if you need it as a string, you'd call myObject.FieldIdList.ToString() etc. This encapsulates everything tidily, allows you to convert to/from string formats anywhere in your code rather than only when accessing FieldIdLists as a member of some other class, and makes the client code really clear and easy to understand.

Upvotes: 1

Lucero
Lucero

Reputation: 60246

Properties are in fact a pair of get/set methods (one of which may be left out), but the property itself has additional metadata which makes it a property in the first place instead of just two methods.

Because the property signature remains invalid as per only-different-by-return-type, even if you only have a setter. If you need this, don't use a property; set-only properties aren't a good thing anyways.

Upvotes: 8

Related Questions