يُعرف المشروع الذي يتضمّن وحدات Gradle متعددة باسم مشروع متعدد الوحدات. يشمل هذا الدليل أفضل الممارسات والأنماط المقترَحة لتطوير تطبيقات Android متعددة الوحدات.
مشكلة قاعدة الرموز المتزايدة
في قاعدة رموز متزايدة باستمرار، غالبًا ما تنخفض قابلية التوسّع وإمكانية القراءة وجودة الرموز بشكل عام بمرور الوقت. ويحدث ذلك نتيجة زيادة حجم قاعدة الرموز بدون اتّخاذ المسؤولين عن صيانتها إجراءات نشطة لفرض بنية يسهل صيانتها. تُعد عملية التقسيم إلى وحدات وسيلة لتنظيم قاعدة الرموز البرمجية بطريقة تحسّن إمكانية الصيانة وتساعد في تجنُّب هذه المشاكل.
ما هي عملية التقسيم إلى وحدات؟
التقسيم إلى وحدات هو ممارسة لتنظيم قاعدة رموز برمجية إلى أجزاء غير مرتبطة بإحكام ومستقلة. كل جزء هو وحدة. كل وحدة مستقلة وتخدم غرضًا واضحًا. من خلال تقسيم المشكلة إلى مشاكل فرعية أصغر وأسهل في الحل، يمكنك تقليل تعقيد تصميم نظام كبير وصيانته.
مزايا التقسيم إلى وحدات
تتعدّد مزايا تقسيم التطبيق إلى وحدات، ولكن يتركّز كل منها على تحسين قابلية صيانة قاعدة الرموز وجودتها بشكل عام. يلخّص الجدول التالي المزايا الرئيسية.
| المزايا | ملخّص |
|---|---|
| إمكانية إعادة الاستخدام | تتيح إمكانية التقسيم إلى وحدات فرصًا لمشاركة الرموز البرمجية وإنشاء تطبيقات متعددة من الأساس نفسه. الوحدات هي في الواقع لبنات أساسية. يجب أن تكون التطبيقات عبارة عن مجموعة من ميزاتها، ويجب تنظيم الميزات كوحدات منفصلة. قد تكون الوظيفة التي توفّرها وحدة نمطية معيّنة مفعَّلة أو غير مفعَّلة في تطبيق معيّن. على سبيل المثال، يمكن أن يكون :feature:news جزءًا من إصدار التطبيق الكامل وتطبيق Wear، ولكن ليس جزءًا من إصدار التطبيق التجريبي. |
| التحكّم الصارم في إذن الوصول | تتيح لك الوحدات التحكّم بسهولة في ما تعرضه لأجزاء أخرى من قاعدة الرموز البرمجية. يمكنك وضع علامة internal أو private على كل شيء باستثناء الواجهة العامة لمنع استخدامه خارج الوحدة. |
| طريقة العرض القابلة للتخصيص | تستفيد ميزة عرض الميزات في Play من الإمكانات المتقدّمة لحِزم التطبيقات، ما يتيح لك عرض ميزات معيّنة في تطبيقك بشكل مشروط أو عند الطلب. |
لا يمكن الاستفادة من مزايا التقسيم إلى وحدات إلا باستخدام قاعدة رموز مقسَّمة إلى وحدات. يمكن تحقيق المزايا التالية باستخدام تقنيات أخرى، ولكن يمكن أن تساعدك عملية التقسيم إلى وحدات في فرضها بشكل أكبر.
| المزايا | ملخّص |
|---|---|
| سهولة التطوير | في قاعدة الرموز البرمجية المرتبطة بإحكام، يمكن أن يؤدي تغيير واحد إلى سلسلة من التعديلات في أجزاء من الرمز تبدو غير ذات صلة. سيتبنّى المشروع الذي تم تقسيمه إلى وحدات بشكل صحيح مبدأ فصل الاهتمامات، وبالتالي سيحدّ من الربط. ويمنح ذلك المساهمين المزيد من الاستقلالية. |
| الملكية | بالإضافة إلى إتاحة الاستقلالية، يمكن استخدام الوحدات أيضًا لفرض المساءلة. يمكن أن يكون لكل وحدة مالك مخصّص مسؤول عن صيانة الرمز البرمجي وإصلاح الأخطاء وإضافة الاختبارات ومراجعة التغييرات. |
| التغليف | يعني التغليف أنّ كل جزء من الرمز البرمجي يجب أن يتضمّن أقل قدر ممكن من المعلومات حول الأجزاء الأخرى. يسهل قراءة التعليمات البرمجية المعزولة وفهمها. |
| إمكانية الاختبار | تشير قابلية الاختبار إلى مدى سهولة اختبار التعليمات البرمجية. قاعدة الرموز البرمجية القابلة للاختبار هي تلك التي يمكن اختبار مكوناتها بسهولة بشكل منفصل. |
| مدّة التصميم | يمكن لبعض وظائف Gradle، مثل الإنشاء التزايدي أو ذاكرة التخزين المؤقت للإنشاء أو الإنشاء المتوازي، الاستفادة من التصميم المعياري من أجل تحسين أداء الإنشاء. |
المشاكل الشائعة
تشير دقة قاعدة الرموز البرمجية إلى مدى توفّرها على شكل وحدات. يحتوي قاعدة الرموز الأكثر تفصيلاً على وحدات أكبر وأصغر. عند تصميم قاعدة رموز برمجية مقسّمة إلى وحدات، عليك تحديد مستوى التفصيل. لإجراء ذلك، ضَع في اعتبارك حجم قاعدة الرموز ومدى تعقيدها. سيؤدي التحديد الدقيق جدًا إلى زيادة العبء، بينما سيؤدي التحديد غير الدقيق إلى تقليل مزايا التقسيم إلى وحدات.
في ما يلي بعض المشاكل الشائعة:
- التفصيل المفرط: يضيف كل وحدة مقدارًا معيّنًا من الحمل الزائد في شكل زيادة في تعقيد عملية الإنشاء والرمز النموذجي. يصعّب إعدادات الإصدار المعقّدة الحفاظ على اتساق الإعدادات في جميع الوحدات. يؤدي استخدام الكثير من الرموز النموذجية إلى إنشاء قاعدة رموز معقّدة يصعب صيانتها. إذا كانت النفقات العامة تعيق تحسينات قابلية التوسّع، عليك التفكير في دمج بعض الوحدات.
- التفاصيل غير كافية: على العكس من ذلك، إذا كانت وحداتك تزداد حجمًا، قد ينتهي بك الأمر إلى إنشاء بنية متكاملة أخرى وتفويت المزايا التي توفّرها البنية النموذجية. على سبيل المثال، في مشروع صغير، لا بأس بوضع طبقة البيانات داخل وحدة نمطية واحدة. ولكن مع نموّه، قد يصبح من الضروري فصل المستودعات ومصادر البيانات إلى وحدات مستقلة.
- معقّد جدًا: ليس من المنطقي دائمًا تقسيم مشروعك إلى وحدات. أحد العوامل المهمة هو حجم قاعدة الرموز البرمجية. إذا كنت لا تتوقّع أن يتجاوز مشروعك حدًا معيّنًا، لن تنطبق مزايا قابلية التوسّع ووقت الإنشاء.
هل التقسيم إلى وحدات هو الأسلوب المناسب لي؟
إذا كنت بحاجة إلى مزايا إعادة الاستخدام أو التحكّم الدقيق في مستوى العرض أو استخدام ميزة عرض الميزات في Play، فإنّ تقسيم التطبيق إلى وحدات أمر ضروري لك. إذا لم تكن بحاجة إلى ذلك، ولكنك لا تزال تريد الاستفادة من قابلية التوسّع أو الملكية أو التغليف أو أوقات الإنشاء المحسّنة، ننصحك بالتفكير في تقسيم التطبيق إلى وحدات.
نماذج
- Now in Android: تطبيق Android يعمل بكامل وظائفه ويتضمّن ميزة التقسيم إلى وحدات.
- نموذج بنية متعددة الوحدات