عادةً ما نكتب الكثير من التعليمات البرمجية للشركة أو لأنفسنا أو للأصدقاء. في بعض الأحيان، من أجل التحقق من فكرة خاصة بي، أو من أجل التعلم
بالنسبة لتقنية معينة، سيتم كتابة بعض التعليمات البرمجية التجريبية. دورة حياة هذا الكود قصيرة جدًا ولا تحتاج إلى صيانة بشكل أساسي، يمكنك فقط كتابتها كما تريد.
بواسطة. ومع ذلك، عندما تريد بالفعل إكمال مشروع PProject، فإن تصميم التعليمات البرمجية مهم جدًا. لأن مثل هذا الكود يتطلب فترة طويلة
الصيانة أو التعديل المستمر أو التحسين. تصميم الكود الفوضوي يجعل الصيانة صعبة للغاية أو مستحيلة. تعديل مثل هذه التعليمات البرمجية
سيؤدي هذا إلى المزيد من الأخطاء أو الكوارث.
وبما أن تصميم الكود مهم جدًا، فلا يمكننا تجاهله. إذًا، كيف تصمم الكود الخاص بك؟ تقنيات البرمجة الموجهة للكائنات يمكن أن تساعد
ساعدونا. هنا، لإجراء بعض الاستطرادات، يخلط العديد من المبرمجين بين تكنولوجيا البرمجة الشيئية (OOP) والتكنولوجيا الموجهة للكائنات (OO). مرة واحدة
من وجهة نظري، فإن التكنولوجيا الموجهة للكائنات هي معرفة واسعة وعميقة، وهي منهجية أو رؤية للعالم، في حين أن التكنولوجيا الموجهة للكائنات هي نوع من المنهجية أو رؤية للعالم.
توفر تقنيات البرمجة الشيئية ببساطة طريقة لاستخدام البرمجة الشيئية عند البرمجة.
وفيما يلي تجربة المؤلف بعد قراءة بعض الكتب ذات الصلة والممارسات اليومية، ويأمل أن يشاركها معكم.
أولاً، افصل رمز الواجهة عن رمز الوظيفة. أحد المبادئ التي يجب مراعاتها هو عدم كتابة منطق وظيفي معقد في كود الواجهة.
الكود في. يتم استخدام ملف التنفيذ الخاص بنموذج الواجهة فقط لتخزين رمز الواجهة وفصل الكود الوظيفي المعقد. ولإعطاء مثال بسيط،
لنفترض أنك تريد الحصول على قائمة من السلاسل من مكان ما ثم عرضها في TListBox، هذا الرمز محترم:
ObjectXXX := TObjectXXX.Create;
ListBox1.Items := ObjectXXX.GetStringList;
ObjectXXX.Free;
بهذه الطريقة، يتم تغليف المنطق المعقد للحصول على قائمة السلاسل في كود التنفيذ لفئة TObjectXXX، ويمكن تعريف هذه الفئة
ويتم وضع التنفيذ في ملف .pas بشكل مستقل لسهولة الصيانة. إن فصل رمز الواجهة والكود الوظيفي له فائدة أخرى،
قد يتم استدعاء رمز تنفيذ الوظيفة بواسطة وحدات واجهة متعددة إذا قمت بنسخ رمز تنفيذ الوظيفة عند الحاجة
سيكون لديك العديد من الوحدات المتطابقة التي يجب صيانتها، إذا كنت بحاجة إلى تعديلها، فمن المستحيل تقريبًا ضمان عدم ارتكاب الأخطاء.
ثانيًا، اجعل منطق كل وحدة بسيطًا قدر الإمكان. تخبرنا التجربة أن المنطق المفرط في التعقيد سيسبب صعوبات في فهم الناس.
كارثة. لذلك، اجعل رمز كل وحدة بسيطًا قدر الإمكان، بشكل عام لا يزيد عن 25 سطرًا من التعليمات البرمجية. عندما تجد أن المنطق الذي تكتبه يميل إليه
معقد، فهذا هو الوقت المناسب لك للبحث عن الأشياء ومعرفة ما إذا كان بإمكانك عزل بعض المنطق.
وأخيرا، انتبه إلى تسمية المتغيرات. تحقق من كود مصدر VCL كثيرًا وستجد أن متغيرات الأعضاء الخاصة في فئة VCL جميعها تبدأ بالحرف "F"
بدءًا من ذلك، تبدأ جميع أسماء الفئات بالحرف "T" وهكذا. ما هي فوائد هذا؟ عندما ينظر الآخرون إلى الكود بهذه الطريقة، بمجرد رؤيتهم للحرف "F"
في البداية، يمكنك أن تعرف على الفور أنه عضو خاص في الفصل، مما يسهل صيانة الكود.