كيف يمكنني تنظيم الوحدات بشكل متماسك لتطبيق PyGTK لسطح المكتب؟

Question

أنا أعمل على تطبيق سطح مكتب في PyGTK ويبدو أنني أواجه بعض القيود المفروضة على تنظيم الملفات الخاصة بي.لقد قمت حتى الآن بتنظيم مشروعي بهذه الطريقة:

• application.py - يحمل فئة التطبيق الأساسية (معظم الإجراءات الوظيفية)
• gui.py - يحمل تطبيق واجهة المستخدم الرسومية GTK المقترن بشكل غير محكم.يعالج عمليات الاسترجاعات للإشارة، وما إلى ذلك.
• Command.py - يحمل وظائف أتمتة سطر الأوامر التي لا تعتمد على البيانات الموجودة في فئة التطبيق
• State.py - يحمل فئة ثبات بيانات الحالة

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

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

هل يجب أن أتعامل فقط مع وجود وحدة مركزية طويلة جدًا أم أن هناك طريقة أفضل لتنظيم المشروع حتى لا أضطر إلى الاعتماد على متصفح الفصل كثيرًا؟

تحرير أنا

حسنًا، لقد تم أخذ النقطة فيما يتعلق بجميع عناصر MVC.لدي تقدير تقريبي لـ MVC في الكود الخاص بي، ولكن من المسلم به أنه ربما يمكنني الحصول على بعض الأميال من خلال الفصل الإضافي بين النموذج ووحدة التحكم.ومع ذلك، فأنا أقرأ وثائق python-gtkmvc (وهو اكتشاف رائع بالمناسبة، شكرًا لك على الرجوع إليه) وانطباعي هو أنه لن يحل مشكلتي بقدر ما سيضفي عليها طابعًا رسميًا.تطبيقي عبارة عن ملف زجاجي واحد، وعادة ما يكون نافذة واحدة.لذا، بغض النظر عن مدى إحكام تحديد أدوار MVC للوحدات، سأظل أملك وحدة تحكم واحدة تقوم بمعظم كل شيء، وهو ما لدي الآن تقريبًا.من المسلم به أنني غير واضح بعض الشيء بشأن تنفيذ MVC المناسب وسأواصل البحث، لكن لا يبدو لي أن هذه البنية ستخرج أي أشياء أخرى من ملفي الرئيسي، بل ستعيد تسمية ذلك فقط ملف إلى وحدة تحكم.py.

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

كثير من الناس يمكن أن استفاد من كتاباتك.

Answer 1

في المشروع الخواض نحن نستخدم بيثون gtkmvc, ، وهذا يجعل تطبيق أنماط MVC أسهل بكثير عند استخدام pygtk وglade، ويمكنك رؤية تنظيم الملفات لمشروعنا في مستودع svn:

wader/
  cli/
  common/
  contrib/
  gtk/
    controllers/
    models/
    views/
  test/
  utils/

Answer 2

من المحتمل ألا يكون لهذا علاقة بـ PyGTK، بل هو مشكلة عامة في تنظيم التعليمات البرمجية.ربما ستستفيد من تطبيق بعض أنماط تصميم MVC (Model-View-Controller).يرى أنماط التصميم, ، على سبيل المثال.

Answer 3

"يحمل فئة التطبيق الأساسية (معظم الإجراءات الوظيفية)"

كما في المفرد - فئة واحدة؟

أنا لست مندهشا أن فئة واحدة تفعل كل شيء التصميم لا يعمل.قد لا يكون ما أسميه موجهًا للكائنات.لا يبدو أنه يتبع نمط تصميم MVC النموذجي إذا كانت وظائفك تتراكم في فئة واحدة.

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

1. قبل القيام بأي شيء آخر، قم بإعادة البناء إلى مكونات توازي كيانات العالم الحقيقي.ليس من الواضح ما هو موجود في "state.py" الخاص بك - سواء كان هذا نموذجًا مناسبًا لكيانات العالم الحقيقي، أو مجرد تعيينات بين التخزين المستمر وبعض هياكل البيانات الغامضة في التطبيق.على الأرجح أنك ستنقل المعالجة من التطبيق الخاص بك إلى النموذج الخاص بك (ربما State.py، وربما وحدة نمطية جديدة تمثل نموذجًا مناسبًا.)

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

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

Answer 4

آسف للرد في وقت متأخر جدا. كيوي يبدو لي حلاً أفضل بكثير من gtkmvc.إنها تبعيتي الأولى لأي مشروع pygtk.

Answer 5

يدعم بايثون 2.6 الواردات النسبية الصريحة, مما يجعل استخدام الحزم أسهل من الإصدارات السابقة.أقترح عليك النظر في تقسيم تطبيقك إلى وحدات أصغر داخل الحزمة.يمكنك تنظيم التطبيق الخاص بك مثل هذا:

myapp/
  application/
  gui/
  command/
  state/

حيث كل دليل له خاصته __init__.py.يمكنك إلقاء نظرة على أي تطبيق بيثون أو حتى وحدات المكتبة القياسية للحصول على أمثلة.

Answer 6

لذا، نظرًا لعدم تلقي أي رد بخصوص تعديلي للسؤال الأصلي، فقد أجريت المزيد من البحث والنتيجة التي يبدو أنني توصلت إليها هي ذلك نعم, ، يجب أن أقوم بتقسيم الواجهة إلى عدة طرق عرض، كل منها مزود بوحدة التحكم الخاصة به.يوفر Python-gtkmvc القدرة على ذلك من خلال توفير ملف glade_top_widget_name المعلمة إلى منشئ العرض.يبدو أن كل هذا منطقي إلى حد كبير على الرغم من أنه سيتطلب إعادة هيكلة كبيرة لقاعدة التعليمات البرمجية الحالية الخاصة بي والتي قد أكون أو لا أرغب في القيام بها على المدى القريب (أعلم، أعرف، أنا يجب.) علاوة على ذلك، لم يبق لي سوى التساؤل عما إذا كان يجب أن يكون لدي كائن نموذج واحد فقط (طلبي بسيط إلى حد ما - لا يزيد عن خمسة وعشرين حالة متغيرة) أو ما إذا كان ينبغي علي تقسيمه إلى نماذج متعددة ويجب علي التعامل معها وحدات التحكم تراقب نماذج متعددة وتسلسل الإخطارات عبرها.(مرة أخرى، أعرف أنني حقًا يجب افعل الأخير.) إذا كان لدى أي شخص أي فكرة إضافية، ما زلت لا أشعر حقًا أنني حصلت على إجابة للسؤال الأصلي، على الرغم من أن لدي اتجاهًا للتوجه إليه الآن.

(علاوة على ذلك، يبدو أنه يجب أن تكون هناك خيارات معمارية أخرى في متناول اليد، نظرًا لأنني حتى الآن لم أر تطبيق Python واحدًا مشفرًا بأسلوب MVC، ولكن مرة أخرى تميل العديد من تطبيقات Python إلى مواجهة المشكلة الدقيقة التي وصفتها فوق.)