Advise on pattern choice object state based on components

Go To StackoverFlow.com

0

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
    }
2012-04-05 15:17
by Pharabus
Can you add some psuedo code - Nick 2012-04-05 15:19
With each sibling object the composition of its child objects would determe it's "type" - type as in 'state' or actually a 'type' - I think you ought to provide some code - make a few FooA and with 'hierarchy' you have - it's hard to follow like this, could mean too many things - NSGaga 2012-04-05 15:27
@NSGaga i will work on some code now, yeah they are both "states" really though the state of the parent object only exists by interogating it's children, it is the state discovered by interrogating the siblings together that needs persisting on each parent objec - Pharabus 2012-04-05 15:30
how often do you have states updated? and do you need to persist the state alongside the (e.g. parent) object - or if it's an occasional walk through this might be done differently. Just put in as much as you have, seems like an interesting design problem. Also what's the nature of the 'thing', as that often tells more, what's that you're trying to solve, w/o of course revealing your trade secrets: - NSGaga 2012-04-05 15:34
@Nick edit to add detai - Pharabus 2012-04-05 15:47


2

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.

2012-04-05 15:51
by Wiktor Zychla
thanks, this looks like it will fit nicel - Pharabus 2012-04-05 16:41


0

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.

2012-04-05 15:58
by Ivo


0

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

2012-04-05 16:02
by surfen
Ads