اذهب إلى المحتوى

البحث في الموقع

المحتوى عن 'ood'.

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المحتوى


التصنيفات

  • الإدارة والقيادة
  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • السلوك التنظيمي في المؤسسات
  • عالم الأعمال
  • التجارة والتجارة الإلكترونية
  • نصائح وإرشادات
  • مقالات ريادة أعمال عامة

التصنيفات

  • مقالات برمجة عامة
  • مقالات برمجة متقدمة
  • PHP
    • Laravel
    • ووردبريس
  • جافاسكربت
    • لغة TypeScript
    • Node.js
    • React
    • Vue.js
    • Angular
    • jQuery
    • Cordova
  • HTML
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • لغة C#‎
    • ‎.NET
    • منصة Xamarin
  • لغة C++‎
  • لغة C
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • لغة Rust
  • برمجة أندرويد
  • لغة R
  • الذكاء الاصطناعي
  • صناعة الألعاب
  • سير العمل
    • Git
  • الأنظمة والأنظمة المدمجة

التصنيفات

  • تصميم تجربة المستخدم UX
  • تصميم واجهة المستخدم UI
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب GIMP
    • كريتا Krita
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • مقالات DevOps عامة
  • خوادم
    • الويب HTTP
    • البريد الإلكتروني
    • قواعد البيانات
    • DNS
    • Samba
  • الحوسبة السحابية
    • Docker
  • إدارة الإعدادات والنشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
    • ريدهات (Red Hat)
  • خواديم ويندوز
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • شبكات
    • سيسكو (Cisco)

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح
  • مبادئ علم التسويق

التصنيفات

  • مقالات عمل حر عامة
  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • العمل الحر المهني
    • العمل بالترجمة
    • العمل كمساعد افتراضي
    • العمل بكتابة المحتوى

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
    • بريستاشوب
    • أوبن كارت
    • دروبال
  • الترجمة بمساعدة الحاسوب
    • omegaT
    • memoQ
    • Trados
    • Memsource
  • برامج تخطيط موارد المؤسسات ERP
    • تطبيقات أودو odoo
  • أنظمة تشغيل الحواسيب والهواتف
    • ويندوز
    • لينكس
  • مقالات عامة

التصنيفات

  • آخر التحديثات

أسئلة وأجوبة

  • الأقسام
    • أسئلة البرمجة
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات

التصنيفات

  • كتب ريادة الأعمال
  • كتب العمل الحر
  • كتب تسويق ومبيعات
  • كتب برمجة
  • كتب تصميم
  • كتب DevOps

ابحث في

ابحث عن


تاريخ الإنشاء

  • بداية

    نهاية


آخر تحديث

  • بداية

    نهاية


رشح النتائج حسب

تاريخ الانضمام

  • بداية

    نهاية


المجموعة


النبذة الشخصية

تم العثور على 2 نتائج

  1. مبدأ فصل الواجهات Interface Segregation Principle أو اختصارًا ISP هو أحد المبادئ الشهيرة من مبادئ SOLID في التصميم الكائنيّ. أوّل من قدّم هذا المبدأ روبرت مارتن في سلسلة مقالات في عام 1996، ويهدف هذا المبدأ إلى تجنُّب إنشاء واجهات "سمينة". الواجهة interface هي عبارة عن تجريد abstraction لناحية وظيفيّة (أو أكثر) ترث منها أنواع (أصناف) لدعم هذه الناحيّة الوظيفيّة، ونقول في هذه الحالة أنّ الصنف الابن يُحقّق الواجهة. فمثلًا تُعرّف الواجهة IComparer في لغة C# إمكانيّة المقارنة بين كائنين يحقّق صنفهما الواجهة IComparer. في لغات برمجة أخرى، قد لا يوجد تمثيل منفصل للواجهة، وإنّما يتم إنشاء أصناف ذات طبيعة مجرّدة لهذا الغرض، نسميها أصناف واجهة، وهي التي سنتحدّث عنها في هذا المقال. تظهر الواجهات السمينة (أو الملوّثة) بسبب توسعة صنف واجهة حالي ببعض النواحي الوظيفيّة الجديدة المفيدة لمجموعة جزئيّة فقط من التوابع methods. تؤدّي هذه الظاهرة في نهاية الأمر إلى إنشاء توابع ليس لها أيّ فائدة سوى تحقيق الواجهة للتمكّن من استخدامها. وهذا أمر سيّء بالطبع. تُعتبر تلك التوابع خطرة وهي تخرق على أيّة حال مبدأ LSP أيضًا. ينص مبدأ ISP كما كتبه المؤلّف: ينبغي أن يكون لكلّ واجهة هدف معرّف بوضوح ويُعبّر عن ناحية وظيفيّة مُحدّدة للمسألة المطروحة. الحل الأمثل (برأيي) لتحقيق هذا المبدأ هو استخدام الوراثة المتعدّدة عند تحقيق الواجهات. سيعمل هذا الأسلوب على فصل النواحي الوظيفيّة التي لا ترتبط منطقيًّا مع بعضها ويلغي الاعتماديّات dependencies الخاطئة. لنستعرض مثالًا يخرق مبدأ ISP. يتناول هذا المثال واجهة خاصّة بالنواحي الوظيفيّة الّتي من الممكن أن تمتلكها أي سيّارة: /* Bad example */ class CarOperation { public: virtual void steer(int degrees) = 0; virtual void pullHandbrake() = 0; virtual void accelerate() = 0; virtual void shift(int gear) = 0; virtual void toggleAirConditioning() = 0; }; هناك العديد من المزايا المألوفة التي توفّرها السيّارات، فكل سيّارة لها عجلة قيادة ومدوسة وقود بالإضافة إلى ناقل حركة يدوي وفرامل اليد. ولكن ماذا عن السيّارات التي لها ناقل حركة أوتوماتيكي؟ ففي مثل هذه السيّارات لا يوجد ناقل حركة يدوي، فالصنف الواجهة الوارد في الشيفرة السابقة سيجبر أي صنف ابن يرث منه على استخدام الطريقة shift التي تُعبّر عن ناقل حركة اليدوي حتى ولو كان هذا الصنف الابن يمثّل سيّارة ذات ناقل أوتوماتيكي. وينطبق نفس الكلام على الطريقة toggleAirConditioning التي تعبّر عن تشغيل جهاز التكييف في السيّارة رغم أنّ بعض السيّارات لا تملك جهاز تكييف. الأفضل في هذه الحالة أن نجزّئ الصنف الواجهة CarOperation إلى عدد من أصناف الواجهات الأصغر بحيث تُعبّر كلّ منها عن مجموعة محدّدة مترابطة منطقيًّا من المزايا: class BasicCarOperation { public: virtual void steer(int degrees) = 0; virtual void pullHandbrake() = 0; virtual void accelerate() = 0; }; class GearboxCarOperation { public: virtual void shift(int gear) = 0; }; class AirConditioningCarOperation { public: virtual void toggleAirConditioning() = 0; }; class AlfaRomeo166 : public BasicCarOperation, GearboxCarOperation, AirConditioningCarOperation { /* Implementation of all the interfaces. */ }; class SkodaFavorit136L : public BasicCarOperation, GearboxCarOperation { /* No air conditioning for old cars. */ }; سيلجأ الصنفان الابنان AlfaRomeo166 وSkodaFavorit136L إلى الوراثة المتعدّدة من الأصناف الواجهات. فإذا أردنا تشغيل جهاز التكييف في سيّارة ما عن طريق الدالّة beCool فسيكون ذلك كالتالي: void beCool(AirConditioningCarOperation* vehicle) { vehicle->toggleAirConditioning(); } نلاحظ أنّنا الدالّة beCool تقبل وسيطًا واحدًا وهو مؤشّر إلى كائن من النوع AirConditioningCarOperation، وهكذا فإنّ أي صنف ابن يرث من الصنف الواجهة AirConditioningCarOperation يمكن أن يُمرَّر إلى هذه الدالة بصرف النظر عن أيّ أصناف واجهات أخرى يرث منها هذا الصنف الابن. وهنا يكمن جمال مبدأ فصل الواجهات. سنحصل تمامًا على ما نريد، ليس أكثر وليس أقل، مما يجعل من الشيفرة البرمجيّة أسهل للصيانة ولإعادة الاستخدام وللفهم، ويساعد ذلك على تجنّب كم كبير من الأخطاء عندما نريد تعديل الشيفرة في المستقبل. المصادر: http://www.oodesign.com/interface-segregation-principle.html http://en.wikipedia.org/wiki/Interface_segregation_principle http://www.objectmentor.com/resources/articles/isp.pdf ترجمة -وبتصرّف- للمقال Interface Segregation Principle لصاحبه Radek Pazdera.
  2. مبدأ عكس التابعيّة Dependency Inversion Principle أو اختصارًا DIP، هو آخر مبادئ التصميم الكائنيّ SOLID ويتمتّع بمزايا كبيرة عند تطبيقه بالشكل السليم. أوّل من قدّم هذا المبدأ هو روبرت مارتن في مقالته التي نشرها عام 1996. أشار روبرت إلى أنّ الأسلوب الشائع في تصميم التابعيّة dependency ضمن المشاريع البرمجيّة في جعل الوحدات البرمجيّة عالية المستوى تعتمد على الوحدات البرمجيّة منخفضة المستوى بشكل مباشر هو أسلوب غير عمليّ ويؤدّي إلى مشاكل كبيرة عند إعادة استخدام الوحدات البرمجيّة عالية المستوى، تتمثّل هذه المشاكل في إجراء تعديلات برمجيّة عديدة عليها كي تتلاءم مع الاستخدام الجديد لها، وهذا بالطبع أمر غير جيّد. تُعتبر الوحدات البرمجيّة عالية المستوى بمثابة قلب التطبيق البرمجيّ. وقد نرغب في كثير من الأحيان أن نُعيد استخدامها في تطبيقات برمجيّة أخرى ولكن بدون إجراء تعديلات كبيرة عليها. يقترح روبرت مبدأ عكس التابعيّة والذي ينص على ما يلي: أ – لا ينبغي أن تعتمد الوحدات البرمجيّة عالية المستوى على الوحدات البرمجيّة منخفضة المستوى. يجب على كلّ منهما الاعتماد على واجهات (أصناف مجرّدة). ب – لا ينبغي أن تعتمد الواجهات/الأصناف المُجردّة على التفاصيل، فالتفاصيل هي من يجب أن تعتمد على الأصناف الواجهات. قد يكون من الصعب قليلًا فهم هذا المبدأ مباشرةً، لذلك اسمح لي بتوضيحه بشكل أفضل. يُقرّ هذا المبدأ أنّه ينبغي أن تكون هناك طبقة تجريديّة إضافيّة بين الوحدات البرمجيّة عالية ومنخفضة المستوى، تتألّف الطبقة التجريديّة من واجهات. فإذا كان لدينا وحدتان برمجيّتان أردنا أن تعتمد إحداهما على الأخر، فإنّ هذه الاعتماديّة ينبغي أن تتمّ عن طريق صنف واجهة معرّف خصيصًا لهذا الغرض. بهذا الأسلوب، فإنّ الوحدات البرمجيّة عالية المستوى لا تتعامل مباشرةً مع الوحدات البرمجيّة منخفضة المستوى. ستعمل الوحدات البرمجيّة منخفضة المستوى على تحقيق الواجهات (نستطيع القول أنّها سترث منها)، ففي حال أردنا استخدام أي وحدة برمجيّة في مشروع برمجيّ آخر فلن نحتاج إلى تعديل أيّ شيء ضمن الشيفرة البرمجيّة لها. فكل ما نحتاجه ببساطة هو تحقيق الواجهات التي ستعتمد عليها الوحدة البرمجيّة المراد إعادة استخدامها. بالنسبة للقسم الثاني من المبدأ (الفقرة ب) فهو ينبّه بأنّ الواجهات ينبغي ألّا تصمّم وفقًا للوحدات البرمجيّة منخفضة المستوى (التفاصيل). حيث ينبغي أن تُحقّق الأصناف الوجهات على نفس مستوى التجريد الذي تتمتّع به الوحدات البرمجيّة عالية المستوى. مثال عن عكس التابعيّة لنستعرض الآن مثالًا حول كيفية تطبيق هذا المبدأ. يدور هذا المثال حول التعامل مع الواجهات الرسوميّة للمستخدم، ليكن لدينا صنف يمثّل نافذة Window تحوي زرّين Button: class Button { public: void makeVisible(); }; class Window { Button* okButton; Button* cancelButton; Window() { okButton = new Button; okButton->makeVisible(); cancelButton = new Button; cancelButton->makeVisible(); } }; تكمن المشكلة هنا أنّه إذا تغيّر الصنف Button، سنضطّر إلى تغيير بانية الصنف Window أيضًا، وهذا بالطبع أمر غير مرغوب به، لأنّ الصنف Window سيكون عُرضةً للكثير من الاختبارات أثناء بناء البرنامج، وهذا سيؤدّي إلى الكثير من الأخطاء في كلّ مرّة نُعدّل فيها الصنف Button. يؤدّي استخدام صنف واجهة إلى تحسين التصميم إلى حدّ كبير: class IButton { public: static virtual IButton* getInstance() = 0; // factory method virtual void show() = 0; }; class Window { IButton* okButton; IButton* cancelButton; public: Window() { okButton = IButton::getInstance(); okButton->show(); cancelButton = IButton::getInstance(); cancelButton->show(); } }; class Button : public IButton { public: void show(); }; كما نرى الآن، يوجد صنف واجهة اسمه IButton وكل من الصنفين Button وWindow يعتمدان عليه. وهذا أمر جيّد للغاية، ففي حال أردنا استخدام الصنف Window في تطبيق برمجيّ جديد، فكل ما علينا هو استخدام أزرار Button تُحقّق الواجهة IButton فحسب. نلاحظ أيضًا التّابع الساكن getInstance الذي نستخدمه للحصول على الكائن الملائم من صنف الزر الذي يُحقّق صنف الواجهة IButton. المصادر http://www.objectmentor.com/publications/dip.pdf http://www.oodesign.com/dependency-inversion-principle.html http://en.wikipedia.org/wiki/Dependency_inversion_principle ترجمة -وبتصرّف- للمقال Dependency Inversion Principle لصاحبه Radek Pazdera.
×
×
  • أضف...