هل تنفجر طريقة العرض السلبي قانون demeter؟

Question

أحاول أن أفهم كيفية استخدام طريقة عرض سلبية بشكل صحيح. يبدو لي أن كل أمثلة ننظر في عرض سلبي يكسر قانون Demeter:

//In the presenter code
myview.mytextfield.text = "whatever";

إذن ما هو التنفيذ الأفضل للمنظر السلبي؟

Answer 1

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

يحاول قانون demeter منع تسخين التبعية مثل:

objectA.objectB.objectC.DoSomething();

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

في حالة ما اذا عرض سلبي

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

لذلك فإن المثال الذي أعطيته ستنفذ عادة:

//from presenter
view.MeaningfulName = "data";

في حين أن الرأي سيكون مثل:

//from view
public string MeaninfulName
{
    get
    {
        return someControl.text;
    }
    set
    {
        someControl.text = value;
    }

آمل أن يوضح هذا الأشياء قليلا.

Answer 2

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

لذلك، لا يتعين على مقدم العرض معرفة أي شيء عن الرأي وقانون demeter آمن.

Answer 3

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

أعتقد أنه حان الوقت لسؤال ما إذا كان لديك الواجهة الصحيحة بشكل عام. ماذا نكون هذه الحقول النصية؟ من يضعهم في المنظر؟ ألا ينبغي أن يسأل الرأي عن نموذج البيانات، بدلا من العكس؟

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

---

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

لا تحتاج إلى نمط المراقب، لأنك الآن لديك وحدة التحكم في صنع جميع التحديثات. يضيف بعض التعقيد وخطول الأخطاء إلى التعليمات البرمجية الإجمالية، لأنك الآن تأكد من كتابة وحدة تحكم لتحديثات متوازية.