كتابة البرمجيات هي عمل創造ي، وتطوير Android ليس استثناء. لا يتعلق الأمر فقط بجعل شيء يعمل، بل يتعلق بتصميم تطبيقات يمكن أن تنمو وتتكيف وتظل قابلة للتحكم مع مرور الوقت.

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

سيوفر هذا المقال رؤية حول كيفية تطبيق مبادئ SOLID في تطوير Android من خلال أمثلة من العالم الحقيقي وطرق عملية وخبرات من فريق Meta WhatsApp.

فهم مبادئ SOLID

مبادئ SOLID، التي اقترحها روبرت سي. مارتن، هي خمسة مبادئ تصميم لبرمجة الكائنات التي تضمن هندسة برمجية نظيفة وفعالة.

• مبدأ المسؤولية الواحدة (SRP): يجب أن يكون للفئة سبب واحد فقط للتغيير.
• مبدأ مفتوح/مغلق (OCP): يجب أن تكون الكيانات البرمجية مفتوحة للتوسيع ولكن مغلقة للتغيير.
• مبدأ استبدال لاسكوف (LSP): يجب أن تكون الفئات الفرعية قابلة للاستبدال بفئاتها الأساسية.
• مبدأ تجزئة الواجهة (ISP): يجب أن تكون الواجهات محددة للعميل ولا تفرض تنفيذ أساليب غير مستخدمة.
• مبدأ عكس التبعية (DIP): يجب أن تعتمد الوحدات عالية المستوى على التstractions وليس على الوحدات منخفضة المستوى.

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

مبدأ المسؤولية الواحدة (SRP): تحسين المسؤوليات

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

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

class NewsRepository {
fun fetchNews(): List {
// يتعامل مع منطق استرجاع البيانات
}
}

class NewsViewModel(private val newsRepository: NewsRepository) {
fun loadNews(): LiveData {
// يدير حالة الواجهة وflux البيانات
}
}

class NewsActivity : AppCompatActivity() {
// يتعامل فقط مع عرض الواجهة
}

كل فئة لها مسؤولية واحدة فقط؛ لذا من السهل اختبارها وتعديلها دون وجود آثار جانبية.

في تطوير Android الحديث، يتم تنفيذ مبدأ المسؤولية الواحدة بشكل شائع جنبًا إلى جنب مع الهيكل الموصى به باستخدام Jetpack. على سبيل المثال، قد توجد منطق متعلقة بمنطق تعديل البيانات داخل ViewModel، بينما يجب على الأنشطة أو الشظايا فقط الاهتمام بالواجهة والتفاعلات. قد يتم تفويض استرجاع البيانات إلى مستودع منفصل، إما من قواعد بيانات محلية مثل Room أو طبقات الشبكة مثل Retrofit. هذا يقلل من خطر انتفاخ فئات الواجهة، منذ أن تتلقى كل مكون مسؤولية واحدة فقط. في نفس الوقت، سيكون кодك أسهل في الاختبار والدعم.

مبدأ مفتوح/مغلق (OCP): تصميم للتوسيع

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

أفضل مثال لاستخدام مبدأ مفتوح/مغلق في تطبيقات Android هو الواجهات والفئات المجردة. على سبيل المثال:

interface PaymentMethod {
fun processPayment(amount: Double)
}

class CreditCardPayment : PaymentMethod {
override fun processPayment(amount: Double) {
// تنفيذ عملية الدفع بالبطاقة الائتمانية
}
}

class PayPalPayment : PaymentMethod {
override fun processPayment(amount: Double) {
// تنفيذ عملية الدفع عبر PayPal
}
}

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

في التطبيقات المطورة لأجهزة Android، مبدأ مفتوح/مغلق مفيد جدًا عند التعامل مع ميزات التoggles والتكوين الذي يتم أخذه بشكل ديناميكي. على سبيل المثال، إذا كان تطبيقك يحتوي على واجهة AnalyticsTracker الأساسية التي تقارير الأحداث إلى خدمات تحليلات مختلفة، Firebase وMixpanel وtrackers داخلية مخصصة، يمكن إضافة كل خدمة جديدة كفئة منفصلة دون تغيير الكود الحالي. هذا يحافظ على وحدة التحليل مفتوحة للتوسيع – يمكنك إضافة متعقبين جدد – مغلقة للتغيير: لا تكتب فئات موجودة كل مرة تضيف خدمة جديدة.

مبدأ استبدال لاسكوف (LSP): ضمان القابلية للاستبدال

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

على سبيل المثال، تطبيق رسم:

abstract class Shape {
abstract fun calculateArea(): Double
}

class Rectangle(private val width: Double, private val height: Double) : Shape() {
override fun calculateArea() = width * height
}

class Circle(private val radius: Double) : Shape() {
override fun calculateArea() = Math.PI * radius * radius
}

يمكن استبدال Rectangle و Circle بأي منهما بشكل متبادل دون فشل النظام، مما يعني أن النظام مرن ويتوافق مع LSP.

فكر في فئات RecyclerView.Adapter في Android. كل فئة فرعية من المُحوِّل تمتد من RecyclerView.Adapter<VH> ويتغلب على الوظائف الأساسية مثل onCreateViewHolder و onBindViewHolder و getItemCount. يمكن لـ RecyclerView استخدام أي فئة فرعية بشكل متبادل طالما تم تنفيذ هذه الطرق بشكل صحيح ولا يتعارض مع وظائف التطبيق. هنا، يتم الحفاظ على LSP، ويمكن لـ RecyclerView استبدال أي فئة فرعية بمحوِّل في أي وقت.

مبدأ تجزئة الواجهة (ISP): واجهات رشيقة ومُركَّزة

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

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

على سبيل المثال، بدلاً من وجود واجهة واحدة كبيرة تمثل إجراءات المستخدم، فكر في الكود التالي:

interface Authentication {
fun login()
fun logout()
}

interface ProfileManagement {
fun updateProfile()
fun deleteAccount()
}

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

مبدأ عكس التبعية (DIP): تجريد التبعيات

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

على سبيل المثال:

class UserRepository @Inject constructor(private val apiService: ApiService) {
fun fetchUserData() {
// يسترجع بيانات المستخدم من تجريد
}
}

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

تسهل الإطارات مثل Hilt وDagger وKoin الحقن التابع بتقديم طريقة لتزويد التبعيات لمكونات Android، مما يلغي الحاجة إلى إنشاءها بشكل مباشر. في مستودع، على سبيل المثال، بدلاً من إنشاء تنفيذ Retrofit، ستحقن تجريدًا – على سبيل المثال، واجهة ApiService. بهذه الطريقة، يمكنك بسهولة التبديل بين تنفيذ الشبكة – على سبيل المثال، خدمة محاكاة في الذاكرة للاختبار المحلي – ولا تحتاج إلى تغيير أي شيء في كود المستودع. في التطبيقات الواقعية، يمكنك أن تجد أن الفئات تم تعليمها بـ @Inject أو @Provides لتزويد هذه التجريدات، مما يجعل تطبيقك موديولارًا وسهل الاختبار.

الفوائد العملية لمبادئ SOLID

تبني مبادئ SOLID في تطوير Android يولد فوائد ملموسة:

1. تحسين الاختبار: الفئات والواجهات المُركَّزة تجعل من السهل كتابة اختبارات الوحدات.
2. تحسين الصيانة: الفصل الواضح للمسؤوليات يبسط عملية التصحيح والتحديث.
3. القدرة على التوسيع: التصميمات الموديولار تمكن من إضافة الميزات بسلاسة.
4. التعاون: الكود المنظم يسهل التعاون ويقلل من وقت التأهيل للمطورين الجدد.
5. تحسين الأداء: الهياكل النحيفة والفعالة تقلل من المعالجة غير الضرورية واستخدام الذاكرة.

التطبيقات الواقعية

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

عند العمل على مشروع كبير يتطلب العديد من المطورين للتعاون، من المستحسن الحفاظ على قاعدة كود معقدة مع مبادئ SOLID. على سبيل المثال، فصل استرجاع البيانات وطريقة الأعمال ومعالجة الواجهة في وحدة الدردشة ساعد في تقليل فرص الانحدارات أثناء توسيع الكود بميزات جديدة. وبالمثل، كان تطبيق DIP حاسمًا لتحديد العمليات الشبكية، وبالتالي تمكنا من التبديل بين عملاء الشبكة几乎 دون أي انقطاع.

الختام

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

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