I am looking at the best way to implement this, essentially a pattern that would fit, given an object that has a relationship with siblings and children.

We have a complex set of rules that set the state of each object

e.g.

• n sibling objects of "type" A then the state of each is x
• n sibling objects "type" A and "type" B then state of each is y

There are probably 3 or 4 more variations on this

With each sibling object the composition of its child objects would determe it's "type"

Hope this is clear enough, please comment if you think I can add more clarification?

edit:

added some psuedo code

state to be persisted along side the Foo objecst (not the FooBar or Bar) and the state is updated on a user driven event (the user can ammedn the mix of Foos and the Bars that the have then generate the event to reinterigate, set states and persist to database)

hope this helps

void Main()
{


    var foobar = GrabAFooBar();
    //Each Foo will have its state set based on the rules in the question
    //eg
    //foobar has 2 Foos both of which only contain BarType1 then both foos have a State of StateOne
    //foobar has 2 foos, one has a BarType1 one has a BarType2 both foos have a State of StateTwo
    //foobar has 2 foos, one has a BarType1 and BarType3 one has a BarType2 both foos have a State of StateThree
    //effectivaly there are 5 States (currently) and a  well defined set of combinations
    //All foos will have the same state at the end of the process (there will never be a mix)

}

FooBar GrabAFooBar()
{
    //return a FooBar from data
}

// Define other methods and classes here

    class FooBar
    {
        List<Foo> Foos {get;set;}

    }
    class Foo
    {
        public List<Bar> Item {get;set;}
        public State state {get;set;}
    }
    abstract class Bar
    {

    }

    class BarType1 : Bar
    {
    }


    class BarType2 : Bar
    {
    }


    class BarType3 : Bar
    {
    }

    enum State
    {
        StateOne,
        StateTwo,
        StateThree
    }

• c#
• design-patterns

Chain of Responsibility sounds like one possible pattern here.

Each handler of the chain would be responsible for "matching" your object and returning the state or passing the object to the next handler in the chain. You can order handlers in the chain so that even if two or more handlers would accept the object, the order of the chain would determine your priorities.

I would suggest replace the enum with actual classes that will manage the logic:

public abstract class State {
    public bool AppliesTo( Foo foo );
}

public class StateOne : State {
    public override bool AppliesTo( Foo foo ){
        return foo.Item.All(x => x is Bar1);
    }
}
//etc.

The "x is Bar1" part is not good, you can use double dispatch for that.

I don't think there is a pattern for this, unless you would like to hear answers like Object Oriented Programming.

You've got many options, for example:

1. Calculate state on demand by calling a method/function that would calculate state and save it in a property State)

2. Create a property State getter, that would calculate the state each time it is called

3. Attach a CollectionChanged handler to sibling collection and update the state automatically after collection change

Choice between these would depend on how often your dependecies change, how often you need to find out the state, and how expensive your calculation is.

If the rules don't change a lot then you can hard-code them. But if they change, you should consider using rules engine, like for example Biztalk