Консультирование по выбору объекта состояния объекта на основе компонентов

Question

Я ищу лучший способ реализовать это, по существу, шаблон, который будет соответствовать, учитывая объект, который имеет отношения с родными братьями и детьми.

Мы имеем сложный набор правил, которые устанавливают состояние каждого объекта

например,

• п родственных объектов «типа» А, то состояние каждого является й
• п родственных объектов «типа» А и «типа» В затем состоянии каждый есть у

Есть вероятно, 3 или 4 больше вариаций на этой

с каждым собратом приемят состав его дочерних объектов будут determe это «тип»

Надеется, что это достаточно ясно, пожалуйста, комментарий, если вам й чернила Я могу добавить больше разъяснений?

редактировать:

добавил некоторые псевдо-код

состояние быть сохранялось вдоль стороны objecst Foo (не FooBar или бар) и состояние обновляется на управляемый пользователем событие (пользователь может ammedn смесь Фоос и баров, что потом генерировать событие reinterigate, набор состояний и сохраняются в базе данных)

надеюсь, что это помогает

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 
    } 

Answer 1

Цепь ответственности звучит как один из возможных вариантов здесь.

Каждый обработчик цепочки будет отвечать за «сопоставление» вашего объекта и возвращение состояния или передачу объекта следующему обработчику в цепочке. Вы можете упорядочить обработчики в цепочке, чтобы даже если два или более обработчика приняли объект, порядок цепочки определял бы ваши приоритеты.

Answer 2

Я хотел бы предложить заменить перечисление с реальными классами, который будет управлять логикой:

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. 

«X является Bar1» часть не очень хорошо, вы можете использовать двойную диспетчеризацию для этого.

Answer 3

Я не думаю, что для этого есть образец, если вы не хотите услышать ответы, такие как Object Oriented Programming.

У вас есть много вариантов, например:

1. Вычислить состояние по требованию путем вызова метода/функции, которая будет вычислять состояние и сохранить его в свойстве State)

2. Создайте свойство State геттер, который будет рассчитывать состояние каждый раз, когда он называется

3. Приложить обработчик CollectionChanged к родственным коллекции и обновить состояние автоматически после изменения коллекции

Выбор между ними будет зависеть от того, как часто меняют свои dependecies, как часто вам нужно выяснить состояние, и как дорого ваш расчет.

Если правила не сильно меняются, вы можете их жестко закодировать. Но если они меняются, вы должны рассмотреть возможность использования правил двигателя, например, Biztalk