المحتوى:
- أنماط التصميم الإبداعية “Creational patterns”
- ما هو نمط التصميم الإبداعي”Abstract pattern”
- مشكلة يمكن حلها باستخدام نمط التصميم”Abstract pattern”
- حل المشكلة باستخدام نمط التصميم”Abstract pattern”
- بناء نمط التصميم الإبداعي”Abstract pattern”
- تمثيل نمط التصميم “Abstract pattern” بشكل كود
- قابلية نمط التصميم “Abstract pattern” للتطبيق
- كيفية تنفيذ نمط التصميم “Abstract pattern”
- إيجابيات وسلبيات نمط التصميم “Abstract pattern”
- علاقات نمط التصميم “Abstract pattern” مع الأنماط الأخرى
- الخاتمة
- المراجع 1.أنماط التصميم الإبداعية “Creational patterns“:
تحدثنا في المقالة السابقة عن أنماط التصميم الإبداعي التي كانت تلخص عملية إنشاء مثيل (instantiation process). وكيف أنها تساعد في جعل النظام مستقلاً عن كيفية إنشاء كائناته وتكوينها وتمثيلها. يستخدم نمط إنشاء الفئة الوراثة لتغيير الفئة التي تم إنشاء مثيل لها، في حين أن نمط إنشاء الكائن سوف يقوم بتفويض إنشاء مثيل إلى كائن آخر.
تصبح الأنماط الإبداعية مهمة مع تطور الأنظمة لتعتمد بشكل أكبر على تكوين الكائن بدلاً من وراثة الفئة. وعندما يحدث ذلك، يتحول التركيز بعيدًا عن الترميز الثابت لمجموعة ثابتة من السلوكيات نحو تحديد مجموعة أصغر من السلوكيات الأساسية التي يمكن تجميعها في أي عدد من السلوكيات الأكثر تعقيدًا. وبالتالي فإن إنشاء كائنات ذات سلوكيات معينة يتطلب أكثر من مجرد إنشاء مثيل لها.
توفر أنماط التصميم الإبداعي آليات مختلفة لإنشاء الكائنات، مما يزيد من المرونة وإعادة استخدام التعليمات البرمجية الموجودة.
وقد تحدثنا في المقالة السابقة عن أول نمط تصميم إبداعي وهو “Factory pattern”وهو نمط المصنع، نمط تصميم إبداعي يوفر واجهة لإنشاء كائنات في فئة فائقة، ولكنه يسمح للفئات الفرعية بتغيير نوع الكائنات التي سيتم إنشاؤها. وسنكمل بالتحدث عن تتمة أنواع التصميم الإبداعي وسنبدأ بال “Abstract pattern”
نتخيل أننا تقوم بإنشاء جهاز محاكاة لمتجر الأثاث. يتكون الكود الخاص بنا من فئات تمثل: عائلة من المنتجات ذات الصلة، على سبيل المثال: كرسي أريكة طاولة قهوةوعدة أنواع من هذه العائلة. على سبيل المثال تتوفر منتجات الكرسي الأريكة طاولة القهوة في هذه المتغيرات: Modern، Victorian، Art Deco.
- ما هو نمط التصميم الإبداعي”Abstract pattern”
هو نمط تصميم إبداعي يتيح لنا إنتاج عائلات من الكائنات”objects” ذات الصلة دون تحديد فئاتها المحددة.
ويستخدم في تطوير البرمجيات لتوفير واجهة لإنشاء عائلات من الكائنات المرتبطة أو التابعة دون تحديد فئاتها المحددة. إنه يندرج ضمن أنماط تصميم Gang of Four (GoF) وهو مفيد بشكل خاص عندما يحتاج النظام إلى أن يكون مستقلاً عن كيفية إنشاء كائناته وتكوينها وتمثيلها.
بعبارات أبسط، يتيح لنا نمط Abstract Factory إنشاء عائلات من الكائنات المرتبطة أو التابعة دون تحديد فئاتها المحددة مباشرة في التعليمات البرمجية الخاصة بنا. بدلاً من ذلك، يمكننا العمل باستخدام واجهات أو فئات مجردة، ويتم تفويض تفاصيل التنفيذ الفعلية إلى المصانع الخرسانية التي تقوم بتنفيذ تلك الواجهات.
3.مشكلة يمكن حلها باستخدام نمط التصميم”Abstract pattern”
نحن بحاجة إلى طريقة لإنشاء كائنات أثاث فردية بحيث تتطابق مع كائنات أخرى من نفس العائلة.
يشعر العملاء بالغضب الشديد عندما يحصلون على أثاث غير مطابق. كما أننا لا نرغب في تغيير التعليمات البرمجية الموجودة عند إضافة منتجات جديدة أو عائلات من المنتجات إلى البرنامج. يقوم بائعو الأثاث بتحديث كتالوجاتهم كثيرًا، ولن نرغب في تغيير الكود الأساسي في كل مرة يحدث ذلك.
- حل المشكلة باستخدام نمط التصميم”Abstract pattern”
أول ما يقترحه نمط Abstract pattern هو الإعلان بوضوح عن واجهات لكل منتج مميز من عائلة المنتج على سبيل المثال، كرسي، أريكة أو طاولة القهوة. وبعد ذلك يمكننا جعل جميع أنواع المنتجات تتبع تلك الواجهات. على سبيل المثال، يمكن لجميع أنواع الكراسي تنفيذ واجهة الكرسي؛ يمكن لجميع أنواع طاولات القهوة تنفيذ واجهة Coffee Table، وما إلى ذلك.
الخطوة التالية هي الإعلان عن واجهة تحتوي على قائمة طرق الإنشاء لجميع المنتجات التي تشكل جزءًا من عائلة المنتج (على سبيل المثال، create Chair، و create Sofa، و createCoffeeTable). يجب أن تقوم هذه الطرق بإرجاع أنواع المنتجات المجردة التي تمثلها الواجهات التي استخرجناها سابقًا: الكرسي والأريكة وطاولة القهوة وما إلى ذلك.
الآن، ماذا عن متغيرات المنتج؟ لكل متغير من عائلة المنتجات، نقوم بإنشاء فئة مصنع منفصلة بناءً على واجهة Abstract Factory. المصنع هو فئة تقوم بإرجاع منتجات من نوع معين. على سبيل المثال، يمكن لـ ModernFurnitureFactory إنشاء كائنات ModernChair وModernSofa وModernCoffeeTable فقط. ويجب أن يعمل رمز العميل مع كل من المصانع والمنتجات عبر واجهات مجردة خاصة بكل منها. يتيح لنا ذلك تغيير نوع المصنع الذي نقوم بتمريره إلى رمز العميل، بالإضافة إلى متغير المنتج الذي يتلقاه رمز العميل، دون كسر رمز العميل الفعلي.
لنفترض أن العميل يريد مصنعًا لإنتاج كرسي. ليس من الضروري أن يكون العميل على علم بفئة المصنع، ولا يهم نوع الكرسي الذي سيحصل عليه. سواء كان كرسيًا من الطراز الحديث أو كرسيًا على الطراز الفيكتوري، يجب على العميل التعامل مع جميع الكراسي بنفس الطريقة، وذلك باستخدام واجهة الكرسي المجردة. مع هذا النهج، الشيء الوحيد الذي يعرفه العميل عن الكرسي هو أنه يطبق طريقة sitOn بطريقة ما. أيضًا، أيًا كان شكل الكرسي الذي يتم إرجاعه، فسوف يتطابق دائمًا مع نوع الأريكة أو طاولة القهوة التي يتم إنتاجها بواسطة نفس كائن المصنع.
هناك أمر آخر يجب توضيحه: إذا كان العميل معرضًا فقط للواجهات المجردة، فما الذي يُنشئ كائنات المصنع الفعلية؟ عادةً ما يقوم التطبيق بإنشاء كائن مصنع خرساني في مرحلة التهيئة. قبل ذلك مباشرة، يجب أن يحدد التطبيق نوع المصنع اعتمادًا على التكوين أو إعدادات البيئة.
- بناء نمط التصميم الإبداعي”Abstract pattern”
- تعلن المنتجات المجردة Abstract Products عن واجهات لمجموعة من المنتجات المتميزة ولكن ذات الصلة والتي تشكل عائلة المنتج.
- المنتجات الملموسة Concrete products هي تطبيقات مختلفة للمنتجات المجردة، مجمعة حسب المتغيرات. يجب تنفيذ كل منتج مجرد (كرسي/أريكة) بجميع المتغيرات المحددة (الفيكتوري/الحديث).
- تعلن واجهة Abstract Factory عن مجموعة من الأساليب لإنشاء كل منتج من المنتجات المجردة.
- تطبق مصانع الخرسانة Concrete Factories أساليب إنشاء المصنع المجرد. يتوافق كل مصنع خرسانة مع متغير معين من المنتجات ويقوم بإنشاء متغيرات المنتج هذه فقط.
- على الرغم من أن مصانع الخرسانة تقوم بمحاكاة المنتجات الخرسانية، إلا أن التوقيعات الخاصة بطرق الإنشاء الخاصة بها يجب أن تعيد المنتجات المجردة المقابلة. بهذه الطريقة، لا يقترن رمز العميل الذي يستخدم المصنع بالمتغير المحدد للمنتج الذي يحصل عليه من المصنع. يمكن للعميل العمل مع أي متغير مصنع/منتج ملموس، طالما أنه يتواصل مع كائناته عبر واجهات مجردة.
- تمثيل نمط التصميم “Abstract pattern” بشكل كود
يوضح هذا المثال كيف يمكن استخدام نمط Abstract Factory لإنشاء عناصر واجهة مستخدم عبر الأنظمة الأساسية دون اقتران رمز العميل بفئات واجهة مستخدم محددة، مع الحفاظ على جميع العناصر التي تم إنشاؤها متسقة مع نظام التشغيل المحدد.
من المتوقع أن تتصرف نفس عناصر واجهة المستخدم في التطبيق عبر الأنظمة الأساسية بشكل مشابه، ولكنها تبدو مختلفة قليلاً في ظل أنظمة تشغيل مختلفة. علاوة على ذلك، فإن مهمتنا هي التأكد من أن عناصر واجهة المستخدم تتوافق مع نمط نظام التشغيل الحالي. لن نرغب في أن يعرض برنامجنا عناصر تحكم macOS عند تنفيذه في Windows.
تعلن واجهة Abstract Factory عن مجموعة من طرق الإنشاء التي يمكن أن يستخدمها كود العميل لإنتاج أنواع مختلفة من عناصر واجهة المستخدم. تتوافق مصانع الخرسانة مع أنظمة تشغيل محددة وتقوم بإنشاء عناصر واجهة المستخدم التي تتوافق مع نظام التشغيل المحدد.
وهو يعمل على النحو التالي: عند تشغيل التطبيق، فإنه يتحقق من نوع نظام التشغيل الحالي. يستخدم التطبيق هذه المعلومات لإنشاء كائن مصنع من فئة تتوافق مع نظام التشغيل. يستخدم باقي الكود هذا المصنع لإنشاء عناصر واجهة المستخدم. وهذا يمنع إنشاء العناصر الخاطئة.
مع هذا النهج، لا يعتمد كود العميل على فئات محددة من المصانع وعناصر واجهة المستخدم طالما أنه يعمل مع هذه الكائنات عبر واجهاتها المجردة. يتيح هذا أيضًا لرمز العميل دعم المصانع الأخرى أو عناصر واجهة المستخدم التي قد تضيفها في المستقبل.
ونتيجة لذلك، لا تحتاج إلى تعديل رمز العميل في كل مرة تقوم فيها بإضافة شكل جديد من عناصر وجهة المستخدم إلى تطبيقنا. فكل ما علينا فعله هو إنشاء فئة مصنع جديدة تنتج هذه العناصروتعديل رمز تهيئة التطبيق قليلاً حتى يختار تلك الفئة عندما يكون ذلك مناسبًا.
- قابلية نمط التصميم “Abstract pattern” للتطبيق
- استخدم Abstract Factory عندما تحتاج التعليمات البرمجية الخاصة بك إلى العمل مع عائلات مختلفة من المنتجات ذات الصلة، ولكنك لا تريد أن تعتمد على الفئات المحددة لتلك المنتجات – فقد تكون غير معروفة مسبقًا أو تريد ببساطة السماح بقابلية التوسعة في المستقبل. حيث يوفر لك Abstract Factory واجهة لإنشاء كائنات من كل فئة من عائلة المنتج. طالما أن التعليمات البرمجية الخاصة بك تنشئ كائنات عبر هذه الواجهة، فلا داعي للقلق بشأن إنشاء متغير خاطئ لمنتج لا يتطابق مع المنتجات التي أنشأها تطبيقك بالفعل.
- فكر في تنفيذ Abstract pattern عندما يكون لدينا فصل دراسي يحتوي على مجموعة من أساليب المصنع التي تطمس مسؤوليته الأساسية. وفي البرنامج المصمم جيدًا، يكون كل فصل مسؤولاً عن شيء واحد فقط. عندما نتعامل فئة ما مع أنواع منتجات متعددة، فقد يكون من المفيد استخراج أساليب المصنع الخاصة بها إلى فئة مصنع قائمة بذاتها أو تنفيذ مصنع مجردة كامل.
- كيفية تنفيذ نمط التصميم “Abstract pattern“
- قم بتخطيط مصفوفة لأنواع المنتجات المميزة مقابل متغيرات هذه المنتجات.
- الإعلان عن واجهات المنتج المجردة لجميع أنواع المنتجات. ثم اجعل جميع فئات المنتجات الملموسة تنفذ هذه الواجهات.
- قم بتعريف واجهة المصنع المجردة مع مجموعة من طرق الإنشاء لجميع المنتجات المجردة.
- تنفيذ مجموعة من فئات المصانع الخرسانية، واحدة لكل نوع منتج.
- قم بإنشاء رمز تهيئة المصنع في مكان ما في التطبيق. يجب أن يقوم بإنشاء مثيل لإحدى فئات مصنع الخرسانة، اعتمادًا على تكوين التطبيق أو البيئة الحالية. قم بتمرير كائن المصنع هذا إلى كافة الفئات التي تقوم بإنشاء المنتجات.
- امسح الرمز ضوئيًا واعثر على جميع المكالمات المباشرة لمنشئي المنتج. استبدلها باستدعاءات طريقة الإنشاء المناسبة على كائن المصنع.
- إيجابيات وسلبيات نمط التصميم “Abstract pattern“
الإيجابيات:
يمكنك التأكد من أن المنتجات التي تحصل عليها من المصنع متوافقة مع بعضها البعض.
يمكنك تجنب الاقتران الوثيق بين المنتجات الملموسة ورمز العميل.
مبدأ المسؤولية الفردية. يمكنك استخراج كود إنشاء المنتج في مكان واحد، مما يسهل دعم الكود.
مبدأ مفتوح/مغلق. يمكنك تقديم أنواع جديدة من المنتجات دون كسر رمز العميل الحالي.
السلبيات:
قد تصبح التعليمات البرمجية أكثر تعقيدًا مما ينبغي، حيث يتم تقديم الكثير من الواجهات والفئات الجديدة جنبًا إلى جنب مع النمط. - علاقات نمط التصميم “Abstract pattern” مع الأنماط الأخرى
- تبدأ العديد من التصميمات باستخدام أسلوب المصنع Factory (أقل تعقيدًا وأكثر قابلية للتخصيص عبر الفئات الفرعية) وتتطور نحو Abstract Factory أو Prototype أو Builder (أكثر مرونة، ولكن أكثر تعقيدًا).
- يركز Builder على بناء الكائنات المعقدة خطوة بخطوة. Abstract Factory متخصص في إنشاء عائلات من الكائنات ذات الصلة. يقوم Abstract Factory بإرجاع المنتج على الفور، بينما يتيح لك Builder تشغيل بعض خطوات البناء الإضافية قبل جلب المنتج.
- تعتمد فئات Abstract Factory غالبًا على مجموعة من أساليب المصنع، ولكن يمكنك أيضًا استخدام النموذج الأولي لتكوين الأساليب في هذه الفئات.
- يمكن أن يعمل Abstract Factory كبديل لـ Facade عندما تريد فقط إخفاء الطريقة التي يتم بها إنشاء كائنات النظام الفرعي من كود العميل.
- يمكنك استخدام Abstract Factory مع Bridge. يكون هذا الاقتران مفيدًا عندما لا تعمل بعض التجريدات التي يحددها Bridge إلا مع تطبيقات محددة. في هذه الحالة، يمكن لـ Abstract Factory تغليف هذه العلاقات وإخفاء التعقيد عن كود العميل.
- الخاتمة
يعد نمط Abstract Factory مفيدًا عندما تحتاج إلى التأكد من أن الكائنات التي تم إنشاؤها متوافقة مع بعضها البعض وعندما يحتاج النظام إلى تكوينه مع عائلات متعددة من الكائنات. إنه يعزز الاقتران غير المحكم بين كود العميل والفئات المحددة، مما يسهل تغيير أو توسيع مجموعات المنتجات دون التأثير على بقية الكود.
- المراجع
