أنماط العمارة في Kotlin: MVC، MVP، MVVM و MVI

كيف لا تغرق في الفوضى: أنماط العمارة في Kotlin

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

أنماط العمارة في Kotlin ليست موضة أو نظريات مجردة. إنها خلاص من "الكود المعكرونة" حيث كل شيء مختلط: منطق الأعمال، واجهة المستخدم، العمل مع الشبكة وقاعدة البيانات. في هذه المقالة سنقوم بتحليل أربعة أنماط رئيسية: MVC، MVP، MVVM و MVI. ستراها وهي تعمل على أمثلة حقيقية في Kotlin، وستفهم الاختلافات الرئيسية وستتمكن من اختيار الأداة المناسبة لمهمتك. هيا بنا!

ما هو نمط العمارة ولماذا هو مطلوب؟

نمط العمارة هو الهيكل العظمي لتطبيقك. إنه يحدد كيفية تواصل الفئات مع بعضها البعض، وأين يتم تخزين البيانات، ومن المسؤول عن العرض. بدونه، عاجلاً أم آجلاً ستحصل على God Object - فئة تفعل كل شيء. أو Callback Hell - عندما تولد استدعاءات رد الاتصال استدعاءات أخرى، ويصبح الكود غير قابل للقراءة.

Kotlin، بتركيبها المختصر وأمانها الصفري، مثالية للعمارة النظيفة. لكن اللغة هي نصف المعادلة فقط. النصف الآخر هو الاختيار الصحيح للنمط.

MVC (Model-View-Controller) - كلاسيكي هذا النوع

أقدم وأبسط نمط. جوهره:

• Model - البيانات ومنطق الأعمال.
• View - العرض (Activity، Fragment، Compose).
• Controller - حلقة الوصل، يعالج إدخال المستخدم.

في Kotlin (خاصة لنظام Android) غالبًا ما يتحول MVC إلى "Controller سمين". تصبح Activity هي View و Controller في نفس الوقت. مثال:

// سيء: Activity هي View و Controller في آن واحدclass LoginActivity : AppCompatActivity() {    private lateinit var emailEditText: EditText    private lateinit var passwordEditText: EditText

    override fun onCreate(savedInstanceState: Bundle?) {        super.onCreate(savedInstanceState)        setContentView(R.layout.activity_login)

        // منطق Controller هنا مباشرة        findViewById<Button>(R.id.loginButton).setOnClickListener {            val email = emailEditText.text.toString()            val password = passwordEditText.text.toString()            // التحقق واستدعاء API - كل شيء في مكان واحد            if (email.isNotEmpty() && password.isNotEmpty()) {                loginUser(email, password)            }        }    }

    private fun loginUser(email: String, password: String) {        // العمل مع الشبكة - مباشرة في Activity        CoroutineScope(Dispatchers.IO).launch {            val result = api.login(email, password)            withContext(Dispatchers.Main) {                // تحديث واجهة المستخدم - هنا أيضًا                Toast.makeText(this@LoginActivity, result.message, Toast.LENGTH_SHORT).show()            }        }    }}

الإيجابيات: البساطة، عتبة دخول منخفضة.

السلبيات: View و Controller مرتبطان بشدة. من المستحيل اختبار المنطق بدون محاكي Android. للمشاريع الكبيرة - جحيم.

MVP (Model-View-Presenter) - فصل السلطات

يحل MVP المشكلة الرئيسية لـ MVC: يتم فصل View عن المنطق من خلال الواجهات. Presenter هو "العقل" الذي لا يعرف شيئًا عن Android. View هي طبقة سلبية.

مثال في Kotlin:

// واجهات للتواصلinterface LoginView {    fun showLoading()    fun hideLoading()    fun showError(message: String)    fun navigateToHome()}

class LoginPresenter(private val view: LoginView, private val authRepository: AuthRepository) {

    fun login(email: String, password: String) {        view.showLoading()        CoroutineScope(Dispatchers.IO).launch {