أخبار من عدد من المستغرب سارة أيقظت كل أنواع الذكريات، الحلو وليس كثيرا جدا. حصلت أيضًا على هذه المقالة منها ، وسئمت على الفور من الحنين إلى الماضي ، وأردت أن ألعب مثل هذا القطع الثقيل منها على مدى السنوات السبع الماضية.
كان Dephi حلاً رائعًا للغاية. حسنًا ، كما تعلم ، مثل البيتلز ، كواجهة كمبيوتر رسومية مع التحكم بالماوس ، كمحرك احتراق داخلي. الحل المبتكر الذي ظهر في حياتنا على نطاق واسع بحيث لا يمكنك حتى تصديق أنه لم يكن موجودًا من قبل ، وقد يكون رسم النوافذ وخانات الاختيار والأزرار في Windows بمثابة ألم حقيقي.
كان الجزء المبتكر ، المطلق ، من Delphi هو VCL - نفس مجموعة مربعات الاختيار والأزرار الخاصة بنوافذ Windows ، والتي أصبحت فجأة سهلة وبسيطة للسحب والإفلات على بعضها البعض ، وإنشاء تطبيقات Windows جميلة وغير عادية.
ومثل أي واجهة مستخدم لائقة ، نجح هذا ، بالطبع ، وفقًا لنموذج الحدث. وصف OnClick في كائن الزر كل ما يفعله الزر ، عند OnChange عند الدخول إلى حقل نصي ، كل شيء تمامًا مثل البالغين. ولكن في الآخرة - للأسف ، لم يكن هناك شيء بعد.
لا شيء مما نعرفه الآن ، أعني. MVC ، على سبيل المثال - تعتبر دلفي أنها تتكون من V واحد ، ثم بقي كل شيء تحت رحمة المطور. مباشرة من OnClick لسحب طلب إلى قاعدة البيانات؟ نعم من فضلك. في OnChange ، افتح ملفًا وحاول الكتابة إليه ، وإذا لم يتحول الملف الموجود إلى تعطل بهدوء مع شيء مثل انتهاك الوصول إلى الذاكرة - في كل خطوة (ومع ذلك ، لا علاقة له بدلفي كنظام أساسي).
ويجب أن أقول أنه لسنوات عديدة كان سعيدًا تمامًا للجميع ، وما زال البعض سعداء به. تظهر فوائد مكتبة رفيعة وجميلة لمكونات واجهة المستخدم على الفور ، ولا تظهر فوائد أي وحدات تحكم ونماذج في السنة الأولى من التطوير ، ولا في أول مائة كيلو بايت من رموز المصدر.
وحتى إذا أصبحت - من السهل نسيانها ، فهناك فخ ذهني هنا ، مثل تلك الأوهام البصرية والصوتية التي تتم مناقشتها بشراسة على الإنترنت. لذا دعني أحاول رمي جسر صغير من دلفي إلى فهم حديث لواجهة المستخدم ويمكننا معرفة ما يحدث.
لذا ، فإن الفكرة الرئيسية: نحن نفصل العرض التقديمي عن البيانات ، والقطعة بشكل منفصل ، وكل العمل مع المعلومات الواردة فيه منفصل. كيف منفصلة؟ لنفترض أن الزر لا يزال يحتوي على نقش وأحيانًا رمز. يمكن للمستخدم نفسه دفع هذا النقش إلى حقل النص ، وأحيانًا يحتوي حقل النص على نقش آخر يشرح للمستخدم ما يقوده بالضبط. قاعدة عامة: تعمل الأداة على عرض المنطق (SIC!) على الأقل ، والذي يجب أن يكون موجودًا فيه يجب أن يرتبط فقط بالشاشة ولا شيء آخر. لنفترض ، إذا كان الزر غير جاهز للتمدد مع الكتابة عليه - يجب إما اقتصاص النقش بطريقة أو بأخرى (على سبيل المثال ، إظهار القطع الناقص والنسخة الكاملة في تلميح الأدوات) ، أو إعطاء خطأ عند محاولة تعيين القيمة أكثر مما يناسبها (على الرغم من أن هذا الفكرة هي هكذا ، على الأرجح أن مثل هذا الخطأ سيظهر بالفعل أثناء تنفيذ البرنامج ، في أكثر الأوقات غير المناسبة).
يمكن لحقل إدخال النص أن يمحو ترجمات النقل من النص إذا كان سطرًا واحدًا ، ولكن ليس من الضروري أن تطلب ، على سبيل المثال ، إدخال أرقام فيه فقط - هذه ليست وظيفته. تمامًا كما هو الحال في معالج النقر فوق الزر ، ليست هناك حاجة إلى عمليات تحقق ، ولا توجد إعادة رسم للمكالمات ، يجب أن يقوم معالج الزر بسحب الرمز الخارجي ، وهو المسؤول بالفعل عن منطق واجهة المستخدم والتطبيق بالكامل.
وإذا كنت تعيش في عالم نفاث جديد جميل ، وتطل على كل هذه الضجة من حدث OOP ، فإن المبدأ يبقى كما هو: الضغط على زر يغير حالته عن طريق إضافة الإجراء المقابل ، ثم بعض التعليمات البرمجية ، لا المرتبطة بعناصر واجهة المستخدم ، انظر إلى هذا الإجراء ، واستخلص الاستنتاجات المناسبة ، وقم بتغيير الحالة بحيث يكون هناك شيء لعرضه على واجهة المستخدم مرة أخرى.
أي أنه بغض النظر عن البيئة والنظام الأساسي والنموذج ، فإن العناصر المرئية نفسها تحمل الحد الأدنى من الوظائف وعدم وجود منطق في حد ذاتها. إنهم يتلقون المعلومات في الشكل الأكثر عمومية ، لذلك إذا كان لديك TextBox ، فهو أيضًا إدخال ، وهو أيضًا حقل لإدخال النص ، ويأخذ سلسلة ويعطي سلسلة. ومهمة تحويل خط إلى رقم أو اسم شخص أو شيء أكثر دهاء لم تعد للأداة.
حسنًا ، يقوم المتحكم أو مقدم العرض بمعالجة النتيجة وإنتاج النتيجة. اتصل به كما اعتدت عليه ، لا تقم بإدخال أي عناصر بصرية إليه.
ما هو الربح؟ أنا أسرد بالترتيب من الأكثر وضوحًا إلى الأكثر ، في رأيي ، الأساسي.
أولا ، إعادة الاستخدام. يمكن قضاء الكثير من الوقت في فهم أن حقل إدخال عنوان بريدي ، وإدخال لقب ، وإدخال مبلغ ، هو في الواقع نفس الحقل. عنصر واجهة مستخدم واحد ، مع نفس مجموعة الميزات التي تأتي لسحب حدث إدخال نص أو تحديث حالة. وقد يختلف فقط منطق العمل مع النص الموجود بداخله. مثال على "كيف لا" من الحياة: قم بإنشاء حقل لإدخال مبلغ من المال (حتى منزلين عشريين) ، ثم العبث لفترة طويلة ، وإعادة ذلك بحيث يمكنك في بعض الأحيان إدخال كمية في نفس الحقل (حتى 4 منازل عشرية) . كسر في العملية جميع الأماكن التي تم إدخال المبلغ في التطبيق ، وإصلاحها بشكل طارئ في منتصف الليل. هذا على الرغم من حقيقة أنه ، وفقًا لمنطق عملهم ، كان لديهم اختلافات في المكان العشري الثالث. يمكنك كتابة قصائد عن كيفية تحول حقول إدخال عناوين البريد الإلكتروني إلى حقول لإدخال العناوين الجغرافية باستخدام الميراث وكلمات الله.
ثانياً: القابلية للاختبار. يمكنك أيضًا اختبار واجهة المستخدم. تقريبا أي واجهة مستخدم. ولكنها ستكون باهظة الثمن ، من حيث الوقت والموارد التي تنفق على تطوير الاختبارات ، وعلى تشغيل الاختبارات ، ومن غير المحتمل إطلاقها في كل عملية إعادة بناء ، ولكن عندما تتعطل الاختبارات عند الإصدار ، ستكون هذه قوة قاهرة. لكن مكونات واجهة المستخدم هي الأكثر خطورة من حيث الأعطال ، فهي تنكسر ، كقاعدة ، في معظم الأحيان ، الأكثر وضوحًا ، والأكثر إيلامًا. لكن الشفرة ، التي تمزقها من الأدوات المصغرة نفسها ، مغطاة حقًا من خلال اختبارات الوحدة. واختبارات الوحدة أرخص بكثير - من السهل الكتابة ، ويمكنك تشغيلها حرفيا بعد أي تغييرات ، وتأكد دائمًا من عدم حدوث أي شيء.
وثالثًا ، الأهم برأيي. من الصعب للغاية رسم قطعة من واجهة المستخدم مع المنطق كقطعة واحدة للتغلب على الكسل والتفكير بشكل أعمق في كيفية عملها. لوضع سيناريوهات باستثناء إيجابية بشكل مثالي ، عندما أدخل المستخدم بالضبط ما كان متوقعًا منه ، فعل بالضبط ما هو مطلوب ، وتلقى بالضبط ما يريد. هذا المبرمج المقدس نفسه "كل شيء يناسبني".
إن فصل الجزء المرئي والجزء المنطقي يجعلك تفكر ، أولاً ، في كيفية عمل الجزء المرئي: ما يدخل إليه ، وما يخرج منه ، وما يحدث إذا لم ينجح شيء لم يكن متوقعًا أن يدخل أو يخرج. ويجبرك كتابة المنطق بشكل منفصل عن عنصر التحكم على كتابته في الحالات ، أي وفقًا للسيناريوهات المحتملة لاستخدام تطبيق معين في مكان معين ، بما في ذلك معالجة الأخطاء التي تنشأ هنا ، ومساعدة المستخدم في الصعوبات التي يواجهها هنا. حسنًا ، نعم ، ليس دائمًا ، أو بالأحرى ليس في كل شيء ، الحل بشكل عام أفضل من الحل المخصص لحالة معينة.
لتلخيص. يمكنك الكتابة في Delph ، أو تطبيق لنظام iOS ، تعذيب الويب طويل المعاناة لنوع ما من هناك 0 ، أو تثبيت بعض لعبة الميكروكونترولر في Python ، إذا تجاوزت التعليمات البرمجية الصيغة "قالب واحد ، استعلام واحد ، نتيجة واحدة" - سأخبرك أوصي بشدة بفصل الحاجيات بشكل حاسم عن أي منطق لعملهم ، ثم هناك فرصة أن يكون عدد الذباب أقل في شرحاتك. وعلى الرغم من عدم الوضوح التام المبدئي لمزايا هذا الحل ، فكلما زاد العمل معه ، ستظهر لك المزيد من هذه المزايا.