تصميم جيد لبناء برنامج كامل باعتباره FSM؟

Question

لقد قمت ببناء محلل باستخدام نهج FSM/Pushdown Automaton مثل هنا (وهو يعمل ، حسناً!): تصميم وملكية C ++ FSMيسمح لي بالخروج بأمان وإخراج رسالة خطأ مفيدة للمستخدم عندما يحدث خطأ ما في مرحلة المحلل.

لقد كنت أتساءل عن طريقة جيدة لإنجاز ذلك في بقية برنامجي ، وبطبيعة الحال ، برزت نهج المحلل في ذهني ...

أود أن أجعل كل كائن حالة ، التي لديها وظيفة حدث واحد () تحتوي على وظائف محددة لبيان تبديل استدعاء اعتمادًا على مرحلة التنفيذ. يمكنني تتبع ذلك باستخدام التعداد الخاص بالكائن ، والحفاظ على الكود أكثر قابلية للقراءة (case parser أكثر قابلية للقراءة من case 5). سيسمح لي هذا بإغلاق شجرة الحالات التي قمت بإنشائها (باستخدام m_parent* نهج في سؤالي الآخر).

هل هذا التصميم الجيد (إجبار كل شيء في وضع FSM)؟ هل هناك طريقة أفضل ، وكم سيكون أكثر تعقيدًا (أجد أن FSM سهل التنفيذ والاختبار)؟

شكرا للاقتراحات!

ملاحظة: أعرف أن Boost لديه كل ما قد يحتاجه المرء على الإطلاق ، لكنني أريد الحد من التبعيات الخارجية ، وخاصة على Boost. C ++ 0x على ما يرام (ولكن ليس من المهم هنا أعتقد)

Answer 1

ما تفعله يشبه إلى حد ما بناء جهاز افتراضي (بسيط) في برنامجك. يميل FSM إلى أن يكون مناسبًا لبعض المشكلات المقيدة مثل Lexing و Exting ، وكما لاحظت على الأرجح ، يمكنك الحصول على قدر كبير من التسجيل وإدارة الأخطاء "مجانًا".

ومع ذلك ، إذا حاولت تطبيق نمط FSM على كل شيء (الذي سيكون صعبًا بالنسبة لبرامج EG GUI التي تحتوي على الكثير من الحالة التي لا ترغب عادة في إدخالها في حالات واضحة) ، فستدرك ذلك تحتاج أيضًا إلى تسهيلات ل تصحيح FSM الخاص بك (نظرًا لأن مصحح الأخطاء C ++ لن يفهم حالاتك وأحداثك) والمرافق إليها الرابط وإعادة الاستخدام الدول (لأن الولايات لن تكون بنيات مستوى OO). إذا كنت ترغب في تسليم التعليمات البرمجية الخاصة بك إلى شخص آخر ، فسوف يحتاج إلى تدريب إضافي لاستخدام FSM بنجاح. هل تريد الاحتفاظ بمحرك FSM واحد لتطبيقات متعددة؟ إذا كان الأمر كذلك ، كيف ستتعامل مع الإصدار والترقيات؟

إستخدم الأداة المناسبة للعمل المناسب. كل نهج له نقاط القوة والضعف. الحل الخاص بك يضيف طبقة أخرى من تعقيد: يمكنك التعامل مع التسجيل ومعالجة الأخطاء في طرق أكثر C ++-ISH. إذا لم تكن راضيًا عن كتابة رمز C ++ ، فقد تفكر في اللغات الموجودة الأخرى ، بدلاً من إنشاء لغة FSM التي تفهمها فقط.

Answer 2

سيستخدم معظم الناس الميراث بدلاً من التبديل/الحالة/الافتراضي. ومع ذلك ، فإن فكرة إجبار كل شيء على أن يكون بطريقة واحدة خاطئة بطبيعتها. يجب أن تتعامل دائمًا مع كل وظيفة مطلوبة بمزاياها الخاصة.

Answer 3

يمكنك دائمًا إلقاء نظرة على تعزيز.