गतिशील राज्य मशीन? क्या राज्य मशीनों को कक्षाएं होनी चाहिए?

Question

प्रश्न यह है कि, राज्य मशीन हमेशा स्थाई रूप से परिभाषित (कक्षाओं पर) हैं? या मेरे पास ऐसा करने का कोई तरीका है, इसलिए कक्षा के प्रत्येक उदाहरण के साथ यह राज्यों का अपना सेट है?

मैं कार्य इंजन को लागू करने के लिए Stonepath देख रहा हूं। मैं वास्तव में वहां "राज्यों" और "कार्यों" के बीच भेद नहीं देखता, इसलिए मुझे लगता है कि मैं सिर्फ एक राज्य को एक कार्य को मानचित्र बना सकता हूं। इस तरह काम करने के लिए बिना, मुझे काम सूचियों (या वर्कफ़्लो) गतिशील रूप से परिभाषित करने के लिए सक्षम होने के लिए अनुमति होगी: इसके बजाय

aasm_event :evaluate do 
    transitions :to => :in_evaluation, :from => :pending 
end 

aasm_event :accept do 
    transitions :to => :accepted, :from => :pending 
end 

aasm_event :reject do 
    transitions :to => :rejected, :from => :pending 
end 

, एक WorkItem (मुख्य कार्यप्रवाह/कार्य प्रबंधक मॉडल), बस कई होता कार्य। तब कार्यों राज्यों की तरह काम करेगा, तो मैं कुछ इस तरह कर सकता है:

aasm_initial_state :initial 

tasks.each do |task| 
    aasm_state task.name.to_sym 
end 

previous_state = nil 
tasks.each do |tasks| 
    aasm_event task.name.to_sym do 
    transitions :to => "#{task.name}_phase".to_sym, :from => previous_state ? "#{task.name}_phase" : "initial" 
    end 
    previous_state = state 
end 

हालांकि, मैं ऐसा नहीं कर सकते कि साथ aasm gem क्योंकि उन तरीकों (aasm_state और aasm_event) वर्ग के तरीकों, इसलिए के प्रत्येक उदाहरण हैं उस राज्य मशीन के साथ कक्षा में एक ही राज्य है। मुझे यह चाहिए कि "वर्कइटम" या "टास्कलिस्ट" द्विपक्षीय रूप से कार्यों के आधार पर राज्यों और संक्रमणों का अनुक्रम बनाता है।

यह मुझे वर्कफ़्लो को गतिशील रूप से परिभाषित करने की अनुमति देगा और केवल राज्यों को कार्यों के लिए नक्शा देगा।

क्या राज्य मशीनें कभी इस तरह उपयोग की जाती हैं? ऐसा लगता है कि यह ruby workflow gem जो मैं वर्णन कर रहा हूं उसके समान है।

अद्यतन: मैं निम्नलिखित की तरह कुछ कर रही देख सकते हैं, लेकिन यह एक तरह से hackish लगता है:

@implementation_state_machine = Class::new do 
    include AASM 
    aasm_initial_state :initial 

    tasks.each { |state| aasm_state :"#{task.name}"} 
    # ... 
end 

... जहाँ मेरे मॉडल पर एक संपत्ति implementation_state_machine होगा। कार्यान्वयन अज्ञात वर्ग में राज्य से संबंधित विधियों (accepted_phase?) को प्रतिनिधि देने के लिए मुझे method_missing ओवरराइड करना होगा।

Answer 1

हाँ, यह बहुत हैकी और काफी गन्दा लग रहा है। मैंने हाल ही में एक नया मणि लिखा है जो आपको निर्णय सेटिंग के साथ गतिशील 'टू' संक्रमण का उपयोग करने की अनुमति देता है।

तो अपनी घटनाओं और संक्रमणों को गतिशील रूप से बनाने के बजाय, क्या उन्हें पहले मानचित्र बनाना संभव होगा, और निर्णय लेने का निर्णय लें कि संक्रमण किस नए राज्य में प्रवेश करेगा? आप अपने सरणी में संक्रमण से भी लपेट सकते हैं ताकि आपको ऐसा करने की आवश्यकता न हो: = = पिछली_स्टेट से? "# {task.name} _phase": "प्रारंभिक", आप बस कर सकते हैं: से => [: cool_task_phase, प्रारंभिक]

मुझे लगता है कि आपके संक्रमण और घटनाओं को पहले सेट करना, आपको एक प्राप्त करने की अनुमति देता है आपका मॉडल क्या कर रहा है उस पर अधिक तस्वीर।

http://github.com/ryanza/stateflow

इसे यहां देखें उम्मीद है कि आप इस से बाहर कुछ का उपयोग पा सकते हैं।

Answer 2

मेरी कार्यान्वयन राज्य मशीन में एक हैश https://github.com/mpapis/state_attr

state_attr :state, { 
    nil => :first, 
    :first => [:second, :third], 
    :second => :last, 
    :third => nil, 
} 

आप को परिभाषित कर सकते है के रूप में कई राज्य आप

BTW तरह के रूप में जिम्मेदार बताते हैं: पृष्ठभूमि में वहाँ अभी भी एक वर्ग है, लेकिन केवल करने के लिए एक प्रॉक्सी के रूप में विशेषता