معرفی انواع دیزاین پترن‌‌های iOS

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

1) Cocoa (Apple’s) MVC

اولین دیزاین پترنی که می‌خوایم مورد بررسی قرار بدیم Cocoa (Apple’s) MVC ـه:

تو این الگو، اطلاعات بین لایه‌ها خوب پخش نشده و لایه‌ای مثل Controller خیلی شلوغ هستش و مسئولیت‌های زیادی گردنشه. در بین لایه‌ها (در بهترین حالت) لایه‌ی مدل قابل تست هستش. از بین الگو‌های ‌دیگه کد کمتری لازم داره، دولوپر‌های بیشتری می‌شناسنش و سرعت برنامه‌نویسی باهاش زیاده.

این الگو زمانی که آماده نیستیم بیشتر وقتمون رو برای معماری صرف کنیم و احساس می کنیم الگویی با هزینه نگهداری بالا یه هزینه سربار برای پروژه کوچکمون ایجاد می‌کنه کاربردی و جواب پس داده است.

2) MVP

دومین دیزاین پترن MVP ـه که توش کلی کد باید بنویسیم (تقریبا ۲ برابر MVC) اما قابلیت تست بیشتری داره چون لایه View که در اینجا یک زیرکلاس UIViewController هستش مسئول فقط و فقط View ـه (برخلاف MVC) و یک لایه میانی به اسم Presenter مسئول ارتباط Model و View ـه. لایه View در این الگو خیلی dumb ـه!

این الگو به‌خاطر همون به اصطلاح dumb بودن لایه View تقسیم وظیفه خوبی انجام می‌ده و تست کردن منطق تجاری (Business Logic) رو برای ما آسون می‌کنه اما کدی که باید برای پیاده‌سازیش زده شه تقریبا ۲ برابر MVC ـه.

3) MVVM

تو MVVM ما با live data سروکار داریم. یعنی چی؟ یعنی ما بجای Direct Callback، دیتا رو Observe می‌کنیم. با Notification ها، Event ها، سرور ریکوست‌ها با همه این‌ها مثل دیتا برخورد می‌کنیم که بصورت live تغییراتشون مشاهده (Observe) می‌شه.

تو این الگو، View Model فقط با Model سروکار مستقیم داره و آپدیت‌ها رو از اونجا می‌گیره یا به اون آپدیت می‌ده، پس View Model وابستگی به View نداره، که امکان تست رو بالا می‌بره و این Viewـه که بعد از آپدیت شدن دیتا توی View Model تغییر می‌کنه.

توی iOS ما از Binding ها برای Observe دیتا استفاده می‌کنیم که می‌تونیم از کتاب‌خونه‌های ساده‌تر استفاده کنیم مثل RZDataBinding یا SwiftBond یا از کتاب‌خونه‌های پیچیده‌تر مثل RxSwift و Reactive Cocoa استفاده کنیم.

این الگو از نظر تست‌پذیری (بجز لایه View) و تقسیم وظایف نسبت به مدل بالا بهتر عمل می‌کنه (به‌خاطر یک لایه بیشتر نسبت به MVP)، اما مقدار کدی که برای پیاده‌سازی این الگو باید زده شه تقریبا بیشتر و سنگین‌تر از مدل بالاست در حالت واقعی.

4) VIPER

همونطور که توی تصویر می‌بینید، VIPER مخفف شده کلاس‌های تصویر بالاست. کلاس View وظیفه نگه‌داری تمام کدی را در اختیار داره که Interface رو به کاربر نشون می‌ده. همچنین این کلاس وظیفه دریافت عملیات توسط کاربر بر روی View رو نیز در اختیار داره که موقع انجام عملیات Presenter رو با خبر می‌کنه. کلاس Presenter بیشتر نقش واسط رو در میون ماژول‌های دیگه بازی می‌کنه و مثلا با ماژول Router که وظیفه لود Segue صفحات مختلف رو داره در ارتباطه و بعد از دریافت نتیجه فراخوانی‌های API و دریافت اطلاعات، وظیفه آپدیت View رو نیز بر عهده داره. کلاس Interactor وظیفه هندل کردن منطق تجاری (Business Logic) برنامه و API Call ها رو بر عهده داره و با کلاس Entity که مدل‌های داده‌ای ما رو شامل می‌شه به صورت مستقیم در ارتباطه.

این الگو از نظر توزیع‌پذیری بهترین مدل‌های بالاست (به خاطر تعداد لایه‌های زیاد) و به خاطر این توزیع‌پذیری قابلیت تست بالایی رو هم داره، اما مقدار کدی که برای حتی کلاس‌هایی با وظیفه کم باید بنویسیم خیلی زیاده!

جمع‌بندی

من در این مقاله سعی کردم ۴ الگوی معماری بیشتر استفاده شده در iOS رو به شما معرفی کنم و امیدوارم بعد از خوندن این مقاله متوجه شده باشید که هیچ الگوی برتری وجود نداره، بنابراین انتخاب الگوی معماری موضوعی‌ـه که در شرایط خاص هر پروژه می‌تونه متفاوت باشه و این اصلا مشکلی نداره.

بنابراین، طبیعیه که ترکیبی از معماری‌ها و الگوها رو هم‌زمان تو یه برنامه داشته باشید. به عنوان مثال: شما با MVC شروع کردید، بعدا فهمیدید که حفظ کارآمدی یه صفحه خاص با MVC خیلی سخته و معماری اون صفحه رو تبدیل به MVVM کردین. در این صورت دیگه نیازی به refactor صفحه‌های دیگه که با MVC به خوبی کار می‌کنن نیست، چون هر دو دیزاین پترن سازگاری بالایی با هم دارن. در آخر: