متى تستخدم الإشارات والفتحات ومتى لا

Question

نحن نستخدم QT الذي يقدم إشارات وفتحات أجدها هل حقا مناسب. ومع ذلك ، مع القوة العظيمة تأتي مسؤولية كبيرة وأعتقد أنه من السهل جدًا إساءة استخدام هذه الميزة.

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

• هل من المقبول استخدام الإشارات للإبلاغ عن الأخطاء؟
• هل من المقبول افتراض أنه سيتم التعامل مع الإشارة؟
• هل يمكن استخدام الإشارات لبدء الإجراءات؟ على سبيل المثال signal displayInfoScreen() يجب التعامل معها بواسطة فتحة تعرض شاشة معلومات.

أي آراء أخرى حول متى يجب/لا ينبغي استخدام الإشارات جداً أهلا بك!

Answer 1

هل من المقبول استخدام الإشارات للإبلاغ
أخطاء؟

نعم ، على سبيل المثال ، انظر QFTP ، حيث تحمل الإشارة التي تم القيام بها حالة. لا يحمل الخطأ الفعلي ، فقط معلومات حدث خطأ.

هل من المقبول افتراض أنه سيتم التعامل مع الإشارة؟

لا. لا يمكن للمرسل أن يفترض أبدًا أنه ، ومع ذلك ، يمكن أن يعتمد تطبيقك الخاص عليه. على سبيل المثال ، يتم التعامل مع QACTION التي تمثل الملف - احتياجات جديدة للتطبيق للعمل ، ولكن لا يمكن أن يهتم كائن QACTION بدرجة أقل.

هل يمكن استخدام الإشارات لبدء الإجراءات؟ على سبيل المثال ، يجب معالجة DisplayInfoscreen () بواسطة فتحة تعرض شاشة معلومات.

مرة أخرى ، نعم ، على سبيل المثال كائن qacty. ولكن إذا كنت تريد أن تكون قادرًا على إعادة استخدام المكونات ، فيجب أن تكون حريصًا على التأكد من أن الفئة الفعلية لا تعتمد عليها.

Answer 2

الإشارات والفتحات قوية لأن الكائنات Decoubles. لا يمكنك افتراض أن الإشارة لها فتحة متصلة ، كما تم الرد عليها سابقًا.

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

Answer 3

هل من المقبول افتراض أنه سيتم التعامل مع الإشارة؟

لا ليس كذلك. الإشارات هي نوع من الأشياء. من يتصل بالإشارة وما تفعله لا ينبغي أن يكون مصدر قلق باعث.

Answer 4

هل من المقبول استخدام الإشارات للإبلاغ عن الأخطاء؟

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

وأيضًا ، يمكن أن تجعل آليات انتقاد الإشارة اتصالًا متقاطعًا أسهل (والتي يمكن اعتبارها الحالة غير المتزامنة) ، وسأستخدمها لهذا الغرض (خطأ أو لا).

هل من المقبول افتراض أنه سيتم التعامل مع الإشارة؟

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

هل يمكن استخدام الإشارات لبدء الإجراءات؟ على سبيل المثال ، يجب معالجة DisplayInfoscreen () بواسطة فتحة تعرض شاشة معلومات.

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

Answer 5

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

على سبيل المثال ، بدلاً من وجود طرق عرض يفهم كيفية عمل النموذج ، وعندما يتغير النموذج ، فإنهم "يستمعون" إلى النموذج. النموذج مسؤول عن قوله عندما يتغير ، وما الذي يتغير.

المشكلة في الأحداث هي عند تصميم الأحداث الخاصة بك مع متطلبات العميل. على سبيل المثال ، يجب ألا يكون لديك إشارة displayInfoScreen لأنه يفترض شيئًا عن الكائنات باستخدام هذه الإشارة. بدلاً من ذلك ، يجب أن يكون infoChanged و ال InfoScreenDisplayer يستمع إلى هذه الإشارات لعرضها على الشاشة. إذا كنت بحاجة ، يمكنك إضافة لاحقًا InfoTweeterPoster هذا ينشر المعلومات على مكبر الصوت كلما تغيرت.