معماری و الگوها در توسعه موبایل: چیست، چه انواعی دارد و چگونه استفاده کنیم

الگوهای معماری اصلی

الگوی معماری تعیین می‌کند که مسئولیت‌ها چگونه بین کلاس‌های برنامه توزیع شوند. انتخاب الگو بر سهولت افزودن صفحه‌های جدید و آزمایش کد تأثیر می‌گذارد.

MVC (Model-View-Controller)

MVC یک الگوی کلاسیک است که در آن Model داده‌ها، View نمایش و Controller منطق را مدیریت می‌کند. در iOS، MVC پیش‌فرض است (UIViewController)؛ در Android، Activity. نقطه ضعف این است که Controller اغلب "حجیم" می‌شود (Massive View Controller). بر اساس نظرسنجی توسعه‌دهندگان iOS (Reddit، 2025)، 62٪ MVC را علت اصلی کد غیرقابل خواندن در پروژه‌های قدیمی می‌دانند.

MVP (Model-View-Presenter)

MVP از این جهت متفاوت است که Presenter View را از طریق یک رابط مدیریت می‌کند و قابلیت آزمایش را بهبود می‌بخشد. MVP قبل از Jetpack در Android محبوب بود، اما از نظر راحتی از MVVM عقب‌تر است.

MVVM (Model-View-ViewModel)

MVVM الگوی توصیه‌شده توسط Google برای Android و Apple برای iOS است. ViewModel وضعیت را ذخیره می‌کند و View از طریق Data Binding یا @Published تغییرات را دنبال می‌کند. ViewModel به View وابسته نیست و به راحتی قابل آزمایش است. در IT Sectr، ما از MVVM به عنوان الگوی اصلی در تمام پروژه‌ها استفاده می‌کنیم.

MVI و VIPER

MVI یک الگوی واکنشی است که در آن هر اقدام از چرخه Intent → Model → View پیروی می‌کند. MVI وضعیت قابل پیش‌بینی را تضمین می‌کند. VIPER یک الگوی iOS با پنج لایه (View، Interactor، Presenter، Entity، Router) است که حداکثر جداسازی را فراهم می‌کند اما به کدهای قالبی زیادی نیاز دارد.

Clean Architecture

Clean Architecture مفهوم رابرت مارتین است که برنامه را به لایه‌ها تقسیم می‌کند: لایه‌های بیرونی (UI، DB، شبکه) به لایه‌های داخلی (منطق کسب‌وکار، موجودیت‌ها) وابسته هستند. در توسعه موبایل، Clean Architecture شامل سه لایه است: data (مخازن)، domain (Use Cases) و presentation (ViewModels، UI).

Repository Pattern یک مؤلفه کلیدی Clean Architecture است که منبع داده را انتزاعی می‌کند. مخزن تصمیم می‌گیرد داده‌ها را از شبکه یا ذخیره‌سازی محلی (Room، Core Data) دریافت کند و قالبی یکپارچه برمی‌گرداند. به گفته Google (Architecture Guide, 2025)، Repository Pattern برای هر برنامه‌ای با درخواست‌های شبکه توصیه می‌شود. Clean Architecture در پروژه‌های با ۳ تا ۵ صفحه یا بیشتر توجیه‌پذیر است — برای برنامه‌های ساده، با MVVM شروع کنید.

الگوهای ایجاد

Singleton

Singleton یک الگوی معماری است که یک نمونه واحد از یک کلاس را تضمین می‌کند و یک نقطه دسترسی جهانی به آن فراهم می‌کند. برای پایگاه داده، مدیر تنظیمات و حافظه نهان استفاده می‌شود. در Kotlin با object ایجاد می‌شود. نقطه ضعف این است که به دلیل وضعیت جهانی، آزمایش را پیچیده می‌کند.

Factory و Builder

Factory ایجاد اشیاء را به یک روش کارخانه‌ای واگذار می‌کند — به جای new، کارخانه را فراخوانی می‌کنید. Builder یک الگوی ساخت گام‌به‌گام برای اشیاء پیچیده با پارامترهای زیاد (AlertDialog.Builder، NotificationCompat.Builder) است. Builder خوانایی را بهبود می‌بخشد و به اشیاء اجازه می‌دهد پس از مونتاژ تغییرناپذیر باقی بمانند.

الگوهای ساختاری و رفتاری

Adapter، Facade، Delegate، Protocol

Adapter یک الگوی معماری است که رابط یک کلاس را به رابط مورد انتظار مشتری تبدیل می‌کند. در Android، این RecyclerView.Adapter است. Facade یک رابط ساده‌شده برای یک سیستم پیچیده فراهم می‌کند — مثلاً، نمای ظاهری برای API که جزئیات احراز هویت را پنهان می‌کند. Delegate یک الگوی iOS است که در آن یک شیء یک وظیفه را واگذار می‌کند (UITableViewDelegate). Protocol معادل رابط در Swift است.

Observer و Strategy

Observer یک الگوی اشتراک برای تغییرات است: موضوع، مشترکان را از به‌روزرسانی‌ها مطلع می‌کند. در توسعه موبایل، Observer پایه LiveData، StateFlow، RxJava و Combine است. Strategy یک الگوی الگوریتم‌های قابل تعویض است: شما یک استراتژی متفاوت (مرتب‌سازی، اعتبارسنجی) بدون چندین دستور if-else وارد می‌کنید.

تزریق وابستگی و مدیریت وضعیت

Dependency Injection یک الگوی معماری است که در آن یک شیء وابستگی‌های خود را از بیرون دریافت می‌کند به جای اینکه خودش آنها را ایجاد کند. به جای new Database()، پایگاه داده را از طریق سازنده منتقل می‌کنید. DI آزمایش را ساده می‌کند — می‌توانید به جای پایگاه داده واقعی از Mock استفاده کنید — و تعویض پیاده‌سازی‌ها را آسان می‌کند. فریم‌ورک‌های DI محبوب: Dagger و Hilt (Android)، Swinject (iOS)، Koin (Kotlin). Hilt — یک پوشش روی Dagger که توسط Google توصیه شده — راه‌اندازی DI را ۳ برابر کاهش می‌دهد.

Service Locator یک جایگزین برای DI با یک ثبت مرکزی وابستگی‌ها است. پیاده‌سازی ساده‌تر است، اما وابستگی‌های کلاس را پنهان می‌کند و آزمایش را دشوارتر می‌کند. پروژه‌های مدرن DI را از طریق Hilt یا Koin ترجیح می‌دهند.

مدیریت وضعیت در Flutter

در Flutter، مدیریت وضعیت یک اکوسیستم جداگانه است. Redux — یک Store واحد با تغییرات از طریق Actions → Reducer → State. BLoC از Google رویدادها و وضعیت‌ها را از طریق Stream جدا می‌کند. Provider — یک ظرف DI ساده که توسط Google برای Flutter تا سال ۲۰۲۳ توصیه شده بود. Riverpod — یک Provider بهبودیافته که مشکلات کامپایل و آزمایش را حل می‌کند. GetX — یک میکرو فریم‌ورک با مسیریابی، DI و مدیریت وضعیت. برای توسعه‌دهندگان مبتدی Flutter، Provider یا Riverpod را به عنوان بهترین راه‌حل‌های مستند توصیه می‌کنیم.

اصول SOLID و DRY

علاوه بر الگوهای خاص، اصول کلی طراحی معماری وجود دارد که در هر زبان و فریم‌ورکی قابل اجرا هستند.

SOLID — پنج اصل طراحی شیءگرا: Single Responsibility (یک کلاس — یک وظیفه)، Open-Closed (باز برای گسترش، بسته برای تغییر)، Liskov Substitution (زیرکلاس‌ها می‌توانند جایگزین کلاس والد شوند)، Interface Segregation (رابط‌های کوچک)، Dependency Inversion (وابستگی به انتزاع‌ها). در توسعه موبایل، SRP مفیدترین اصل است: هر کلاس فقط یک کار انجام می‌دهد. بر اساس تجربه IT Sectr، نقض SRP علت ۷۰٪ مشکلات آزمایش در پروژه‌های تجاری است.

// Пример: нарушение SRP
class UserManager {
    fun saveUser(user: User) { /* сохранение */ }
    fun validateEmail(email: String): Boolean { /* валидация */ }
    fun sendEmail(user: User) { /* отправка */ }
    fun formatUser(user: User): String { /* форматирование */ }
}

// Исправление: разделяем на отдельные классы
class UserRepository { fun save(user: User) {} }
class EmailValidator { fun isValid(email: String): Boolean {} }
class EmailService { fun send(user: User) {} }
class UserFormatter { fun format(user: User): String {} }

مثال Kotlin نشان می‌دهد که چگونه یک کلاس UserManager با چهار مسئولیت را به چهار کلاس با یک مسئولیت هر کدام تبدیل می‌کنیم. چنین کدی آزمایش، تغییر و استفاده مجدد آسان‌تر است.

DRY (Don't Repeat Yourself) — از تکرار کد خودداری کنید. منطق تکراری را به روش‌ها یا کلاس‌های مشترک استخراج کنید. KISS (Keep It Simple, Stupid) — سادگی مهم‌تر از ظرافت است. YAGNI (You Aren't Gonna Need It) — کدی را برای چیزی که ممکن است نیاز نباشد ننویسید. این اصول به نوشتن کد تمیز، قابل نگهداری بدون افزونگی کمک می‌کنند.

الگوهای پلتفرم Android

ViewModel (Android) یک مؤلفه معماری Jetpack برای ذخیره وضعیت UI است، در برابر چرخش صفحه مقاوم است. ViewModel هیچ ارجاعی به Activity ندارد و به طور خودکار پاک می‌شود. LiveData — یک ظرف داده قابل مشاهده با آگاهی از چرخه حیات. StateFlow — جایگزین مدرن LiveData مبتنی بر Kotlin Flow. SharedFlow — یک Hot Flow برای رویدادهای یکبار مصرف (ناوبری، پیام‌ها).

Data Binding و Two-Way Binding — مکانیسم‌های اتصال UI و داده در Android. Data Binding اتصال را در XML اعلام می‌کند؛ Two-Way Binding به طور خودکار فیلد را در ViewModel به‌روز می‌کند. Unidirectional Data Flow — اصلی که داده‌ها در یک جهت جریان دارند: State → UI → Event → State. در IT Sectr، ما از Unidirectional Data Flow در تمام پروژه‌های جدید استفاده می‌کنیم — تعداد باگ‌های ناشی از تغییرات وضعیت غیرمنتظره را کاهش می‌دهد.