1. حديث الرجل العجوز
يعد Delphi VS VC موضوعًا قديمًا جدًا، ولكني ما زلت أرغب في التحدث عنه هنا، فهذا رأيي بالكامل. إذا كنت لا توافق على ذلك، يرجى الضحك.
من السهل رؤية فوائد RAD فيما يتعلق بتصميم الواجهة، فدلفي في الواقع أفضل من VC. أريد أن أكتب زرًا شفافًا غير تقليدي في دلفي، كل ما أحتاجه هو العثور على عنصر تحكم، والنقر بالماوس، وتعديل التسمية التوضيحية. ماذا عن VC؟ يستغرق الأمر ما لا يقل عن 10 أسطر من التعليمات البرمجية لإنجازها. بالطبع، أسلوب MFC يجعل الناس يفهمون المبادئ الأساسية لنظام التشغيل Windows، ولكن تغليف OOP لا ينعكس جيدًا على المطورين فهم جميع المبادئ الأساسية قبل أن يتمكنوا من كتابة التعليمات البرمجية بالنسبة لي وللأكثر فإن كونك مبتدئًا هو بمثابة تعذيب لأنه لا داعي لذلك نعم، المواعيد النهائية للتطوير ضيقة دائمًا والوقت لا يكفي أبدًا. لا يمكننا أن نتوقع أن يعرف المبرمجون جميع جوانب برمجة Windows. يعرف بعض الأشخاص الكثير عن مقاطع الفيديو والبعض الآخر جيد في التواصل، ولكن لا يوجد أحد متعدد المهارات وجيد في كل شيء غير واقعي، لذلك التغليف مهم جدا. إذا كان علي أن أقضي 30% أو أكثر من وقتي على زر شفاف أو واجهة جميلة في كل مرة أقوم فيها بتطوير منتج جديد، فسوف أقفز إلى النهر :) دلفي أفضل بالفعل من MFC من حيث الواجهة! بالطبع، هذا لا يعني أن MFC لا يمكنه تصميم واجهات جميلة، لكن الأمر يستغرق وقتًا طويلاً ولا يستحق ذلك.
هل RAD حقًا يدور حول الفوائد؟ لا. على الأقل ليس للمبتدئين، لأنه يجعل الناس يسيئون فهم أن البرمجة هي مجرد تحريك الماوس وسحب الإطار، والنتيجة النهائية هي أن الناس يعتقدون أن دلفي تستخدم فقط لكتابة الواجهات، والطبقة السفلية لا تستطيع فعل أي شيء. يبدو أن مبرمجي MFC يتحدثون جميعًا عن مبرمجي دلفي: "بالإضافة إلى واجهة جميلة، ما الذي يمكن أن يفعله برنامجك أيضًا؟" في الواقع، باستثناء DDK، ما الذي لا يمكن تطويره في دلفي؟ ما هو ملف رأس API الذي لا يحتوي عليه دلفي؟ لم يقم Borland بالتحويل، لكن JEDI قام بتحويله. حتى لو لم يتم تحويل JEDI، فسيكون الأمر نفسه إذا قمت بذلك بنفسك، طالما أعطيتني ملف رأس C، يمكنني تحويله يجب أن يكون ذلك أمرًا ضروريًا لكل الوثائق المطلوبة لمبرمج دلفي. بمجرد تحويل ملفات الرأس، كل ما تبقى هو البدء في الكتابة. ما يمكن أن يفعله MFC، يمكن أن تفعله دلفي أيضًا! فيديو؟ شبكة؟ دايركتكس؟ صوتي؟ ما الذي لا تستطيع دلفي فعله؟
2. العملية الفرعية
عند كتابة حدث ما، يبدأ العديد من الأشخاص في كتابته، بغض النظر عن طول الكود أو عدد الأشياء التي تم إنجازها، وطالما تم ذلك في حدث ما، فإنهم يكتبونه في رؤوسهم ليس لديهم طريقة للبدء عندما يقومون بمراجعته بعد بضعة أشهر، لأن مقتطف الشفرة طويل جدًا. فلماذا لا نقوم بفصل مقتطفات التعليمات البرمجية عن بعضها البعض؟ الاهتمام البشري محدود، وستشعر بالدوار إذا قرأت أكثر من 100 سطر من التعليمات البرمجية دفعة واحدة. أخبرني كبار السن في دلفي بشيء واحد: جميع العمليات (تتضمن العملية هنا الإجراء والوظيفة) يجب ألا تتجاوز 25 سطرًا! نظرًا لأن هذا الطول من التعليمات البرمجية لن يجعل رأسك يدور، فسوف تفهم بسهولة ما تفعله العملية.
إذًا كيف يمكنك تفكيك الأشياء التي تم القيام بها في الأصل في حدث ما؟ هناك العديد من الطرق، تجربتي معيارية. على سبيل المثال، إذا كان هناك العديد من الأشياء المختلفة التي يجب القيام بها في حدث ما، فسيتم تحويل الأشياء المختلفة إلى عمليات فرعية مختلفة، ثم يتم استدعاؤها في العملية الرئيسية. معظم العمليات الرئيسية عبارة عن بعض الأحكام والحلقات، وسيكون هناك لا توجد عملية تنفيذ محددة، سيؤدي هذا إلى إنشاء الكثير من مقتطفات التعليمات البرمجية، لكنه سيحافظ على تركيزك.
المبدأ: العملية تفعل شيئًا واحدًا فقط، وتفعله بشكل جيد.
المرجع: كود مصدر VCL. بالنظر إلى كود مصدر VCL، نادرًا ما يكون هناك أكثر من 25 سطرًا من التعليمات البرمجية!
3. اسم المعلمة
أتذكر عندما تعلمت SDK لأول مرة، شعرت بالدوار عندما رأيت التدوين المجري، كان كثيرًا! لا أستطيع أن أتذكر ذلك! لذلك أنا أكره ذلك المخترع :) وأخيرًا ظهرت دلفي وانتهت أيام الرقص بالأغلال! في دلفي، تعريف سلسلة بإسم متغير مثل strDoSometing أمر مثير للسخرية وغير ضروري. طالما أن الإجراء الخاص بك قصير ولم تظهر أي متغيرات عامة، فلن تحتاج إلى مثل هذه البادئة. على سبيل المثال:
الإجراء SubPro؛
فار
أنا: بايت؛
العرض، الارتفاع: عدد صحيح؛
يبدأ
العرض := GetWidth;
الارتفاع := GetHeight;
لأني: = 0 إلى 9 افعل
يبدأ
DrawThread := TDrawThread.Create;
DrawThread.Width := Width;
DrawThread.Height := الارتفاع؛
DrawThread.Start;
نهاية؛
نهاية؛
أعتقد أنه على الرغم من عدم وجود تعليقات على هذا الجزء من الكود، فمن السهل معرفة ما سيفعله. لذا، يرجى إزالة جميع البادئات والشرطات السفلية، فبرامج دلفي لا تحتاج إليها! تحتاج أسماء المعلمات لدينا فقط إلى فعل + اسم، ونحتاج فقط إلى شرح وظيفة هذه المعلمة، ولا نريد أشياء زائدة عن الحاجة. إن ميزة Pascal هي أن الكود يبدو وكأنه يتحدث، بدلاً من القراءة من السماء في رأسك، ما تعتقده هو ما يبدو عليه الكود. أنيقة وبسيطة، هذه هي فوائد باسكال، يرجى الالتزام بها!
المبدأ: البساطة جميلة!
4. النافذة الفرعية
يقوم العديد من الأشخاص بتشغيل عناصر التحكم في النافذة الفرعية مباشرةً عند الاتصال بنافذة فرعية، مثل:
إذا SetAlarmParamDlg.ShowModal = MrOK إذن
يبدأ
AlarmTimes := StrToInt(SetAlarmParamDlg.Edit1.Text);
AlarmArea := SetAlarmParamDlg.SpinEdit1.Value;
نهاية؛
يا إلهي، إذا اعتقد المستخدمون غدًا أن Edit أو SpinEdit الذي تستخدمه يبدو قبيحًا واستبدلوه بعنصر تحكم جميل، فماذا ستفعل؟ لا تحتاج فقط إلى تعديل رمز النافذة الفرعية، ولكنك تحتاج أيضًا إلى تعديل رمز النموذج الرئيسي. بالطبع برنامج به نافذة فرعية واحدة أو اثنتين لن يسبب لك الألم. ماذا لو كان برنامجا به أكثر من عشرين نافذة فرعية؟ استغرق الأمر يومًا، لكن السبب كان مجرد تغيير عنصر التحكم! لماذا لا تجرب طريقة أخرى؟ إذا كنت تستخدم السمات لتمثيل المعلمات التي تريد استخدامها، فسوف تقوم بحفظ عدد لا يحصى من الرموز.
// النموذج الرئيسي
إذا SetAlarmParamDlg.ShowModal = MrOK إذن
يبدأ
AlarmTimes := SetAlarmParamDlg.AlarmTimes;
AlarmArea := SetAlarmParamDlg.AlarmArea;
نهاية؛
// نموذج فرعي
واجهة
خاص
FAlarmTimes: عدد صحيح؛
FAlarmArea: عدد صحيح؛
نشرت
الخاصية AlarmTimes: قراءة عدد صحيح FAlarmTimes كتابة FAlarmTimes؛
خاصية AlarmArea: قراءة عدد صحيح FAlarmArea إرسال FAlarmArea؛
تطبيق
...
FAlarmTimes := StrToInt(Edit1.Text);
FAlarmArea := SpinEdit1.Value;
ModalResult := MrOK;
...
طالما واصلت هذه الطريقة، ستجد فوائد عظيمة. النافذة الفرعية تقوم بعملها الخاص فقط، ويتم التفاعل بين النافذة الرئيسية من خلال السمات لن تؤثر النافذة الفرعية على النافذة الرئيسية بغض النظر عن كيفية تغير مظهر النافذة الفرعية، أو كيفية استبدال عناصر التحكم، أو كيفية تعديل الكود، يظل البرنامج بأكمله كما هو، فقط الواجهة هي التي تغيرت.
المبدأ: قم بتقسيم النوافذ الفرعية الخاصة بك إلى فئات أيضًا.