Control accessability of elements in a class derived from ObservableCollection

Question

4.00/5 (1 vote)

See more:

Hi all,
I am just playing around with some ideas and was wondering if the following would be possible without too much hassle...

Imagine a class like this:

C#

public class Animals : ObservableCollection<Animal>
{
}

And of course this radically rare class

C#

public class Animal
{
     public string Name{ get; set; }
     public bool IsAlive{ get; set; }
     public bool Buried{ get; set; }
}

Now if someone uses the Animals class he/she would propably not be interested in retrieving animals that are not alive and buried (if so I could provide a function to get these if neccessary).

So would it somehow be possible to modify the Animals class so that it only respects instances of Animal that are actually alive and not buried?
So after an instance of Animal is actually buried (and of course no longer alive - which might automatically change if buried alive) it should not be available anymore by using the standard retrieval methods of the Animals class (also Count and Linq related stuff like First, Where, etc. - you get the picture).

So far I implemented the INotifyPropertyChanged interface in the Animal class to allow Animals to remove those instances (dead and buried) and store them internally, which works fine. But would there be a more elegant solution to the problem?

UPDATE:
Maybe I can simplify it a little bit more.
Would it be possible to modify the Animals class somehow to only return instances of Animal where not (Alive = false AND Buried = true) so that they can no longer be seen by the outside world but to keep it in the list?
Mabe by overriding/overwriting the enumerator like this:

C#

new public IEnumerator GetEnumerator()
{
    IEnumerator ie = base.GetEnumerator();
    while (ie.MoveNext())
    {
        Animal animal = (Animal)ie.Current;
        if(animal.Alive && !animal.Buried)
        yield return ie.Current;
    }
}

..but would that also affect Count, First, etc of the List?

UPDATE:
I figured out that the above will affect foreach (which was ecpectable) but not Count or Linq methods...

I have hard time expressing myself in english here, please be mercyfull :)

Any thoughts are kindly appreciated,
have a great day
Andy

Posted 12-Sep-12 2:34am

hoernchenmeister

Updated 12-Sep-12 3:28am

v8

Add a Solution

Comments

Kenneth Haugland 12-Sep-12 8:38am

Do you wan tsomething that say MyAnimal.Buiried = True then delete this instance of the class?

hoernchenmeister 12-Sep-12 8:54am

Yes thats somehow right. If an animal dies it gets buried and after that it should no longer be accessible via standard retrieval methods. If anybody would be interested in retrieving a List of dead and buried animals he/she could call a "List<animal> GetDeadAndBuried()" function to retrieve (and maybe unbury and reanimate them) them

Malli_S 12-Sep-12 8:40am

If you don't wanna to preserve the dead Animals, you should check them while inserting also. Don't insert the dead Animals in the list. Bcz, there's less chance of changing the property from 'Dead' to 'Alive'.

hoernchenmeister 12-Sep-12 8:59am

Dead animals are not inserted in the list. First they are alive, if they die (become deleted) they become buried at a certain point (committed), thats where they sould no longer be visible by the default retrieval methods (like beeing bound to a grid or something alike).

Malli_S 12-Sep-12 8:43am

Did you mean have another list of dead animals by saying 'store them internally' ?

hoernchenmeister 12-Sep-12 9:00am

Somehow... if they die (become deleted) and are buried (committed against the source) I can still store them in an internal list that might be retrieved by some kind of "GetDeadAndBuriedAnimals" function ;)

hoernchenmeister 12-Sep-12 8:57am

For clarification, this is some kind of made up example (surprise *LG*).
It simplyfies a problem I am dealing with where dead means deleted and buried means committed against some kind of datasource.

Retrieving dead and buried instances might be useful for undeleting and re-inserting the committed instances.

For the user of the Animals class who maybe binds the instance of Animals to a grid they should no longer be visible.

The main purpose might be to simplify the usage of the Animals class for my colleagues so that they can just bind it and do whatever they want.

They might use a porperty like InstanceOfAnimalsThatAreNotDeadAndBuried of the Animals class for binding, but binding to the instance of Animals itself looks more comfortable to me :)

Malli_S 12-Sep-12 9:25am

Rather linking to the Animal class, I'd suggest to add a property to the list, something like ListType. Which may hold value like 'DeadAnimal' or 'AliveAnimals'. And link to that property change event. And in the retrieval function you can apply the filter or provide the predicate/delegate for the filter. This way you can have generic class, which doesn't depend on the type of the object it is holding. You need not to update the list whenever the object state is changed. You simply have to update the list/apply the filter while providing the list out of your container class.

hoernchenmeister 12-Sep-12 9:40am

Thanks Malli_S for your reply.
Wouldn't this require that every usage of the Animals class that is already happening needs to be changed as well?
I was just wondering if it would be possible if the list could be modified somehow so that it only returns instances of Animal that meet a certain criteria to users of the list and still just behaves like a normal list... you know, just change the internals somehow?
Retrieving dead and buried animals can be implemented by a property because nobody already used them before...
I am sorry if I missunderstood your comment somehow...

Malli_S 12-Sep-12 9:49am

That's what I'm saying. You need not to change every usage of it. Just apply filter/delegate/predicate while sending data out of the class. Rest of the functionality remains same.

hoernchenmeister 12-Sep-12 10:10am

I am sorry Malli_S but it seems that I just don't get it...
I just read upon predicates in lists, but those refer to a Find method that would be used where the predicate has to be passed as a parameter...
Would you mind to explain this a little bit more or give me a source where I could read about this?

I just don't bridge the gap in my mind where I have
grid.DataSource = animals;

and where modifying the animals class with what I just read would lead to the same code above to only display alive animals...
Dude, I really feel stupid somehow right now ;)

hoernchenmeister 12-Sep-12 9:42am

I updated my question recently with an overwritten GetEnumerator() method that at least archives what I am trying for foreach etc... but Count and the Linq stuff still returns everything, not only alive/unburied animals :)

Malli_S 12-Sep-12 9:50am

Surely that will return everything, and is meant to. Because your list has it (though internally represented differently).

Malli_S 12-Sep-12 9:54am

If you don't wanna to expose the dead one to the outer world (not even with 'foreach') what's point in saving them? You can simply remove them or delete.

hoernchenmeister 12-Sep-12 10:06am

I do not want to show them, that is right. But maybe I wan't to reanimate them due to problems in the process where they are handled.
So if somebody buried an animal by accident I wan't to be able to get it back.
Somebody kills an animal (calls the delete function on it) and then buries it (commits the kill to its source) and then figures out that this was an error while the process which owns it is still alive it would be possible to get it back... But for a grid where the list is bound to showing those animals is useless...

Ashraff Ali Wahab 12-Sep-12 11:29am

Implementing INotifyPropertyChanged is best way of doing this.If there is a better way to handle such scenarios, ObservableCollection wouldnt have implemented the interface 'INotifyCollectionChanged' inherently :)

hoernchenmeister 12-Sep-12 11:48am

Thanks you very much for your comment Ashraff Ali Wahab.
I indeed try to create a base collection class where the Animals class should inherit from instead of ObservableCollection.
Looks somewhat like this:
BuryableBaseClassObservableCollection<
T> : ObservableCollection<
T> where T : BuryableBaseClass
in order to do the internal handling...
I am still thinking about it some more, let's see what I'll come up with ;)
Have a great day
Andy

1 solution

Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

hoernchenmeister · Accepted Answer · 2012-09-12T22:26:00

First of all thanks to Malli_S, Kenneth Haugland and Ashraff Ali Wahab for their contribution. It is very much appreciated!!!

In the end I came up with the following, which solves my problem.

If anybody has a comment on this I would be interested very much in hearing about it.

I only posted the replacement for the ObservableCollection because there is quite a bunch of stuff involved that would be out of the scope of the question.

C#

public abstract class BuryableBaseClassObservableCollection<T> : ObservableCollection<T>, ITransactionEnabled where T : BuryableBaseClass
{
    protected BuryableBaseClassObservableCollection()
    {
        InitializeInternalEvents();
    }

    protected void InitializeInternalEvents()
    {
        this.CollectionChanged += ItemsBaseCollectionChanged;
    }

    void ItemsBaseCollectionChanged(object sender, NotifyCollectionChangedEventArgs e)
    {
        switch (e.Action)
        {
            case NotifyCollectionChangedAction.Remove:
                Unregister(e.OldItems);
                return;

            case NotifyCollectionChangedAction.Add:
                Register(e.NewItems);
                return;
        }
    }

    protected void Unregister(IList oldItems)
    {
        foreach (T item in oldItems)
        {
            item.PropertyChanged -= ItemPropertyChanged;
            item.ElementCommitted -= ItemElementCommitted;
        }
    }

    protected void Register(IList oldItems)
    {
        foreach (T item in oldItems)
        {
            item.PropertyChanged += ItemPropertyChanged;
            item.ElementCommitted += ItemElementCommitted;
        }
    }

    void ItemElementCommitted(object sender, BuryableBaseClass committedElement)
    {
        T element = committedElement as T;
        if (committedElement.Deleted)
        {
            Console.WriteLine(String.Format("removing element of type: {0}", typeof(T)));
            this.Remove(element);
        }
    }

    void ItemPropertyChanged(object sender, PropertyChangedEventArgs args)
    {
        Console.WriteLine(String.Format("NotifyPropertyChangedPropertyChanged: {0}", args.PropertyName));
    }

    #region Implementation of ITransactionEnabled

    public virtual List<Exception> TransactionExceptions
    {
        get
        {
            List<Exception> retVal = new List<Exception>();
            foreach (ITransactionEnabled itm in this)
            {
                retVal.AddRange(itm.TransactionExceptions);
            }
            return retVal;
        }
    }

    public virtual bool Save()
    {
        return !this.Any(a => !a.Save());
    }

    public virtual void Commit()
    {
        for (int i = this.Count - 1; i >= 0; i--)
        {
            this[i].Commit();
        }
    }

    public virtual void Rollback()
    {
        for (int i = this.Count - 1; i >= 0; i--)
        {
            this[i].Rollback();
        }
    }

    #endregion
}

Control accessability of elements in a class derived from ObservableCollection

1 solution

Solution 1

Add your solution here

Preview 0

Control accessability of elements in a class derived from ObservableCollection

1 solution

Solution 1

Add your solution here

Preview 0

Existing Members

...or Join us