0

This Question explains how to implement interface properties in interfaces: Implementing interface properties in interfaces?

Now how do I implement a Setter with this? I'm getting "Cannot convert source type ..."

Is this the right way?

class WpfReportParams : IReportParams
{
    private ObservableCollection<StatusEnum> _selectedStatuses;

    public WpfReportParams()
    {
        _selectedStatuses = new ObservableCollection<StatusEnum>();
    }

    public IEnumerable<StatusEnum> SelectedStatuses
    {
        get { return _selectedStatuses; }
        set
        {
            var collection = value as ObservableCollection<StatusEnum>;
            if (collection != null)
            {
                _selectedStatuses = collection;
            }
        }
    }
}
Community
  • 1
  • 1
André Fiedler
  • 1,093
  • 4
  • 16
  • 25
  • 4
    Normally, you don't have setters to Collections. If you need to add to your collection, implement an `Add` method or expose property via `IList` instead – default Jul 02 '14 at 08:18

2 Answers2

1

No, that would not be the correct way. You shouldn't have setters to Collections. If you need to add to your collection, implement an Add method or expose your property via IList<T> or ICollection<T> or a similar interface which supports the Add method instead.

Note that this can be accomplished using explicit implementations of the interface, where you are able to expose a different collection than that from the interface.

public interface IReportParams {
    IEnumerable<StatusEnum> SelectedStatuses { get; }
}

public class WpfReportParams : IReportParams {
    private readonly ObservableCollection<StatusEnum> _SelectedStatuses;

    public WpfReportParams() {
        _SelectedStatuses = new ObservableCollection<StatusEnum>();
    }

    public ICollection<StatusEnum> SelectedStatuses {
        get { return _SelectedStatuses; }
    }

    IEnumerable<StatusEnum> IReportParams.SelectedStatuses {
        get { return SelectedStatuses; }
    }
}

This is a better solution, considering that if you would have a setter and overwrite the value of the current collection, all event handlers for the current collection would be lost (or at least not trigger when new StatusEnum were added to the collection).

If you do need to "reset" your collection, use Clear() instead.

Patrick
  • 17,669
  • 6
  • 70
  • 85
default
  • 11,485
  • 9
  • 66
  • 102
0

Is this the right way?

Yes. Its the right way.

Where are you stuck?

Note: Collections do not have set part. Only get part. In its get part we initialize backup-field if it is null and always access property and not backup-field. Like this

private IEnumerable<StatusEnum> _selectedStatuses;

public IEnumerable<StatusEnum> SelectedStatuses
{
    get 
    {
        if (_selectedStatuses == null)
            _selectedStatuses = new List<StatusEnum>();

        return _selectedStatuses; 
    }        
}    
Nikhil Agrawal
  • 47,018
  • 22
  • 121
  • 208
  • 1
    Note: You **can** do this. However, I'd say that the OP has initialized his field correctly in the constructor. There is no need to move the initialization to the property. – default Jul 02 '14 at 08:36
  • 1
    @Default: Lets take a scenario. In constructor, this property is initialized but not used anywhere. in that case it will hold useless memory. Initializing inside get makes sure that it gets initialized only when used. – Nikhil Agrawal Jul 02 '14 at 08:52
  • 1
    [Lazy loading has its places](http://stackoverflow.com/questions/14774008/good-or-bad-practice-initializing-objects-in-getter). There is no context in the question which says that this property is **not** used. If it *is* used a **constructor** is used to **construct** the object. So I'd say that the constructor is very well suited to handle that Construction. When created in the constructor there are other benefits, for instance marking the field as readonly, which you cannot do when you lazyload in the getter. – default Jul 02 '14 at 09:24
  • @Default: That's why added in Note. – Nikhil Agrawal Jul 02 '14 at 09:27