آموزش سوئیفت (Swift): معماری MVC — بخش هجدهم

این بخش هجدهم و پایانی سری مقالات آموزش زبان سوئیفت مجله فرادرس محسوب می‌شود. شما با مطالعه هفده بخش قبلی این سری مقالات آموزش زبان برنامه‌نویسی سوئیفت با مبانی آن آشنا شدید. اینک و با مطالعه این بخش با موضوع معماری MVC می‌توانید شروع به نوشتن عملی اپلیکیشن‌های خود بکنید. در بخش قبلی این سری مقالات در مورد نوشتن تست صحبت کردیم. برای مطالعه آن به لینک زیر مراجعه کنید:

آموزش سوئیفت (Swift): نوشتن تست — بخش هفدهم

اینک باید چند سؤال از خود بپرسید:

1. آنچه را تا به اینجا آموخته‌ایم، چگونه برای ساخت یک اپلیکیشن پیاده‌سازی کنیم؟
2. در گام بعدی چه چیزی باید بیاموزیم؟
3. شرکت الف به دنبال یک توسعه‌دهنده متوسط Swift است و من به تازگی آن را آموخته‌ام، آیا می‌توانم برای تصاحب این شغل اقدام کنم؟

ما در این مقاله به دو سؤال نخست پاسخ می‌دهیم. این مقاله به این منظور نوشته شده است که شیوه استفاده مؤثر از معماری MVC را به شما آموزش دهد. MVC اختصاری برای عبارت «مدل، نما، کنترلر» (Model-View-Controller) است. از ساختار MVC در فناوری‌های مختلف استفاده می‌شود. به عنوان مثال، PHP MVC چارچوب رایجی در توسعه کاربردهای وب به شمار می‌رود.

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

اگر به تازگی وارد دنیای برنامه‌نویسی شده‌اید و این نخستین راهنمایی است که مطالعه کرده‌اید شما نباید برای این جایگاه شغلی اقدام کنید. حتی اگر این شغل را به دست بیاورید هم، آن‌ها از شما چیزهایی خواهند خواست که هنوز نیاموخته‌اید و این فرایند دشواری خواهد بود. مثلاً ممکن است از شما خواسته شود «داده‌هایی را از یک URL دانلود کنید، پاسخ JSON را تحلیل کنید، سپس آن را در فایل plist ذخیره کرده و در قالب مورد نظر عرضه کنید.» بنابراین بهتر است اقدام به درخواست این شغل نکنید.

نکته دیگری که باید اشاره کنیم این است که گرچه وب‌سایت‌هایی مانند HackerRank و CodeWars وجود دارند که به ارتقای مهارت‌های برنامه‌نویسی کمک می‌کنند، اما تمرکز اولیه آن‌ها پیرامون الگوریتم‌ها است. البته هیچ اشکالی در کار این وب‌سایت‌ها نیست، اما فکر کنید آخرین باری که نیازمند استفاده از الگوریتم اقلیدسی برای انجام تکالیف خود بودید چه زمانی بوده است، همچنین خواندن فایل، تحلیل نتایج یک پاسخ وب و کارهای دیگر نیز به همین منوال است.

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

مدل، نما، کنترلر

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

فیلم آموزش برنامه نویسی سوئیفت – برنامه نویسی iOS با Swift در فرادرس

کلیک کنید

بنابراین در این بخش در مورد این معماری صحبت می‌کنیم. زمانی که کلمه معماری را می‌شنوید به احتمال زیاد به یاد ساختمان‌ها و پل‌ها می‌افتید که البته آن معنایی نیست که در دنیای برنامه‌نویسی دارد.

معماری یک اپلیکیشن تنها ساختار پوشه پروژه را تعریف نمی‌کند، بلکه شیوه تعامل هر کلاس با کلاس‌ها و ماژول‌های دیگر را نیز تعریف می‌کند. برای نمونه ممکن است لازم باشد که به یک کلاس بازیابی فایل اجازه دهیم با کلاس‌هایی کار کند که داده‌های درون فایل‌ها را دستکاری می‌کنند. اما این وضعیت شاید برای کلاس دستکاری داده‌ها که با کلاس‌هایی کار می‌کند که مسئول طراحی رابط کاربری (UI) هستند مناسب نباشد، چون میزان جدایی آن‌ها زیاد است.

ایده نهفته در پس این معماری این است که نهادهای مختلف باید تنها در معرض دید چند عنصر معدود پیرامون خود باشند. نماها باید تنها مسئول کار با UI باشند، مدل‌ها باید تنها مسئول ذخیره‌سازی، قالب‌بندی و بازیابی داده‌ها باشند و کنترلرها نیز صرفاً باید مسئول مسیریابی داده‌ها از مدل به نما باشند.

اغلب افراد به این بخش از توضیح معماری MVC که می‌رسند به ارائه یک تصویر متوسل می‌شوند اما ما چنین قصدی نداریم. ما قصد داریم هر بخش را با ارائه یک مثال توضیح دهیم و سپس تصویر را در انتها نمایش دهیم.

مدل‌ها

مدل‌ها اساس کلاس‌ها و سازه‌هایی پر از مشخصه و متد هستند که برای ذخیره، قالب‌بندی و بازیابی داده‌های برنامه استفاده می‌شوند. زمانی که به یک مدل فکر می‌کنید، باید آن را به صورت یک رکورد منفرد در پایگاه داده تصور کنید. در ادامه مثالی از یک مدل را می‌بینید:

1struct PhoneBookEntry {
2    var name: String
3    var address1: String
4    var address2: String
5    var city: String
6    var state: String
7    var zip: Int
8    var zip4: Int // stores the last 4 numbers after the '-'
9    var phone: Int
10  
11    func getFormattedPhoneNumber() -> String {
12        // Returns number in (123) 456-7890 format.
13        var formattedPhone = phone
14        formattedPhone.insert('(', at: 0)
15        formattedPhone.insert(')', at: 4)
16        formattedPhone.insert(' ', at: 5)
17        formattedPhone.insert('-', at: 9)
18        return formattedPhone
19    }
20}

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

شما می‌توانید این مدخل را بردارید، آن را به یک آرایه از مدخل در کلاس دیگر PhoneBook در یک فایل دیگر اضافه کنید. جای نگرانی نیست چون تا زمانی که خصوصیت دسترسی مناسبی تنظیم کرده باشید، می‌توانید از این کلاس در فایل‌های دیگر استفاده کنید به طوری که گویی در همان فایل قرار دارد.

نماها

«نماها» (Views) برای نگهداری منطقی که داده‌ها روی صفحه نمایش می‌دهند مورد استفاده قرار می‌گیرند. این منطق می‌تواند یک شکل رسم شده خاص، یک سلول نمای جدولی سفارشی یا یک ظاهر دکمه سفارشی باشد. این همان کدی است که منطق رسم و خروجی (IBOutlet) مورد استفاده از سوی نما را نگهداری می‌کند. به طور معمول، نماها زیرکلاس‌هایی از IView ،UITableViewCell یا UIButton هستند، اما می‌توانند هر چیزی باشند که صرفاً برای نمایش اشیا روی صفحه استفاده می‌شوند.

کنترلرها

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

کنترلرها در iOS به وسیله پسوند ViewController مشخص می‌شوند. بدین ترتیب SearchViewController یک کنترلر و SearchView یک نما و Items می‌تواند یک مدل باشد.

MVC

اگر به مثال دفترچه تلفن بازگردیم، می‌بینیم که دفترچه تلفنی به عنوان مدل خود داریم. این دفترچه تلفن شامل آرایه‌ای از مدخل‌ها است. کنترل ما می‌تواند مسئول اعلان کردن وهله‌سازی از دفترچه تلفن و واکشی داده‌ها از مدخل دفترچه تلفن باشد که نما به آن نیاز دارد. پس از این که داده‌ها بازیابی شدند، می‌توانیم خروجی‌ها را درون نما مقداردهی کرده و نما را عرضه کنیم. اگر کاربر شماره تلفن فردی را تغییر دهد، نما به کنترل اطلاع می‌دهد و کنترلر اقدام به مدیریت ارسال داده‌ها به مدل از طریق فراخوانی یکی از متدهای به‌روزرسانی و ارسال داده‌های تغییریافته به آن می‌کند.

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

تنها مقصود نما، نمایش اطلاعات به کاربر است و از این رو نماهای iOS کاملاً ساده هستند. این نماها از چیزی خارج از حوزه نمایش UI و اطلاع‌رسانی به کنترلر بی‌اطلاع هستند.

کارکرد مدل تا حدود زیادی شبیه به منشی است و صرفاً داده‌ها را منظم حفظ می‌کند. مدل وظیفه مهم نگهداری داده‌ها را بر عهده دارد. مدل‌ها الزاماً به ذخیره‌سازی داده‌ها نمی‌پردازند، بلکه ارجاعی برای ارائه قالب‌بندی داده‌ها ارائه می‌کند که در پایگاه داده ذخیره می‌شوند.

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

جمع‌بندی

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

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

شما باید معماری را بر مبنای نوع اپلیکیشن انتخاب کنید. نباید بگویید من می‌خواهیم این اپلیکیشن را با معماری فلان بنویسم. زمانی که افراد چنین چیزی را می‌گویند خود را به زحمت می‌اندازند، چون در اغلب موارد اپلیکیشن آن‌ها به چیزی بیش از MVC نیاز ندارد. این بدان معنی نیست که باید گزینه‌های دیگر را کلاً کنار بگذاریم، بلکه منظور ما این است که در آغاز از MVC برای بررسی طرز کار اپلیکیشن خود استفاده کنید و سپس اگر دیدید نمی‌توانید پاسخ مناسبی دریافت کنید و حجم بیشتر کار به مزیت‌هایی که ارائه می‌کرد می‌ارزید، از معماری‌های پیچیده‌تر استفاده کنید.

بدین ترتیب به پایان این سری مقالات آموزش سوئیفت می‌رسیم. اما شما فرایند یادگیری خود را متوقف نکنید، و تلاش کنید از منابع دیگر برای آموزش موارد بیشتر کمک بگیرید.

اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

• مجموعه آموزش‌های برنامه‌‌نویسی
• آموزش برنامه نویسی Swift (سوئیفت) برای برنامه نویسی iOS
• مجموعه آموزش‌های دروس علوم و مهندسی کامپیوتر
• آموزش برنامه نویسی سوئیفت (Swift): تصمیم‌ گیری و حلقه‌ ها — بخش چهارم
• آموزش کامل MVC در PHP — از صفر تا صد و به زبان ساده

==