1. تنفيذ كائنات الأعمال. تعتبر الفئات التي تتضمن قواعد العمل أساس البرمجة الشيئية الحقيقية. في هذه المقالة، سنغطي جميع جوانب البرمجة ونطرح أسئلة حول بعض طرقنا المعتادة في كتابة برامج دلفي. المفهوم الأساسي وراء طرق التصميم هذه هو التغليف: تصميم مجموعة من الفئات ذات واجهات (طرق) محددة بوضوح ولها طرق للعمل على خصائصها. سيتم استخدام هذا المفهوم في جميع أنحاء البرنامج بأكمله وسيكون له تأثير قوي على كيفية حفظ البيانات وعرضها. أود أن أقدم للقراء مقالة فرانسيس جلاسبورو حول لغة C++، على الرغم من اختلاف اللغات، إلا أن مفاهيم التصميم الطبقي الممتازة مستقلة عن اللغة. معظم البرامج المكتوبة بلغة دلفي اليوم ليست موجهة للكائنات. لمجرد وجود نموذج كائن في اللغة واستخدام فئات أصلية أو جديدة، فهذا لا يعني أن البرنامج موجه للكائنات حقًا. تنتهي إعادة استخدام التعليمات البرمجية عندما يتم سحب عناصر تحكم الطرف الثالث إلى النوافذ، ولكن الترابط بين النوافذ والوحدات يتكاثر بسرعة. (!!!) إذا كنت ترغب في تغيير أساس البرنامج في المستقبل (مثل التبديل إلى قاعدة بيانات مختلفة أو الانتقال من هيكل من مستويين إلى هيكل من ثلاث طبقات) فسيكون ذلك معوقًا للغاية أو مكلفًا. إذا تمت كتابة البرنامج بطريقة موجهة للكائنات، فسيكون مناسبًا جدًا وليس مقيدًا. بالطبع كتابة مثل هذا البرنامج تتطلب تحسين المفاهيم، وهناك نقص في الإنتاجية في البداية معظم فرق التطوير غير راغبة في القيام بذلك أو التفكير فيه. آمل أن أوضح لك من خلال هذه المقالة كيفية كتابة برامج أفضل. والنتيجة هي نظام أكثر موثوقية، وسهل الصيانة، ومتسق في الأسلوب، ومرن، وقابل لإعادة الاستخدام، ويعمل بشكل أفضل من البرامج المكتوبة بالطرق التقليدية. خاصة بالنسبة للبرامج الكبيرة، فإن البرامج التي تكون شفرتها واضحة وموجهة نحو الكائنات ستتطلب موارد صيانة أقل من نفس البرنامج المكتوب بطريقة تقليدية. تأتي الموثوقية الأكبر للبرامج الموجهة للكائنات من حقيقة أن البيانات والعمليات مغلفة في فئات محددة جيدًا. يفرض المترجم الفئات والأساليب والخصائص الصحيحة في التعليمات البرمجية من خلال التحقق القوي من النوع، ويجب ألا يكون هناك أي احتمال لسوء فهم القصد من التعليمات البرمجية إذا أثر التغيير المستقبلي على البرنامج بأكمله. عندما يتم استخدام الفئات بشكل صحيح، تكون العلاقات بينها واضحة بذاتها، وتركز معظم التعليمات البرمجية حقًا على جوهر البرنامج، بدلاً من التفكير في تفاصيل مثل كيفية استمرار البيانات. ستؤدي البساطة والاتساق في جميع أنحاء الكود إلى تحسين قابلية صيانة البرنامج بشكل كبير. كما سنرى، الاستخدام المكثف للميراث الطبقي يزيد من الإنتاجية والموثوقية، ويعزز الاتساق. تنعكس هذه التناسقات في الكود الموضح، بما في ذلك سلوك الفئات، وكيفية تخزين البيانات، وكيفية تقديم واجهة المستخدم للبيانات. نظرًا لأن معظم الوظائف متوفرة في الفئات الأساسية، فيمكنك تغيير برنامجك بشكل أساسي عن طريق تغيير سلوكها بسرعة. (على سبيل المثال، تم تغيير واجهة تفاعل المستخدم من نموذج يعتمد على النافذة إلى نموذج يعتمد على HTML). يمكن تصميم هذه الفئات الأساسية لتكون مستقلة عن البرنامج، بحيث يحصل برنامج ثانٍ مماثل على الفور على زيادة في الإنتاجية. يمكن لمجموعة جيدة من الفئات الأساسية أن توفر تحسنًا كبيرًا يصل إلى 50% لبرنامج متواضع من حيث الوقت والتكلفة والموثوقية. أول شيء يجب التأكيد عليه هو أن التحول إلى التطوير الحقيقي الموجه للكائنات ليس أمرًا تافهًا. لأول مرة، يجب عليك التأكد من أن لديك مساعدة من ذوي الخبرة، أو أن البرنامج صغير ولا يوجد موعد نهائي للتسليم العاجل؛ تجدر الإشارة إلى أن الحل الموجه للكائنات (OO) لا يتمثل في تحديد الفئات التي يجب استخدامها وأي الفئات لا ينبغي استخدامها في البرنامج. إذا قامت إحدى الشركات بتطوير عناصر التحكم المرئية الخاصة بها، أو تستخدم عناصر تحكم مرئية تابعة لجهة خارجية، فإن الخطوة الأولى في تصميم أي برنامج موجه للكائنات هي التفكير في الفئات الضرورية. وهذه خطوة أساسية تمامًا، وتخضع للضمانات الفنية لمختلف التطورات الأخرى، نظرًا لأن تصحيح الأخطاء في المراحل المبكرة سيكون مكلفًا. عند تصميم فئاتنا، نسعى عمومًا لتحقيق اقتران منخفض وتماسك عالٍ - تكون الفئات مستقلة قدر الإمكان، ولكن يمكن دمجها بطريقة قوية. إحدى الطرق لتحقيق هذا الهدف هي تقسيم الفصول الدراسية إلى فئات مختلفة وفقًا للأدوار المختلفة التي يلعبونها في برامجهم. سيؤدي الاختيار الصحيح لهذه الأدوار إلى مجموعة متماسكة من الفئات. هناك مبدأ أساسي ثابت في تصميم دور الفئات: تقسيم مسؤوليات الفصل إلى العرض والتطبيق والتخزين المستمر للبيانات (عادة في قاعدة بيانات). على الرغم من أن هذا هو نفس تقسيم برامج قواعد البيانات ثلاثية المستويات، فمن المهم ملاحظة أن مفهوم التقسيم هذا يمكن تنفيذه في مجموعة متنوعة من البيئات: من البرامج ذات الشريحة الواحدة إلى البرامج الموزعة متعددة المستويات. مجموعة الفئات التي تشكل منطق التطبيق هي المسؤولة عن العمل الأكثر صعوبة، مثل الاستجابة لطلبات إجراءات المستخدم ومعالجة البيانات. تمثل بعض الفئات في هذه الطبقة كيانات من العالم الحقيقي ويتم تصميمها بواسطة النظام. غالبًا ما تسمى هذه الفئات "فئات الأعمال" أو "فئات مجال المشكلة". إنها تشكل جزءًا حيويًا من أي برنامج موجه للكائنات، ولأن الفئات الأخرى ستدعم هذه الفئات بطريقة ما، فإنها تصبح محط اهتمام جميع المطورين. يعد تحديد كائنات الأعمال الموجودة في برنامج معين بشكل عام مسألة خبرة وغريزة، على الرغم من وجود نظام كامل (أو فن؟) لهذه العملية. إن مزايا توجيه الكائن مقارنة بالتقنيات التقليدية مثل SSADM(1) موجودة طوال عملية التحليل والتصميم وصيانة الكيانات: يمكن تمثيل كل كائن عمل من خلال التحليل الموجه للكائنات (OOA)، والتصميم الموجه للكائنات (OOD)، والبرمجة الموجهة للكائنات (OOP). وسوف نستكشف بعض التقنيات لتحديد الأهداف التجارية المناسبة لاحقًا. أولا نفترض أن العمليات التالية قد اكتملت. إن التواصل بين الطبقات بين الطبقات المختلفة (العرض والتطبيق والمثابرة) محدد بوضوح ومترابط. تظهر العلاقة بين هذه الفئات في الشكل 1. توضح الأسهم الموجودة في الشكل أن الفئات الموجودة في نفس الطبقة يمكنها استدعاء الأساليب في فئة أخرى. توضح هذه الصورة أيضًا أن فئات طبقة العرض (واجهة المستخدم) يمكنها تشغيل طبقة التطبيق أو الفئات الأخرى في واجهة المستخدم. يمكن لطبقة التطبيق (كائنات الأعمال) تشغيل فئات طبقة التطبيق واستدعاء أساليب الثبات طبقة الثبات تستجيب فقط لطلب الطبقة. كائنات الأعمال لتوضيح كيفية تنفيذ كائنات الأعمال، سنرى بعد ذلك برنامجًا مبسطًا يتضمن كيانات المخزون والعملاء والطلب (توفر الشركة كمية معينة من البضائع، ويشتري العملاء هذه البضائع). حدد تحليلنا الأولي أن ثلاثة كائنات أعمال مطلوبة لتمثيل هذه الكيانات. سيكون هناك ثلاث فئات في برنامج دلفي لدينا: TStockItem، TCustomer وTorder. يتم عرض الواجهات العامة لهذه الفئات في القائمة 1. وتجدر الإشارة هنا إلى أن خصائص هذه الفئات يتم كشفها للخارج من خلال الخصائص (PRoperty): وهذا تصميم فئة بسيط ومفيد ويتحكم في الوصول الخارجي من خلال الخصائص. كما يجب أن تكون هذه الخصائص في المنطقة المنشورة للفئة (للأسباب التي سيتم ذكرها لاحقًا) ويتم تعيين القيم الافتراضية المناسبة لها. على الرغم من أن مؤهلات الخاصية هذه تُستخدم فقط عند تدفق الفئات، إلا أنها تعطي كل خاصية قيمة أولية مناسبة وتجعل الكود أكثر وصفًا ذاتيًا. إطار عمل من الدرجة الأولى في المراحل الأولى من تطوير البرنامج، قمنا بتحديد وتنفيذ ثلاثة عناصر عمل. تلعب هذه الأشياء الثلاثة دورًا مشتركًا: تمثيل كيانات العالم الحقيقي بطريقة ما. لذلك نريدهم أن يتمتعوا بخصائص مماثلة ومستويات مناسبة لكيانات العالم الحقيقي. سنعطي كل كائن فئة أساسية مشتركة تسمى TPDObject (كائن مجال المشكلة). بمرور الوقت، سنضيف أساليب وخصائص عامة إلى هذه الفئة، وسيستمر توسيع TPDObject. تجدر الإشارة إلى أن TPDObject لا ينبغي (أبدًا) أن يحتوي على أي عناصر مرتبطة بتطبيق معين. باعتبارها فئة مستقلة عن البرنامج، يتم وضعها في وحدة مستقلة وتشكل أساس الإطار: مجموعة من الفئات التي يمكن إعادة استخدامها في العديد من البرامج. في المستقبل، سيتم توسيع إطار عملنا بشكل كبير ليشكل فئات أساسية توفر وظائف مهمة مستقلة عن البرنامج ويمكن استخدامها بسرعة في أنظمة محددة. إن TStockItem وTCustomer وTorder هي كائنات مخصصة لأنظمة معينة من TPDObject. TMyAppPDObject عبارة عن فئة موروثة من TPDObject، على الرغم من أن جزء التنفيذ الخاص بها فارغ، إلا أنه يعد عرضًا جيدًا؛ تم إدراج الكود الأولي للإطار في القائمة. توفر فئة TPDObject أيضًا معرف سمة للقراءة فقط، ونوعه هو TobjectID. تمنح هذه السمة معرفًا لكل كائن: سنعتبر حالتين من نفس النوع والمعرف هما نفس الكائن. هنا يتم الإعلان عن المعرف عمدًا كنوع خاص به لتجنب تعيينه مباشرة إلى قيمة من نوع قياسي آخر. لم يتم اختيار نوع TobjectID على وجه التحديد: هنا اخترت عددًا صحيحًا، والذي قد يكون أيضًا فئة متخصصة في بعض الحالات. على الرغم من أن استخدام الفئات كمعرفات يبدو نهجًا أكثر نقاءً تجاه الكائنات، استنادًا إلى حقيقة أنه سيتم إنشاء الفئات في مجال مشكلتنا وإصدارها آلاف المرات أثناء تشغيل البرنامج، وذلك لتجنب الحمل الإضافي عند الإنشاء وإطلاق الكائنات، لم أفعل ذلك (باعتباري متشددًا، قمت بتضمين TobjectID في TPDObject ككائن مركب). يوجد في الكود زوج من الوظائف التي تحول السلاسل إلى أنواع تعريف الكائنات لدينا، وثابت يعمل كقيمة أولية عند عدم إجراء أي تعيين. هناك العديد من الفئات التي يتم فيها ذكر تعريف الكائن: يقول البعض أنه يجب منح كافة كائنات الأعمال تعريفًا (حتى GUID) لا يتكرر داخل البرنامج عند إنشائها. في الواقع، إن القدرة على التمييز بين الكائنات المختلفة في سياق معين هو ما يهم حقًا، والحفاظ على هذا الأمر البسيط سيكون له فوائد واضحة في الأداء ومساحة التخزين. أسئلة حول المواصفات: من أجل تعزيز بعض مفاهيم وممارسات التصميم عند تصميم أطر الفصل، سأطرح بعض الأسئلة وأطلب من القراء التفكير في المبادئ الأساسية التي تقف وراءها. لقد ذكرت أن التصميم الحقيقي الموجه للكائنات لا يمنع استخدام فئات محددة، ولكن هناك استثناء واحد مهم. ما هو هذا الاستثناء (الإجابة في الشكل 1) ((( القائمة 1 - وحدة مجال المشكلة الخاصة بالتطبيق (مختصرة))))unitProblemDomain;interfaceuses Framework;type TMyAppPDObject = class (TPDObject) end; TMyAppPDObject ) اسم الخاصية المنشورة: الخاصية stringInStock: الخاصية الافتراضية TradePrice: العملة؛ TCustomer = class (TMyAppPDObject) … ; TOrder = class (TMyAppPDObject) … ;implementationend.((( قائمة النهاية 1 )))((( القائمة 2 - وحدة إطارية مستقلة عن التطبيق )))unit Framework;interfaceconst NotAssigned = 0; اكتب TObjectID = نوع TPDObject = فئة FID الخاصة: TObjectID معرف الملكية العامة: TObjectID قراءة FID الافتراضي NotAssigned؛ end;function StrToID (القيمة: String): TObjectID;الوظيفة IDToStr (القيمة: TObjectID): String;implementation...end.((( قائمة النهاية 2 )))(1) تم إنشاء SSADM (تحليل النظم الهيكلية وتصميم الأنظمة) في 1981 موقع الوكالة المركزية للكمبيوتر والاتصالات (CCTA) التابعة للحكومة البريطانية: http://www.ccta.gov.uk ) تطوير تحليل البرمجيات وأساليب التصميم القياسية. فيليب براون هو مستشار تصميم الأنظمة ومطور ومقدم ومدرب نشط، وسيعمل على الترويج لفوائد تقنيات OO القوية لتقديم تطبيقات أفضل في أي فرصة.