//من <دليل مطور دلفي 5>
1.2 ما هي دلفي؟
كثيرًا ما نطرح أسئلة مثل: "ما الذي يجعل دلفي جيدة جدًا؟" و"لماذا أفضّل دلفي على أدوات البرمجة الأخرى؟" وما إلى ذلك. على مر السنين، توصلنا إلى إجابتين، واحدة طويلة والأخرى قصيرة، لأسئلة مثل هذه. الجواب القصير هو: الكفاءة. لإنشاء تطبيقات Windows، يعد استخدام دلفي أسهل طريقة يمكننا العثور عليها. بالطبع بعض الأشخاص (الرؤساء والعملاء المستقبليين) غير راضين عن هذه الإجابة. لذلك، يجب أن نقدم إجابتنا التفصيلية، التي توضح مجموعة العوامل التي تجعل دلفي فعالة للغاية. نلخص العوامل التي تحدد كفاءة أداة تطوير البرمجيات في النقاط الخمس التالية:
• أداء بيئة التطوير البصري.
• سرعة المترجم وكفاءة الكود المترجم.
• إمكانيات لغات البرمجة وتعقيدها.
• المرونة وقابلية التوسع في بنية قاعدة البيانات.
• ملحقات الإطار لأنماط التصميم والاستخدام.
على الرغم من أن هناك العديد من العوامل الأخرى التي يجب تضمينها، مثل التكوين، والوثائق، ودعم الطرف الثالث، وما إلى ذلك، فقد وجدنا أن هذه هي الطريقة الأكثر دقة وأبسط لشرح للناس سبب اختيارنا لدلفي. بالطبع، النقاط الخمس المذكورة أعلاه قد تتضمن أيضًا بعض العوامل الذاتية، ولكن المفتاح هو: ما مدى كفاءتك عند استخدام أداة معينة للتطوير؟ كما هو موضح في الشكل 1-1، يتم تقييم جميع جوانب أداء الأداة وتحديد كميتها (بين 1 و5) ووضع علامة عليها على كل محور من محاور الشكل 1-1، وفي النهاية، يمكن الحصول على شكل خماسي. كلما كانت مساحة البنتاغون أكبر، زادت كفاءة هذه الأداة.
لا حاجة لإخبارك بالإجابات التي حصلنا عليها باستخدام هذه الطريقة - ستكتشف ذلك بنفسك بمجرد تجربتها! دعونا نلقي نظرة فاحصة على أداء دلفي في هذه المجالات ونقارنها بأدوات تطوير Windows الأخرى.
1.2.1 بيئة التطوير البصري
تنقسم بيئة التطوير المرئية عادة إلى ثلاثة مكونات: المحرر، ومصحح الأخطاء، ومصمم النماذج. مثل معظم أدوات RAD (التطوير السريع للتطبيقات) الحديثة، تعمل هذه الأجزاء الثلاثة معًا. أثناء عملك في مصمم النماذج، تقوم دلفي تلقائيًا بإنشاء تعليمات برمجية خلف الكواليس لعناصر التحكم التي تقوم بمعالجتها في النموذج. يمكنك أيضًا إضافة التعليمات البرمجية بنفسك في المحرر لتحديد سلوك التطبيق، ويمكنك أيضًا تصحيح أخطاء البرنامج عن طريق تعيين نقاط التوقف ونقاط المراقبة في نفس المحرر.
بشكل عام، محرر دلفي يشبه محرري الأدوات الأخرى، لكن تقنية Code Insight الخاصة به توفر الكثير من أعمال الإدخال. تعتمد هذه التقنية على معلومات المترجم، وليس على مكتبات الأنواع مثل Visual Basic، لذا فهي تحتوي على نطاق أوسع من التطبيقات. على الرغم من أن محرر دلفي لديه أيضًا العديد من خيارات التكوين الجيدة، أعتقد أن محرر Visual Studio لديه مساحة أكبر للتكوين. في الإصدار 5، تمكنت وظيفة مصحح أخطاء دلفي أخيرًا من اللحاق بمصحح أخطاء Visual Studio، مع العديد من الميزات المتقدمة، مثل تصحيح الأخطاء عن بعد، واقتران العمليات، وتصحيح أخطاء DLL والحزمة، والمراقبة المحلية التلقائية، ونوافذ وحدة المعالجة المركزية. تدعم دلفي أيضًا وضع النوافذ وإرسائها بشكل عشوائي أثناء تصحيح الأخطاء وحفظ هذه الحالة كإعداد لسطح المكتب للأمر. ونتيجة لذلك، حقق IDE الخاص بـ Delphi دعمًا جيدًا لوظائف تصحيح الأخطاء.
كما هو الحال غالبًا في بعض البيئات المتكاملة (مثل VB وبعض أدوات Java)، فإن ميزة مصحح الأخطاء الكامل للغاية هي أنه عندما يتم تصحيح أخطاء التطبيق، يمكنه تعديل التعليمات البرمجية الخاصة به، وبالتالي تغيير سلوكه. لسوء الحظ، هذه الوظيفة غير مدعومة من قبل دلفي لأنها معقدة للغاية بحيث لا يمكن تنفيذها عند تجميعها في التعليمات البرمجية الأصلية.
بالنسبة لأدوات RAD (مثل Delphi وVisual Basic وC++Builder وPowerBilder وما إلى ذلك)، يعد مصمم النموذج ميزة فريدة. توفر بعض بيئات التطوير الأكثر كلاسيكية، مثل VC++ وBC++، محررين للمحادثة، ولكنها لا تدمج مصمم النموذج في عملية التطوير. كما يتبين من مخطط الكفاءة في الشكل 1-1، فإن غياب مصمم النماذج سوف يقلل من الكفاءة الإجمالية لأداة التطوير. على مدى السنوات القليلة الماضية، كانت دلفي وفيجوال بيسك تتنافسان بشدة لتحسين وظائف مصمم النماذج. يحتوي كل إصدار جديد على ميزات أفضل من الإصدار السابق. ما يجعل مصمم النماذج في دلفي فريدًا هو أن دلفي مبنية على إطار حقيقي موجه للكائنات. بهذه الطريقة، سيتم نشر التغييرات التي تجريها على الفئة الأساسية إلى جميع الفئات المشتقة. إحدى التقنيات الرئيسية المستخدمة هنا هي VFI (وراثة النموذج المرئي)، وهو وراثة النموذج المرئي. تمكنك تقنية VFI من الوراثة ديناميكيًا من أي نموذج آخر في المشروع الحالي أو مكتبة الكائنات. كلما تغير النموذج الأساسي، يتم تحديث النموذج المشتق على الفور. تم شرح هذه الميزة المهمة بالتفصيل في الفصل الرابع، "إطار عمل التطبيق وتصميمه".
1.2.2 سرعة المترجم وكفاءة التعليمات البرمجية المترجمة
يتيح لك المترجم السريع تطوير البرامج خطوة بخطوة، وتعديل كود المصدر بشكل متكرر، وإعادة الترجمة، والاختبار، والتعديل مرة أخرى، والتجميع مرة أخرى، والاختبار مرة أخرى... مما يشكل دورة تطوير جيدة. إذا كانت سرعة التجميع بطيئة جدًا، فسيتعين على المطورين تعديل التعليمات البرمجية على دفعات، وإجراء تغييرات متعددة قبل كل تجميع للتكيف مع عملية حلقة غير فعالة. إنه يحسن كفاءة التشغيل، ويوفر وقت التشغيل، ويولد رموز ثنائية أقصر.
ولعل الميزة الأكثر شهرة لمترجم باسكال هي سرعته، وقد بنيت دلفي على هذا المترجم. في الواقع، قد يكون أسرع مترجم تعليمات برمجية أصلي للغة عالية المستوى لنظام التشغيل Windows. حققت مترجمات C++ التي كانت بطيئة في السابق تقدمًا كبيرًا في السنوات الأخيرة، حيث أضافت الروابط وإستراتيجيات التخزين المؤقت المتنوعة، خاصة في Visual C++ وC++Builder. ولكن على الرغم من ذلك، فإن مترجم C++ لا يزال أبطأ عدة مرات من مترجم دلفي.
هل سرعة الترجمة تتناسب بالضرورة مع كفاءة التشغيل؟ بالطبع لا. تشترك دلفي وC++Builder في نفس الواجهة الخلفية للمترجم، لذا فإن الكود الذي تم إنشاؤه يعادل ذلك الذي ينتجه مترجم C++ جيد. وفقًا لأحدث معايير التقييم الموثوقة، يعتبر Visual C++ في العديد من المناسبات هو الأكثر كفاءة من حيث سرعة الترجمة وطول التعليمات البرمجية التي تم إنشاؤها، وذلك بفضل بعض إجراءات التحسين القوية للغاية. على الرغم من صعوبة ملاحظة هذه المزايا الصغيرة في تطوير التطبيقات النموذجية، إلا أنها يمكن أن تدخل حيز التنفيذ إذا كنت تكتب تعليمات برمجية حسابية معقدة.
تعتبر تقنية التجميع الخاصة بـ Visual Basic مميزة بعض الشيء. أثناء التطوير، يعمل VB بطريقة متكاملة ويستجيب تمامًا. هذا المترجم أبطأ والتعليمات البرمجية القابلة للتنفيذ التي تم إنشاؤها أقل كفاءة بكثير من أدوات دلفي وC++.
جافا هي لغة أخرى مثيرة للاهتمام. تدعي أحدث لغات الأدوات المستندة إلى Java JB uilder وVisual J ++ أن سرعة الترجمة الخاصة بها يمكن أن تتطابق
إنها قابلة للمقارنة مع دلفي، لكن كفاءة تنفيذ التعليمات البرمجية التي تم إنشاؤها ليست مرضية لأن Java هي لغة متكاملة. على الرغم من أن Jave يحرز تقدمًا ثابتًا، إلا أن سرعة تشغيله لا تزال بعيدة عن دلفي وC++ في معظم المواقف.
1.2.3 وظائف لغات البرمجة وتعقيدها
إن وظيفة اللغة وتعقيدها تقع في عين الناظر وهي موضوع الكثير من النقاش. فما هو بسيط بالنسبة لشخص ما قد يكون صعبًا بالنسبة لذلك الشخص؛ وما قد يكون ذا وظيفة محدودة بالنسبة لشخص ما قد يكون مثاليًا بالنسبة لشخص آخر. ولذلك، فإن النقاط التالية تعتمد فقط على تجربة المؤلف الشخصية وفهمه.
التجميع هو في الأساس أقوى لغة. يمكنك أن تفعل أي شيء تقريبا معها. ومع ذلك، فإن تطوير أبسط التطبيقات في التجميع أمر صعب للغاية وقد لا يؤدي إلى أي شيء. ليس هذا فحسب، بل إن الاحتفاظ بجزء من كود التجميع في بيئة تطوير جماعية لأي فترة زمنية يكون أمرًا مستحيلًا في بعض الأحيان. عندما يتم تمرير الكود من شخص إلى آخر، ومن الشخص التالي، تصبح أفكار التصميم والنوايا غير واضحة بشكل متزايد، حتى يبدو الكود ككتاب من السماء. ونتيجة لذلك، فإننا نصنف التجميع على أنه منخفض جدًا، لأنه قوي ولكنه معقد للغاية بالنسبة لجميع المطورين تقريبًا.
C++ هي لغة أخرى قوية للغاية. بمساعدة ميزاتها المحتملة (مثل وحدات ماكرو المعالج الأولي، والقوالب، وتحميل المشغل، وما إلى ذلك)، يمكنك تقريبًا تصميم لغتك الخاصة باستخدام C++. وطالما أنك تستخدم خياراته الوظيفية الغنية بشكل صحيح، يمكنك تطوير تعليمات برمجية موجزة وبديهية وسهلة الصيانة. ومع ذلك، تكمن المشكلة في أن العديد من المطورين يسيئون استخدام هذه الميزات، مما قد يؤدي بسهولة إلى حدوث أخطاء كبيرة. في الواقع، من الأسهل كتابة تعليمات برمجية سيئة لـ C++ بدلاً من كتابة تعليمات برمجية جيدة لـ C++. لأن اللغة نفسها لن تتحرك في اتجاه التصميم الجيد - فالأمر متروك للمطورين.
يبدو أن Object Pascal وJava متشابهان جدًا معنا لأنهما يفهمان التوازن بين التعقيد والوظيفة بشكل جيد للغاية. إنهم جميعًا يتبعون أسلوب الحد من وظائفهم المتاحة لتعزيز التصميم المنطقي للمطور. على سبيل المثال، يتجنب كلاهما المفهوم الموجه بالكامل للكائنات ولكن من السهل إساءة استخدامه والمتمثل في الوراثة المتعددة، وبدلاً من ذلك يقومان بتنفيذ فئة واحدة تؤدي وظائف واجهات متعددة. لا يدعم أي منهما تحميل المشغل الجميل ولكنه خطير. يتمتع كلاهما ببعض الميزات القوية، مثل معالجة الاستثناءات ومعلومات نوع وقت التشغيل (RT TI) وذاكرة عمر السلسلة المُدارة ذاتيًا. وفي الوقت نفسه، لا تتم كتابة أي من اللغتين بواسطة هيئة تحرير مخصصة، ولكنها تأتي من أفراد أو مجموعات داخل منظمة واحدة يتشاركون في فهم مشترك للغة.
تم تصميم Visual Basic في الأصل لتسهيل البدء والتقدم بشكل أسرع للمبتدئين (ومن هنا جاء الاسم). ولكن كلغة، يجب على لغة VB أن تتعلم باستمرار من نقاط قوتها وتعوض نقاط ضعفها، مما يجعلها تصبح أكثر تعقيدًا في السنوات الأخيرة. من أجل إخفاء هذه التفاصيل عن المطورين، لا يزال VB يحتفظ ببعض المعالجات لإنشاء مشاريع معقدة.
1.2.4 المرونة وقابلية التوسع في بنية قاعدة البيانات
نظرًا لأن بورلاند يفتقر إلى مخطط قاعدة البيانات، فإن دلفي تحتفظ بما نعتبره بنية قاعدة البيانات الأكثر مرونة بين جميع الأدوات. يعد BDE قويًا جدًا لمعظم التطبيقات المستندة إلى منصات قواعد بيانات العميل/الخادم وODBC المحلية. إذا لم تكن راضيًا عن هذا، فيمكنك تجنب استخدام BDE لصالح مكونات ADO الأصلية الجديدة. إذا لم يكن ADO مثبتًا لديك، فيمكنك إنشاء فئات الوصول إلى البيانات الخاصة بك أو شراء حل الوصول إلى البيانات من جهة خارجية. بالإضافة إلى ذلك، يسهل MIDAS الوصول متعدد المستويات إلى مصادر البيانات. تميل أدوات Microsoft (ODBC أو OLE DB أو غيرها) منطقيًا إلى دعم قاعدة البيانات الخاصة بشركة Microsoft وحلول الوصول إلى البيانات.
1.2.5 امتدادات الإطار لأنماط التصميم والاستخدام
هذه ميزة مهمة غالبًا ما يتم تجاهلها بواسطة أدوات تصميم البرامج الأخرى. VCL هو العنصر الأكثر أهمية في دلفي. القدرة على التعامل مع المكونات في وقت التصميم، وإنشاء المكونات، واستخدام تقنية OO (الموجهة للكائنات) لوراثة سلوك المكونات الأخرى هي العوامل الرئيسية التي تحدد كفاءة دلفي. في كثير من الحالات، تتم كتابة مكونات VCL باستخدام أسلوب تصميم OO ثابت. وبالمقارنة، فإن الأطر الأخرى القائمة على المكونات غالبا ما تكون جامدة أو معقدة للغاية. على سبيل المثال، تتمتع عناصر تحكم Active X بنفس إمكانات وقت التصميم مثل عناصر تحكم VCL، ولكن لا يمكن توريثها لإنشاء فئة جديدة بسلوكيات مختلفة. تتطلب أطر عمل الفئات التقليدية، مثل OWL وMFC، أن يكون لديك الكثير من المعرفة بالبنية الداخلية، وبدون دعم وقت التصميم من أدوات RAD، سيتم إعاقة وظائفها. إحدى الأدوات التي يمكنها منافسة وظيفة VCL في المستقبل هي Visual J++'s WFC (فئات Windows Foundation)، وهي فئة Windows Foundation. ولكن مع استمرار النظر في الدعوى القضائية التي رفعتها شركة Sun Microsystems بشأن مشكلات Java، فإن مستقبل Visual J++ غير واضح.