طراحی سایت و برنامه نویسی

آموزش طراحی سایت و برنامه نویسی

طراحی سایت و برنامه نویسی

آموزش طراحی سایت و برنامه نویسی

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مدل‌ها

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

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

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

نماها

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

کنترلرها

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

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

MVC

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

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

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

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

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

معماری MVC

جمع‌بندی

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

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

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

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

منبع: فرادرس

عبارت های لامبدا در جاوا — راهنمای کاربردی

پیش از آنکه پشتیبانی از عبارت‌های لامبدا در نسخه JDK8 به جاوا اضافه شود، ما تنها در زبان‌هایی مانند #C و ++C از آن‌ها استفاده کرده بودیم. اینک که این قابلیت به جاوا اضافه شده است باید نگاهی دقیق‌تر به آن‌ها بیندازیم. اضافه شدن عبارت های لامبدا در جاوا موجب اضافه شدن عناصر ساختاری دیگری به این زبان شده است که توان بیان عبارت‌ها را در جاوا بالا برده است. در این مقاله می‌خواهیم روی مبانی مقدماتی که برای آغاز کار با عبارت‌های لامبدا در کدهای مدرن نیاز دارید تمرکز کنیم.

مقدمه

عبارت‌های لامبدا از مزیت ظرفیت‌های پردازش موازی محیط‌های چند نخی چنان که در پشتیبانی از عملیات pipeline روی داده‌ها در API Stream دیده‌ایم استفاده می‌کنند. برخی متدهای بی‌نام وجود دارند که برای پیاده‌سازی متد تعریف شده از سوی یک اینترفیس تابعی استفاده می‌شوند. پیش از آشنا شدن با عبارت‌های لامبدا باید با مفهوم اینترفیس تابعی آشنا شوید.

اینترفیس‌های تابعی

اینترفیس تابعی اینترفیسی است که شامل یک و تنها یک متد مجرد است. اگر نگاهی به تعریف اینترفیس Runnable استاندارد جاوا بکنید، متوجه خواهید شد که در تعریف اینترفیس تابعی قرار می‌گیرد، زیرا تنها یک متد یعنی ()run را تعریف می‌کند. در قطعه کد نمونه زیر متد computeName به صراحت مجرد است و تنها متد تعریف شده است که موجب می‌شود MyName یک اینترفیس تابعی باشد.

عملگر arrow

عبارت‌های لامبدا عملگر جدید arrow را به صورت (<-) در جاوا معرفی کرده‌اند. و این عملگر عبارت لامبدا را به دو بخش تقسیم می‌کند:

(n) -> n*n

سمت چپ پارامترهای مورد نیاز عبارت را تعیین می‌کند که در صورت عدم نیاز به پارامتر می‌تواند خالی هم باشد. سمت راست بدنه لامبدا است که اقدامات عبارت لامبدا را تعیین می‌کند. این عملگر را می‌توان به صورت «تبدیل می‌شود» ترجمه کرد. برای نمونه در مثال فوق «n تبدیل می‌شود به n*n» یا «n تبدیل می‌شود به جذر n.» با استفاده از اینترفیس تابعی و عملگر arrow می‌توانید یک عبارت لامبدای ساده را کنار هم قرار دهید:

لامبدای خوش‌ آمدگویی

متغیرهای morningGreeting و eveningGreeting در خطوط 6 و 7 فوق ارجاعی به اینترفیس MyGreeting دارند و عبارت‌های خوشامدگویی مختلفی را تعریف می‌کنند. زمانی که یک عبارت لامبدا می‌نویسیم امکان تعیین صریح نوع پارامتر در عبارت به صورت زیر نیز وجود دارد:

عبارت‌های لامبدای بلوکی

تا به اینجا، نمونه‌هایی از لامبداهای عبارت منفرد را مورد بررسی قرار دادیم. نوع دیگری از عبارت نیز وجود دارد که هنگامی استفاده می‌شود که کد سمت راست عملگر arrow شامل بیش از یک گزاره باشد که به نام «لامبدای بلوکی» (block lambdas) شناخته می‌شود:

اینترفیس‌های تابعی ژنریک

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

عبارت های لامبدا در جاوا

عبارت لامبدا به عنوان آرگومان

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

سخن پایانی

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

منبع: فرادرس