كيفية إنشاء بنية مكون من مكونات الإضافات مرنة؟

Question

كان السمة المتكررة في أعمال التطوير الخاصة بي هو استخدام أو إنشاء بنية مكون من قِبل في المنزل. لقد رأيت أنه اقترب من العديد من الطرق - ملفات التكوين (XML ، .Conf ، وما إلى ذلك) ، وأطر الميراث ، ومعلومات قاعدة البيانات ، والمكتبات ، وغيرها. في تجربتي:

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

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

بعض الأمثلة التي وجدتها بمفردي:

• بيرل الوحدة النمطية :: قابلية و IOC لحقن التبعية في بيرل
• أطر الربيع المختلفة (Java ، .NET ، Python) لحقن التبعية.
• و لذلك سؤال مع قائمة لجافا (بما في ذلك واجهات مزود الخدمة)
• و لذلك سؤال لـ C ++ يشير إلى أ مقال الدكتور دوبس
• و لذلك سؤال بخصوص فكرة مكون إضافي محدد لـ ASP.NET MVC

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

Answer 1

هذا ليس إجابه بقدر مجموعة من الملاحظات/الأمثلة المفيدة المحتملة.

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

• تطبيق واحد مددته قليلاً تراك. يحتوي على بنية مكونة تعني في هذه الحالة أن المهام تفويض إلى الوحدات النمطية التي تعلن عن نقاط التمديد. يمكنك بعد ذلك تنفيذ مكونات أخرى تتناسب مع هذه النقاط وتغيير التدفق. إنه يشبه إلى حد ما اقتراح Kalkie أعلاه.

• واحد آخر هذا جيد Py.Test. يتبع فلسفة "أفضل واجهة برمجة التطبيقات ليست واجهة برمجة التطبيقات" وتعتمد على السنانير البحتة التي يتم استدعاؤها على كل مستوى. يمكنك تجاوز هذه السنانير في الملفات/الوظائف المسمى وفقًا لاتفاقية وتغيير السلوك. يمكنك رؤية قائمة الإضافات على الموقع لمعرفة مدى سرعة/بسهولة تنفيذها.

بعض النقاط العامة.

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

Answer 2

في تجربتي ، وجدت أن هناك بالفعل نوعين من بنيات المكونات الإضافية.

1. واحد يتبع Eclipse model وهو المقصود منه السماح بالحرية وهو مفتوح.
2. عادة ما يتطلب الآخر الإضافات لمتابعة أ narrow API لأن البرنامج المساعد سوف يملأ وظيفة محددة.

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

التمييز دقيق ، وأحيانًا لا يوجد تمييز ... تريد كلاهما لتطبيقك.

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

Yegge's مدونة الخصائص يتحدث قليلاً عن كيفية يتيح استخدام نمط الخصائص الإضافات والتوسيع.

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

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

• الآن عادة لدي فقط DI framework القيام بمعظم هذا العمل.

لا يزال يتعين عليّ كتابة محولات لاستخدام مكتبات الطرف الثالث ، لكنها عادةً ليست بهذا السوء.

Answer 3

يتم تنفيذ واحدة من أفضل بنيات المكونات التي رأيتها في Eclipse. بدلاً من وجود تطبيق مع طراز إضافي ، يكون كل شيء مكونًا إضافيًا. التطبيق الأساسي نفسه هو إطار المكونات الإضافية.

http://www.eclipse.org/articles/article-plug-in-architecture/plugin_architecture.html

Answer 4

لقد عملت ذات مرة في مشروع كان يجب أن يكون مرنًا للغاية في الطريقة التي يمكن بها لكل عميل إعداد النظام ، وهو التصميم الجيد الوحيد الذي وجدناه هو شحن العميل A C#!

إذا كانت المواصفات مليئة بكلمات مثل:

• مرن
• توصيل في
• قابل للتخصيص

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

إن دعم العملاء (أو الأشخاص الدعمون في خط النافورة) يكتبون المكونات الإضافية أصعب بكثير من الهندسة المعمارية

Answer 5

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

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

للعثور على المكونات الإضافية ، يقوم التطبيق بمسح مجلد إضافي لـ .NET Assemblies. يتم تحميل كل مجموعة. يتم استخدام الانعكاس للمسح الضوئي للفئات التي تنفذ IPlugin. يتم إنشاء مثيل لكل فئة مكون الإضافي.

(بدلاً من ذلك ، قد يسرد ملف XML التجميعات والفئات التي يتم تحميلها. قد يساعد هذا في الأداء ، لكنني لم أجد مشكلة مع الأداء).

ال Init يتم استدعاء الطريقة لكل كائن إضافي. يتم تمرير مرجع إلى كائن يقوم بتطبيق واجهة التطبيق: IApplication (أو أي شيء آخر محدد لتطبيقك ، على سبيل المثال itexteditorapplication).

IApplication يحتوي على طرق تسمح للمكون الإضافي بالتواصل مع التطبيق. على سبيل المثال ، إذا كنت تكتب محرر نصية ، فستكون هذه الواجهة OpenDocuments الخاصية التي تسمح للمكونات الإضافية بتعداد مجموعة المستندات المفتوحة حاليًا.

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

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

Answer 6

المعتاد أنا أستخدم MEF. يبسيط إطار التوسيع المدار (أو MEF للاختصار) إنشاء تطبيقات قابلة للتمديد. تقدم MEF قدرات الاكتشاف والتكوين التي يمكنك الاستفادة منها لتحميل ملحقات التطبيق.

إذا كنت مهتمًا بقراءة أكثر...

Answer 7

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

لقد وجدت أن IOC (انقلاب التحكم) الرئيسي (قراءة springframework) يعمل بشكل جيد لتوفير قاعدة مرنة ، والتي يمكنك إضافة التخصص لجعل تطوير البرنامج المساعد أكثر بساطة.

• يمكنك فحص الحاوية لآلية "الواجهة كإعلان نوع إضافي".
• يمكنك استخدام الحاوية لضخ التبعيات الشائعة التي قد تتطلبها الإضافات (أي ResourceLoaderaware أو MessagesourCeaware).

Answer 8

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

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

لكي ينجح هذا ، يجب أن يكون لنظام البرمجة النصية واجهة برمجة تطبيقات قوية إلى حد ما ، مع وجود خطافات لبيانات التطبيق ، والمنطق ، و GUI ، وكذلك الوظائف الأساسية لاستيراد التعليمات البرمجية من المكتبات. علاوة على ذلك ، عادة ما تكون البرامج النصية مطلوبة آمنة بمعنى أن التطبيق يمكن أن يتعافى بأمان من نص مكتوب بشكل سيء. يعني استخدام نظام البرمجة النصية كطبقة من عدم التوجيه أن التطبيق يمكن أن ينفصل بسهولة أكبر في حالة وجود شيء سيء ™.

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