سؤال

ينص المبدأ المفتوح/المغلق على أن الكيانات البرمجية (الفئات والوحدات النمطية وما إلى ذلك) يجب أن تكون مفتوحة للتوسيع، ولكنها مغلقة للتعديل.ماذا يعني هذا، ولماذا يعتبر مبدأً مهمًا للتصميم الجيد الموجه للكائنات؟

هل كانت مفيدة؟

المحلول

على وجه التحديد، يتعلق الأمر بـ "الكأس المقدسة" للتصميم في OOP المتمثل في جعل الكيان قابلاً للتوسيع بدرجة كافية (من خلال تصميمه الفردي أو من خلال مشاركته في البنية) لدعم التغييرات المستقبلية غير المتوقعة دون إعادة كتابة الكود الخاص به (وأحيانًا حتى بدون إعادة التجميع). **).

تتضمن بعض الطرق للقيام بذلك تعدد الأشكال/الوراثة، والتركيب، وانعكاس التحكم (المعروف أيضًا باسم.DIP)، والبرمجة الموجهة نحو الجوانب، وأنماط مثل الإستراتيجية، والزائر، وطريقة القالب، والعديد من المبادئ والأنماط والتقنيات الأخرى لـ OOAD.

** راجع "مبادئ الحزمة" الستة، REP، CCP، CRP، ADP، SDP، SAP

نصائح أخرى

هذا يعني أنه يجب عليك وضع كود جديد في فئات/وحدات جديدة.يجب تعديل التعليمات البرمجية الموجودة فقط لإصلاح الأخطاء.يمكن للفئات الجديدة إعادة استخدام التعليمات البرمجية الموجودة عبر الميراث.

يهدف مبدأ الفتح/المغلق إلى تخفيف المخاطر عند تقديم وظائف جديدة.وبما أنك لا تقوم بتعديل الكود الموجود، يمكنك التأكد من أنه لن يتم كسره.إنه يقلل من تكلفة الصيانة ويزيد من استقرار المنتج.

إنها الإجابة على مشكلة الطبقة الأساسية الهشة، والتي تقول إن التعديلات التي تبدو بريئة على الفئات الأساسية قد يكون لها عواقب غير مقصودة على الورثة الذين اعتمدوا على السلوك السابق.لذلك عليك أن تكون حريصًا على تغليف ما لا تريد الاعتماد عليه حتى تلتزم الفئات المشتقة بالعقود التي تحددها الفئة الأساسية.وبمجرد وجود الورثة، يجب أن تكون كذلك حقًا كن حذرًا فيما تقوم بتغييره في الفئة الأساسية.

وبشكل أكثر تحديدًا من DaveK، فهذا يعني عادةً أنه إذا كنت تريد إضافة وظائف إضافية، أو تغيير وظيفة فئة ما، فقم بإنشاء فئة فرعية بدلاً من تغيير الفئة الأصلية.بهذه الطريقة، لن يضطر أي شخص يستخدم الفصل الأصلي إلى القلق بشأن تغييره لاحقًا.في الأساس، الأمر كله يتعلق بالتوافق مع الإصدارات السابقة.

هناك مبدأ آخر مهم حقًا في التصميم الموجه للكائنات وهو الاقتران غير المحكم من خلال واجهة الطريقة.إذا كان التغيير الذي تريد إجراؤه لا يؤثر على الواجهة الحالية، فمن الآمن جدًا تغييره.على سبيل المثال، لجعل الخوارزمية أكثر كفاءة.تحتاج المبادئ الموجهة للكائنات إلى التخفيف من الحس السليم أيضًا :)

يجب أن تكون الكيانات البرمجية مفتوحة للتوسيع ولكنها مغلقة للتعديل

وهذا يعني أنه يجب كتابة أي فصل أو وحدة بطريقة يمكن استخدامها كما هي، ويمكن توسيعها، ولكن لا يتم تعديلها

مثال سيء في جافا سكريبت

var juiceTypes = ['Mango','Apple','Lemon'];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}

exports.makeJuice = juiceMaker;

الآن، إذا كنت تريد إضافة نوع عصير آخر، فيجب عليك تعديل الوحدة نفسها، وبهذه الطريقة، فإننا نكسر OCP .

مثال جيد في جافا سكريبت

var juiceTypes = [];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}
function addType(typeName){
    if(juiceTypes.indexOf(typeName)==-1)
        juiceTypes.push(typeName);
}
function removeType(typeName){
  let index = juiceTypes.indexOf(typeName)
    if(index!==-1)
        juiceTypes.splice(index,1);
}

exports.makeJuice = juiceMaker;
exports.addType = addType;
exports.removeType = removeType;

الآن، يمكنك إضافة أنواع عصير جديدة من خارج الوحدة دون تحرير نفس الوحدة.

ويعني هذا المبدأ أنه من السهل إضافة وظائف جديدة دون الحاجة إلى تغيير الوظائف الحالية والمستقرة والمختبرة، مما يوفر الوقت والمال.

في كثير من الأحيان، يعد تعدد الأشكال، على سبيل المثال استخدام الواجهات، أداة جيدة لتحقيق ذلك.

هناك قاعدة إضافية للتوافق مع OCP وهي جعل الفئات الأساسية مجردة فيما يتعلق بالوظائف التي توفرها الفئات المشتقة.أو كما يقول سكوت مايرز "اجعل الفصول غير الورقية مجردة".

وهذا يعني وجود أساليب غير منفذة في الفئة الأساسية وتنفيذ هذه الأساليب فقط في الفئات التي لا تحتوي في حد ذاتها على فئات فرعية.ثم لا يمكن لعميل الفئة الأساسية الاعتماد على تطبيق معين في الفئة الأساسية لأنه لا يوجد أي تطبيق.

أريد فقط التأكيد على أن "مفتوح/مغلق"، على الرغم من كونه مفيدًا بشكل واضح في برمجة OO، إلا أنه طريقة صحية يمكن استخدامها في جميع جوانب التطوير.على سبيل المثال، في تجربتي الخاصة، يعد استخدام "مفتوح/مغلق" قدر الإمكان عند العمل مع C العادي مسكنًا رائعًا للألم.

/ روبرت

وهذا يعني أنه يجب البناء على برنامج OO، ولكن لا يتم تغييره بشكل جوهري.يعد هذا أمرًا جيدًا لأنه يضمن أداءً موثوقًا ويمكن التنبؤ به من الفئات الأساسية.

لقد حصلت مؤخرًا على فكرة إضافية عما يستلزمه هذا المبدأ:أن المبدأ المفتوح والمغلق يصف في آن واحد طريقة لكتابة التعليمات البرمجية، بالإضافة إلى النتيجة النهائية لكتابة التعليمات البرمجية بطريقة مرنة.

أحب أن أفكر في تقسيم مفتوح/مغلق إلى جزأين مرتبطين ارتباطًا وثيقًا:

  • الرمز الذي هو يفتح للتغيير، يمكن إما تغيير سلوكه للتعامل مع مدخلاته بشكل صحيح، أو يتطلب الحد الأدنى من التعديل لتوفير سيناريوهات الاستخدام الجديدة.
  • الرمز الذي هو مغلق للتعديل لا يتطلب الكثير من التدخل البشري، إن وجد، للتعامل مع سيناريوهات الاستخدام الجديدة.الحاجة ببساطة غير موجودة.

وبالتالي، فإن التعليمات البرمجية التي تظهر سلوكًا مفتوحًا/مغلقًا (أو، إذا كنت تفضل، تفي بمبدأ الفتح/المغلق) تتطلب الحد الأدنى من التعديل أو لا تتطلب أي تعديل استجابةً لسيناريوهات الاستخدام بما يتجاوز ما تم إنشاؤه في الأصل من أجله.

وفيما يتعلق بالتنفيذ؟أجد أن التفسير الشائع ، "مفتوح/مغلق يشير إلى الكود يجري متعدد الأشكال!" ليكون في أفضل الأحوال بيان غير مكتمل.يعد تعدد الأشكال في الكود إحدى الأدوات لتحقيق هذا النوع من السلوك؛الوراثة، التنفيذ... في الواقع، كل مبدأ تصميم موجه للكائنات ضروري لكتابة تعليمات برمجية مرنة بالطريقة التي يتضمنها هذا المبدأ.

في مبدأ التصميم، SOLID - يشير الحرف "O" في "SOLID" إلى المبدأ المفتوح/المغلق.

المبدأ المفتوح المغلق هو مبدأ تصميم ينص على أن الفصل والوحدات والوظائف يجب أن تكون مفتوحة للتوسيع ولكنها مغلقة للتعديل.

ينص هذا المبدأ على أن تصميم وكتابة الكود يجب أن يتم بطريقة يمكن من خلالها إضافة وظائف جديدة مع الحد الأدنى من التغييرات في الكود الموجود (الكود الذي تم اختباره).يجب أن يتم التصميم بطريقة تسمح بإضافة وظائف جديدة كفئات جديدة، مع الحفاظ على أكبر قدر ممكن من التعليمات البرمجية الموجودة دون تغيير.

الاستفادة من مبدأ التصميم المفتوح المغلق:

  1. سيكون التطبيق أكثر قوة لأننا لا نغير الفصل الذي تم اختباره بالفعل.
  2. مرنة لأنه يمكننا بسهولة استيعاب المتطلبات الجديدة.
  3. سهل الاختبار وأقل عرضة للأخطاء.

تدوينة مدونتي حول هذا:

http://javaexplorer03.blogspot.in/2016/12/open- Closed-design-principle.html

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top