التصميم الجيد للكلاس قبل أن نبدأ في تعلم الميزات المتقدمة الجديدة لـ ++C نحن بحاجة للحديث عن بعض المبادئ من فئة جيدة التصميم لماذا التصميم الجيد مهم؟ هذا لأنه بدون تصميم عالي الجودة القدرة على توسيع وظائف البرنامج أو إضافة ميزات جديدة إليه، تتضائل بشدة لذلك دعنا نتحدث عن بعض المبادئ الأكثر فائدة ودعنا نبدأ مع مبدأ يسمى DRY هو اختصار يشير إلى لا تكرر نفسك DRY don't repeat yourself مما يعني أنه يجب عليك كتابة التعليمات البرمجية للقيام بشيء ما أو لوصف شيئًا ما مرة واحدة فقط اذا ماذا يعني ذلك بالضبط؟ دعنا نلقي نظرة على مثال لديك فئة تسمى DoNotRepeat الذي تم تظليلها وهذه الفئة بها بعض المتغيرات بعض متغيرات الأعضاء تسمى Integer_var double_var و string_var كما أن لديها دوال لتعيين تلك المتغيرات وكذلك استرداد قيمهم الآن دعونا ننظر في كلاس آخر يسمى هذا الكلاس مكرر repeated ألق نظرة عليه، أنه يحتوي على تصميم مشابه جدًا له متغيرات عضو مماثلة تسمى Integer_var double_var و string_var ولها دوال واجهة مماثلة لتعيين تلك المتغيرات واسترداد بعض قيمها ولكن أيضًا لحساب قيمة أخرى على أساس تلك القيم لذلك إذا نظرت إلى هاتين الفئتين وسوف تفهم أنه إذا كنت بحاجة إلى تغيير ميزة الذي هو نفسه بينهما ربما تحتاج إلى إجراء تغييرات مرتين سوف تحتاج إلى تغيير DoNotRepeat وستحتاج بعد ذلك أيضًا إلى التغيير المتكرر repeated وهو بالطبع ممكن عمليا لكنها فكرة سيئة للغاية بسبب تغييرات في الكود التي يجب أن تتكرر 2، 3، 4 مرات هي طريقة جيدة جدًا لإدخال الأخطاء في برنامجك لذلك يوفر لك ++C آلية ستسمح لك ذلك بكتابة الكود أو التعليمة البرمجية الذي يكون شائعا بين الفئتين مرة واحدة ومرة واحدة فقط وهو ما يسمى الوراثة Inheritance وسوف نتحدث عن ذلك في بعض الأقسام القادمة مبدأ آخر نحتاج للحديث عنه هو التغليف encapsulation وهذا المبدأ مهم للغاية في الواقع التغليف هو مبدأ يتم بموجبه حماية خصائص الكائن من الوصول المباشر إليها من خلال دوال أو فئات خارجية ليس هذا هو الشيء الوحيد الذي يتطلبه التغليف الكائنات المغلفة بشكل صحيح لها واجهة ضيقة جدًا مما يعني أن المستخدم الخارجي يمكنه فقط القيام بأشياء قليلة مع الكائنات لكن عدد المكونات والدوال الداخلية داخل الكائن يمكن أن تكون كبيرة ويمكنهم القيام ببعض الأشياء بمفردهم لكن لا يمكنك أداء تلك الدوال دون الوصول إلى واجهة الكائن المغلف في هذا المثال دعنا نلقي نظرة على فئة كائن تسمى Mixer الذي يصف خلاط مطبخ قائم في المثال هنا أنا أصف خلاط Kitchen Aid وكما ترون له واجهة بسيطة للغاية يمكنك أن تقوم بتشغيله، إيقافه، يمكنك الخلط يمكنك إزالة الكوب، يمكنك تثبيت الكوب يمكنك فتح الخلاط، قفل الخلاط ويمكنك أيضًا رفع الخلاط هذه هي الدوال الوحيدة التي يمكنك القيام بها على الكائن المغلف بشكل صحيح أنت تعلم أيضًا أن الخلاط يحتوي على تروس المحرك، وجهاز التحكم، وعدد قليل من المكونات الأخرى لكن لا يمكنك الوصول إليهم كمستخدم عادي للكائن أنت تعلم أن هذه موجودة بشكل فردي لا تهمك كثيرًا ولا داعي للسيطرة عليهم أو لديك وظيفة السيطرة عليها إلا من خلال الكائن المبدأ التالي الذي سنلقي نظرة عليه يسمى مبدأ المهمة الواحدة single responsiblity principle هذه طريقة رائعة للقول أنه يجب أن يكون هذا الصنف أو الكلاس مسؤولاً عن شيء واحد وشيء واحد فقط إذا كان الكلاس، على سبيل المثال مسؤول عن وصف أمر المبيعات لا ينبغي أن يكون مسؤولا عن حفظ معلومات أمر المبيعات هذا إلى قاعدة البيانات ولا ينبغي أن يكون مسؤولا عن تحويل نفسه إلى تنسيق آخر مثل XML لماذا هذه ليست فكرة جيدة؟ حسنًا، إنه في الواقع بسيط للغاية نفسها قاعدة البيانات، على سبيل المثال الكائن يحتاج إلى معلومات قاعدة البيانات لذلك إذا كان لديك العديد من أوامر المبيعات يحتاج كل كائن إلى نسخة من معلومات قاعدة البيانات وهو عرضة للأخطاء ويجعل قراءة الكود أو الشفرة محيرة حقًا ويصعب الحفاظ عليها لذلك ما لم يكن ذلك ضروريًا للغاية يجب تجنب مثل هذه التبعيات المبدأ الأخير الذي سنتحدث عنه في هذا القسم يسمى مبدأ المفتوح المغلق open-closed principle ينص المبدأ على أن الكلاس يجب أن يكون مفتوحًا للتمديد أو التوسع أو النمو، ولكن مغلق للتعديل اذا ماذا يعني ذلك بالضبط؟ دعنا نلقي نظرة على شيء ما للتحقق من صحة القاعدة rule validation لديك فئة تسمى RuleValidation الذي يحتوي على طريقة واجهة تسمى قاعدة التحقق من الصحة validate rule التي تضع عليها كائن قاعدة rule التي يمكنك وصفها بنفسك وبعد ذلك يكون لديك منطق التحقق في الطريقة وهذا يعني أنه في كل مرة تضيف فيها قاعدة جديدة أو نوع جديد من التحقق سيكون عليك تغيير فئة RuleValidation لاستيعاب الوظائف الجديدة أفضل طريقة للقيام بذلك هي أن يكون لديك فئة تسمى ValidateRule والتي سيكون لها دالة عامة public تسمى التحقق من الصحة validate لذلك بالنسبة لكل نوع من أنواع التحقق الذي تريده سوف تقوم بإنشاء كائن من هذه الفئة ويمكنك تمديد أو توسيع هذا مرة أخرى باستخدام الوراثة يمكنك تمديده لتوفر أنواعًا محددة من التحقق validate وبعد ذلك يمكنك بالفعل التحقق من صحة القاعدة لديك مجموعة من كائنات قواعد التحقق من الصحة validate rule objects والتي سيستدعيها validate بالفعل على التوالي حتى يحصل على أن القاعدة صحيحة أو سيحصل على الفشل كل منهم بهذه الطريقة، كائن التحقق من صحة القاعدة لا يجب أن يتغير كثيرًا لاستيعاب قواعد التحقق الجديدة الشيء الوحيد الذي سوف تحتاج لإضافته هو دالة تسمى addRuleValidator والتي ستأخذ كائن قاعدة التحقق من الصحة validate rule object وستضيفهم لمجموعة التحقق من الصحة validation إضافة validaterule وبعد ذلك يمكنك ببساطة إضافة العديد من عمليات التحقق من الصحة validations العديد من عمليات التحقق كما تريد وهو بالضبط كيف تم وصفه في مبدأ المفتوح المغلق
