In C# 4.0, is there any way to make an otherwise p

问题:

We're creating an object hierarchy where each item has a collection of other items, and each item also has a Parent property pointing to its parent item. Pretty standard stuff. We also have an ItemsCollection class that inherits from Collection<Item> which itself has an Owner property pointing to the item the collection belongs to. Again, nothing interesting there.

When an item is added to the ItemsCollection class, we want it to automatically set the parent of Item (using the collection's Owner property) and when the item is removed, we want to clear the parent.

Here's the thing. We only want the Parent setter to be available to ItemsCollection, nothing else. That way not only can we know who the parent of an item is, but we can also ensure an item isn't added to multiple collections by checking for an existing value in Parent, or letting someone arbitrarily change it to something else.

The two ways we know how to do this are:

1. Mark the setter as private, then enclose the collection definition within the scope of the item itself. Pro: Full protection. Con: Ugly code with nested classes.

2. Use a private ISetParent interface on Item that only ItemsCollection knows about. Pro: Much cleaner code and easy to follow. Con: Technically anyone who knows of the interface can cast Item and get at the setter.

Now technically via reflection anyone can get at anything anyway, but still... trying to find the best way to do this.

Now I know there was a feature in C++ called Friend or something that let you designate an otherwise private member in one class as being available to another which would be the perfect scenario, but I don't know of any such thing in C#.

In pseudocode (e.g. all the property changed notifications and such have been removed for brevity and I'm just typing this here, not copying from code), we have this...

public class Item
{
    public string Name{ get; set; }
    public Item Parent{ get; private set; }
    public ItemsCollection ChildItems;

    public Item()
    {
        this.ChildItems = new ItemsCollection (this);
    }
}

public class ItemsCollection : ObservableCollection<Item>
{
    public ItemsCollection(Item owner)
    {
        this.Owner = owner;
    }   

    public Item Owner{ get; private set; }

    private CheckParent(Item item)
    {
        if(item.Parent != null) throw new Exception("Item already belongs to another ItemsCollection");
        item.Parent = this.Owner; // <-- This is where we need to access the private Parent setter
    }

    protected override void InsertItem(int index, Item item)
    {
        CheckParent(item);
        base.InsertItem(index, item);
    }

    protected override void RemoveItem(int index)
    {
        this[index].Parent = null;
        base.RemoveItem(index);
    }

    protected override void SetItem(int index, Item item)
    {
        var existingItem = this[index];

        if(item == existingItem) return;

        CheckParent(item);
        existingItem.Parent = null;

        base.SetItem(index, item);
    }

    protected override void ClearItems()
    {
        foreach(var item in this) item.Parent = null; <-- ...as is this
        base.ClearItems();
    }

}

Any other way to do something similar?

回答1:

I have to solve your problem every day, but I don't do it the way you're trying to do it.

Take a step back. What is the fundamental problem you're trying to solve? Consistency. You are trying to ensure that the "x is a child of y" relationship and the "y is the parent of x" relationship are always consistent. That's a sensible goal.

Your supposition is that every item directly knows both its children and its parent because the children collection and the parent reference are stored locally in fields. This logically requires that when item x becomes a child of item y, you have to consistently change both x.Parent and y.Children. That presents the problem that you've run into: who gets to be "in charge" of making sure that both changes are made consistently? And how do you ensure that only the "in charge" code gets to mutate the parent field?

Tricky.

Suppose we denied your supposition. It need not be the case that every item knows both its children and its parent.

Technique #1:

For example, you could say that there is one special item called "the universe", which is the ancestor of every item except itself. "The universe" could be a singleton stored in a well-known location. When you ask an item for its parent, the implementation could find the universe, and then do a search of every descendant of the universe looking for the item, keeping track of the path as you go. When you find the item, great, you're done. You look one step back on the "path" that got you there, and you have the parent. Even better, you can provide the entire chain of parents if you want; after all, you just computed it.

Technique #2:

That could be expensive if the universe is large and it takes a while to find each item. Another solution would be to have the universe contain a hash table that maps items to their parents, and a second hash table that maps items to a list of their children. When you add child x to parent y, the "add" method actually calls the Universe and says "hey, item x is now parented by y", and the Universe takes care of updating the hash tables. Items do not contain any of their own "connectedness" information; that's the responsibility of the universe to enforce.

A down side of that is it is possible for the universe to then contain cycles; you could tell the universe that x is parented by y and y is parented by x. If you wish to avoid this then you'd have to write a cycle detector.

Technique #3:

You could say that there are two trees; the "real" tree and the "facade" tree. The real tree is immutable and persistent. In the real tree, every item knows its children but not its parent. Once you have built the immutable real tree, you make a facade node that is a proxy to the root of the real tree. When you ask that node for its children, it makes a new facade node wrapped around each child and sets the parent property of the facade node to the node that was queried for its children.

Now you can treat the facade tree as a parented tree, but the parent relationships are only computed as you traverse the tree.

When you want to edit the tree, you produce a new real tree, re-using as much of the old real tree as possible. You then make a new facade root.

The downside of this approach is that it only works if you typically traverse the tree from the top down after every edit.

We use this latter approach in the C# and VB compilers because that is precisely the situation we are in: when we rebuild a parse tree after a code edit we can re-use much of the existing immutable parse tree from the previous text. We always traverse the tree from the top down, and only want to compute the parent references when necessary.

回答2:

C# Doesn't have a friend keyword, but it has something close called internal. You could mark the methods you want to expose in a limited fashion as internal and then only other types in that assembly will be able to see them. If all your code is in one assembly, this won't help you much, but if this class is packaged in a separate assembly it would work.

public class Item
{
    public string Name{ get; set; }
    public Item Parent{ get; internal set; } // changed to internal...
    public ItemsCollection ChildItems;

    public Item()
    {
        this.ChildItems = new ItemsCollection (this);
    }
}

回答3:

Here's a way you can simulate friend in C#:

Mark your properties internal and then use this attribute to expose them to friend assemblies:

[assembly: InternalsVisibleTo("Friend1, PublicKey=002400000480000094" + 
                              "0000000602000000240000525341310004000" +
                              "001000100bf8c25fcd44838d87e245ab35bf7" +
                              "3ba2615707feea295709559b3de903fb95a93" +
                              "3d2729967c3184a97d7b84c7547cd87e435b5" +
                              "6bdf8621bcb62b59c00c88bd83aa62c4fcdd4" +
                              "712da72eec2533dc00f8529c3a0bbb4103282" +
                              "f0d894d5f34e9f0103c473dce9f4b457a5dee" +
                              "fd8f920d8681ed6dfcb0a81e96bd9b176525a" +
                              "26e0b3")]

public class MyClass {
   // code...
}

回答4:

The only two things I can think of:

One:

Use sort of option number 2 you mention above (which I do constantly myself)...but make the implementation of the interface (Item) be a nested private class inside of ItemsCollection... that way only ItemsCollection knows about the setter. The interface IItem only declares a getter for Parent...and no one can cast it to Item because Item is private to ItemsCollection. So, something like:

public class ItemsCollection : ObservableCollection<IItem>
{
    private class Item : IItem 
    {
        public object Parent { get; set; }
    }

    private CheckParent(IItem item)
    {
        if(item.Parent != null) throw new Exception("Item already belongs to another ItemsCollection");
        ((Item)item).Parent = this.Owner; // <-- This is where we need to access the private Parent setter
    }

    public static IItem CreateItem() { return new Item(); }
}

public interface IItem 
{
    object Parent {get; }
}

and when you want ItemsCollection to set the item Parent, case the IItem instance to Item (which does expose a setter). Only ItemsCollection can do this cast, since the Item implementation is private to ItemsCollection...so I think that accomplishes what you want.

Two:

Make it internal not private...you don't get exactly what you want, but you can use InternalsVisibleToAttribute to denote that the internal members are visible to another assembly.

回答5:

The first thing that struck me with this scenario is that there is definite feature envy between ItemCollection and Item. I understand your desire to make adding the child item to the collection and setting the parent to be an autonomous operation, but really I think the responsibility of maintaining that relationship is in the Item, not the ItemCollection.

I would recommend exposing the ChildItems on Item as a Read-Only collection (with IEnumerable<Item> perhaps), and putting the AddChild(Item child),RemoveChild(Item child), ClearChildren(), etc methods on the Item. That puts the responsibility for maintaining the Parent with the Item where you don't have concerns leaking into other classes.

回答6:

How about you make sure that only the item's current collection can orphan the item. That way no other collection can set the item's parent while it belongs to a collection. You could use a unique key of some sort so that a third party couldn't get involved:

public sealed class ItemsCollection : ObservableCollection<Item>
{
    private Dictionary<Item, Guid> guids = new Dictionary<Item, Guid>();

    public ItemsCollection(Item owner)
    {
        this.Owner = owner;
    }

    public Item Owner { get; private set; }

    private Guid CheckParent(Item item)
    {
        if (item.Parent != null)
            throw new Exception("Item already belongs to another ItemsCollection");
        //item.Parent = this.Owner; // <-- This is where we need to access the private Parent setter     
        return item.BecomeMemberOf(this);

    }

    protected override void InsertItem(int index, Item item)
    {
        Guid g = CheckParent(item);
        base.InsertItem(index, item);
        guids.Add(item, g);
    }

    protected override void RemoveItem(int index)
    {
        Item item = this[index];
        DisownItem(item);
        base.RemoveItem(index);
    }

    protected override void DisownItem(Item item)
    {
        item.BecomeOrphan(guids[item]);
        guids.Remove(item);            
    }

    protected override void SetItem(int index, Item item)
    {
        var existingItem = this[index];
        if (item == existingItem)
            return;
        Guid g = CheckParent(item);
        existingItem.BecomeOrphan(guids[existingItem]);
        base.SetItem(index, item);
        guids.Add(item, g);
    }

    protected override void ClearItems()
    {
        foreach (var item in this)
            DisownItem(item);
        base.ClearItems();
    }
}




public class Item
{
    public string Name { get; set; }
    public Item Parent { get; private set; }

    public ItemsCollection ChildItems;

    public Item()
    {
        this.ChildItems = new ItemsCollection(this);
    }

    private Guid guid;

    public Guid BecomeMemberOf(ItemsCollection collection)
    {
        if (Parent != null)
            throw new Exception("Item already belongs to another ItemsCollection");
        Parent = collection.Owner;
        guid = new Guid();
        return guid; // collection stores this privately         
    }

    public void BecomeOrphan(Guid guid) // collection passes back stored guid         
    {
        if (guid != this.guid)
            throw new InvalidOperationException("Item can only be orphaned by its current collection");
        Parent = null;
    }
}

Obviously there is redundancy there; the item collection is storing a second item collection (the dictionary). But there are numerous options for overcoming that which I assume you can think of. It's beside the point here.

However I do suggest you consider moving the task of child-item management to the item class, and keep the collection as 'dumb' as possible.

EDIT: in response to your quesion, how does this prevent and item from being in two ItemsCollections:

You ask what the point of the guids is. Why not just use the collection instance itself?

If you replace the guid argument with a collection reference, you could add an item to two different collections like this:

{
    collection1.InsertItem(item);  // item parent now == collection1
    collection2.InsertItem(item);  // fails, but I can get around it:
    item.BecomeOrphan(collection1); // item parent now == null 
    collection2.InsertItem(item);  // collection2 hijacks item by changing its parent (and exists in both collections)
}

Now imagine doing this with the guid argument:

{
    collection1.InsertItem(item);  // item parent now == collection1
    collection2.InsertItem(item);  // fails, so...
    item.BecomeOrphan(????); // can't do it because I don't know the guid, only collection1 knows it.
}

So you can't add an item to more than one ItemsCollection. And ItemsCollection is sealed so you can't subclass it and override its Insert method (and even if you did that, you still couldn't change the item's parent).

回答7:

You can do these sorts of things using Delegates:

public delegate void ItemParentChangerDelegate(Item item, Item newParent);

public class Item
{
    public string Name{ get; set; }
    public Item Parent{ get; private set; }
    public ItemsCollection ChildItems;

    static Item()
    {
        // I hereby empower ItemsCollection to be able to set the Parent property:
        ItemsCollection.ItemParentChanger = (item, parent) => { item.Parent = parent };
        // Now I just have to trust the ItemsCollection not to do evil things with it, such as passing it to someone else...
    }
    public static void Dummy() { }

    public Item()
    {
        this.ChildItems = new ItemsCollection (this);
    }
}

public class ItemsCollection : ObservableCollection<Item>
{
    static ItemsCollection()
    {
        /* Forces the static constructor of Item to run, so if anyone tries to set ItemParentChanger,
        it runs this static constructor, which in turn runs the static constructor of Item,
        which sets ItemParentChanger before the initial call can complete.*/
        Item.Dummy();
    }
    private static object itemParentChangerLock = new object();
    private static ItemParentChangerDelegate itemParentChanger;
    public static ItemParentChangerDelegate ItemParentChanger
    {
        private get
        {
            return itemParentChanger;
        }
        set
        {
            lock (itemParentChangerLock)
            {
                if (itemParentChanger != null)
                {
                    throw new InvalidStateException("ItemParentChanger has already been initialised!");
                }
                itemParentChanger = value;
            }
        }
    }

    public ItemsCollection(Item owner)
    {
        this.Owner = owner;
    }   

    public Item Owner{ get; private set; }

    private CheckParent(Item item)
    {
        if(item.Parent != null) throw new Exception("Item already belongs to another ItemsCollection");
        //item.Parent = this.Owner;
        ItemParentChanger(item, this.Owner); // Perfectly legal! :)
    }

    protected override void InsertItem(int index, Item item)
    {
        CheckParent(item);
        base.InsertItem(index, item);
    }

    protected override void RemoveItem(int index)
    {
        ItemParentChanger(this[index], null);
        base.RemoveItem(index);
    }

    protected override void SetItem(int index, Item item)
    {
        var existingItem = this[index];

        if(item == existingItem) return;

        CheckParent(item);
        ItemParentChanger(existingItem, null);

        base.SetItem(index, item);
    }

    protected override void ClearItems()
    {
        foreach(var item in this) ItemParentChanger(item, null);
        base.ClearItems();
    }

回答8:

My answer is built off of two parts

1. Why is it so "Unsafe" to have the Interface ISetParent?

private/internal access modifiers are ment to prevent from mistakes, not really "Secure Code".

Remember... you can call private methods using some Reflections/Invoke Etc...

.

2 . i usually make everything public and make sure both sides know how to handle each other,

ofcourse, there is a little ping-pong but it takes just few cycles (in this case i have a NamedSet)

    private IPhysicalObject partOf;
    public IPhysicalObject PartOf
    {
        get { return partOf; }
        set
        {
            if (partOf != value)
            {
                if (partOf != null)
                    partOf.Children.Remove(this.Designation);

                partOf = value;

                if (partOf != null)
                    partOf.Children.Add(this.Designation);
            }
        }
    }

    public virtual void Add(String key, IPhysicalObject value)
    {
        IPhysicalObject o;
        if (!TryGetValue(key, out o))
        {
            innerDictionary.Add(key, value);
            value.PartOf = Parent;
        }
    }

    public virtual bool Remove(String key)
    {
        IPhysicalObject o;
        if(TryGetValue(key, out o))
        {
            innerDictionary.Remove(key);
            o.PartOf = null;
        }
    }

Hope this helps... Good Day, Tomer W.

P.S. I'll never get how this Editor is working... should i HTML it, or should i not?

回答9:

One solution I've used to control visibility of class members is to define the class as partial, and then in a different namespace declare the class as partial, and define the special visibility members you want.

This controls member visibility depending on the namespace chosen.

The only thing you'll have to wrap your head around is referencing. It can get complex, but once you have it figured out, it works.