tags:

views:

123

answers:

6

I'm facing a situation where I have dependent objects and I would like to be able to remove an object and all references to it.

Say I have an object structure like the code below, with a Branch type which references two Nodes.

public class Node
{
    // Has Some Data!
}

public class Branch
{
    // Contains references to Nodes
    public Node NodeA
    public Node NodeB
}

public class Graph
{
    public List<Node> Nodes;
    public List<Branch> Branches;
}

If I remove a Node from the Nodes list in the Graph class, it is still possible that one or more Branch objects still contains a reference to the removed Node, thus retaining it in memory, whereas really what I would quite like would be to set any references to the removed Node to null and let the garbage collection kick in.

Other than enumerating through each Branch and checking each Node reference sequentially, are there any smart ideas on how I remove references to the Node in each Branch instance AND indeed any other class which reference the removed Node?

A: 

Some class holding a reference to a Node would not like it, if some mechanism just deletes this reference. And no, there is no other way. You have to iterate and set them to null manually. But if Node represents a limited or memroy intensive resource, you should consider managingaccess to it better, perhaps at a central place.

Danvil
Thanks very much for all your responses, it's certainly given me something to think about. I think I'll go down the route which Hightechrider has suggested, until I hit some problems. For that reason I've accepted his answer.
LiamV
+5  A: 

There's no built-in C# language feature to facilate that (you can't really track assignments). You'll have to keep track of all references somewhere and update it as soon as you're assigning a new reference to it. A very general idea is to provide a Removed event in the Node itself and raise the event when the object is supposed to be abandoned. Every time you want to hold on a new reference to the Node, you'd subscribe to the event with a matching delegate that nulls out the reference to that object. Of course, if you're doing this with a set of previously known types that reference the node in a specific way, there may be easier and more efficient ways to accomplish the task.

Mehrdad Afshari
A: 

Try WeakReference as a wrapper for Node or Branch, lists will contain these weak references.

Karel Frajtak
`WeakReference` will eliminate the garbage collection problem but it won't tackle the issue if you need to update the data structures appropriately in different places as soon as a node is removed.
Mehrdad Afshari
so implement events OnAdded, OnRemoved and keep backward references - so each Node will know about a Branch it is in.
Karel Frajtak
A: 

You can certainly query your branch elements for references to each node that you're removing, something like this example

class Branch
{
    public Branch(Node nodeA, Node nodeB) { NodeA = nodeA; NodeB = nodeB; }
    public Node NodeA { get; set; }
    public Node NodeB { get; set; }
}

class Node
{
    public Node(string name) { Name = name; }
    public string Name { get; set; }
}

...

List<Node> nodes = new List<Node>() { new Node("Apple"), new Node("Banana") };
List<Branch> branches = new List<Branch>() { new Branch(nodes[0], nodes[1]), new Branch(nodes[1], nodes[0]) };

Node node = nodes[0];
nodes.Remove(node);

var query = from branch in branches
            where branch.NodeA == node || branch.NodeB == node 
            select branch;

foreach (Branch branch in query)
{
    if (branch.NodeA == node)
        branch.NodeA = null;
    if (branch.NodeB == node) // could just be 'else' if NodeA cannot equal NodeB
        branch.NodeB = null;
}

Which is fine for removing references in your list of branches. However, like Mehrdad points out, it becomes increasingly more difficult to wipe out all references if references to your Node object are more prolific.

Anthony Pegram
+1  A: 

Change your Node to include a list of the branches it is on:

public class Node
{
    // Has Some Data!

    public List<Branch> BranchesIn;
    public List<Branch> BranchesOut;  // assuming this is a directed graph

    public void Delete()
    {
      foreach (var branch in BranchesIn)
        branch.NodeB.BranchesOut.Remove(branch);

      foreach (var branch in BranchesOut)
        branch.NodeA.BranchesIn.Remove(branch);

      BranchesIn.Clear();
      BranchesOut.Clear();
     }
}

public class Branch
{
    // Contains references to Nodes
    public Node NodeA
    public Node NodeB
}

Now your Graph class doesn't need a List of Nodes or Branches, all it needs is a single Root Node. When you remove a Node you remove all the branches off it. Clearly you encapsulate all the methods to add and remove nodes and branches so external code can't break the structure.

If you aren't actually storing any data on the Branch (more typically called an Edge) you don't need it at all. Nodes can just maintain a list of the other nodes they link in from and out to.

Hightechrider
You are correct that I do not need a list of nodes or branches based on the information I've given, but there are other factors that you probably wouldn't know to consider.For example, this data will actually be stored within a database, therefore it is more appropriate to have lists of each type, which map to a database table.
LiamV
This structure can *easily* map to a database: table for Nodes, table for Edges, FK relationships between them. It's 100% a relational model. EF 4 can handle all the issues around lazily loading edges and nodes without any extra work. You get Node.Edges automatically, for free, when you import the database to an Entity Data Model. In fact it will make deleting easy too, when you remove an Edge it can automatically remove it from each Node.
Hightechrider
A: 

I recommend making it so that only your Graph knows about Branches and Nodes. That way you can control access and can make sure you know how to invalidate all of your own references. If you need to provide access to user data at a Node, you can provide methods to iterate over your structure, rather than giving access to the raw structure. You can embed user information in the structure classes via generics (i.e. a user-defined 'Tag' property for each Node and each Branch).

Dan Bryant