تکنیک های برنامه نویسی ناهمزمان

برای ده ها سال ، به عنوان توسعه دهندگان ، ما برای حل آنها با مشکلی روبرو هستیم - چگونه می توان از مسدود شدن برنامه های ما جلوگیری کرد. این که آیا ما در حال توسعه برنامه های دسک تاپ ، موبایل و یا حتی برنامه های سمت سرور هستیم ، می خواهیم از انتظار کاربر جلوگیری کنیم یا چه چیزی باعث ایجاد تنگنا هایی می شود که مانع از مقیاس بندی کاربرد می شود.

رویکردهای زیادی برای حل این مشکل وجود داشته است ، از جمله:

• نخ دار
• تماس تلفنی
• آینده ، وعده ها و دیگران
• پسوندهای واکنشی
• قیافه

قبل از اینکه توضیح دهیم Coroutines چیست ، بیایید به طور خلاصه برخی از راه حل های دیگر را مرور کنیم.

نخ دار

موضوعات احتمالاً مشهورترین روش برای جلوگیری از مسدود شدن برنامه ها هستند.

PostItem سرگرم کننده (مورد: مورد)آماده سازی سرگرم کننده (): توکن

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

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

تماس تلفنی

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

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

• دشواری در تماس های تو در تو در تو. معمولاً تابعی که به عنوان پاسخ به تماس استفاده می شود ، اغلب به پاسخ به تماس با خود نیاز دارد. این منجر به مجموعه ای از تماس های تو در تو می شود که منجر به کد غیرقابل درک می شود. این الگوی اغلب به عنوان درخت کریسمس تحت عنوان گفته می شود (بریس ها شاخه های درخت را نشان می دهند).
• رسیدگی به خطا پیچیده است. مدل لانه سازی باعث ایجاد خطا و انتشار این موارد تا حدودی پیچیده تر می شود.

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

آینده ، وعده ها و دیگران

ایده آینده یا وعده ها (اصطلاحات دیگری نیز وجود دارد که بسته به زبان/پلتفرم به آنها می توان اشاره کرد) ، این است که وقتی ما یک تماس برقرار می کنیم ، به ما قول داده می شود که در بعضی مواقع با یک شیء به نام وعده بازگردد. که پس از آن می توان روی آن کار کرد.

این رویکرد به ویژه در نحوه برنامه ریزی ما به مجموعه ای از تغییرات نیاز دارد:

• مدل برنامه نویسی مختلف. مشابه تماس با تماس ، مدل برنامه نویسی از یک رویکرد ضروری از بالا به پایین به یک مدل ترکیبی با تماس های زنجیره ای دور می شود. ساختارهای برنامه سنتی مانند حلقه ها ، استفاده از استثناء و غیره معمولاً در این مدل دیگر معتبر نیستند.
• API های مختلف. معمولاً نیاز به یادگیری یک API کاملاً جدید مانند Thencompose یا TheneCcept وجود دارد ، که می تواند در سیستم عامل ها نیز متفاوت باشد.
• نوع بازگشت خاصنوع بازگشت از داده های واقعی مورد نیاز ما دور می شود و در عوض قول نوع جدیدی را برمی گرداند که باید درونگرا باشد.
• رسیدگی به خطا می تواند پیچیده باشد. انتشار و زنجیره ای خطاها همیشه ساده نیست.

پسوندهای واکنشی

پسوندهای واکنشی (RX) توسط Erik Meijer به C# معرفی شد. در حالی که قطعاً در سکوی . NET استفاده می شد ، واقعاً به اتخاذ جریان اصلی نرسید تا اینکه نتفلیکس آن را به جاوا منتقل کرد و نام آن را rxjava نامید. از آن زمان به بعد ، بنادر بی شماری برای انواع سیستم عامل از جمله JavaScript (RXJS) ارائه شده است.

ایده پشت RX این است که به سمت آنچه که جریان های قابل مشاهده نامیده می شود حرکت کند که به موجب آن اکنون داده ها را به عنوان جریان (مقدار نامحدود داده) فکر می کنیم و این جریان ها را می توان مشاهده کرد. از نظر عملی ، Rx به سادگی الگوی ناظر با یک سری پسوندها است که به ما امکان می دهد روی داده ها کار کنیم.

در این رویکرد کاملاً شبیه به آینده است ، اما می توان آینده ای را به عنوان بازگشت یک عنصر گسسته فکر کرد ، در حالی که RX یک جریان را برمی گرداند. با این حال ، مشابه موارد قبلی ، همچنین یک روش جدید برای تفکر در مورد مدل برنامه نویسی ما ، معروف به عنوان ارائه می دهد

"همه چیز یک جریان است ، و قابل مشاهده است"

این به معنای روش متفاوتی برای نزدیک شدن به مشکلات و تغییر قابل توجهی از آنچه در هنگام نوشتن کد همزمان استفاده می کنیم ، است. یک مزیت بر خلاف آینده این است که با توجه به اینکه به بسیاری از سیستم عامل ها منتقل می شود ، به طور کلی می توانیم یک تجربه API سازگار را بدون توجه به آنچه که ما استفاده می کنیم ، پیدا کنیم ، چه C#، Java ، JavaScript یا هر زبان دیگری که RX در دسترس است.

علاوه بر این ، RX یک رویکرد تا حدودی بهتر برای رسیدگی به خطا معرفی می کند.

قیافه

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

یکی از مزایای Coroutines این است که وقتی صحبت از توسعه دهنده می شود ، نوشتن کد غیر مسدود کننده اساساً همان نوشتن کد مسدود کننده است. مدل برنامه نویسی به خودی خود تغییر نمی کند.

به عنوان مثال کد زیر را در نظر بگیرید:

PostItem سرگرم کننده (مورد: مورد)>آماده سازی سرگرم کننده (): توکن>

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

• امضای عملکرد دقیقاً یکسان است. تنها تفاوت تعلیق به آن اضافه شده است. نوع بازگشت با این حال نوعی است که می خواهیم برگردیم.
• این کد هنوز هم به گونه ای نوشته شده است که گویی ما در حال نوشتن کد همزمان ، از بالا به پایین ، بدون نیاز به نحوی خاص ، فراتر از استفاده از عملکردی به نام پرتاب است که اساساً Coroutine (تحت پوشش سایر آموزش ها) را آغاز می کند.
• مدل برنامه نویسی و API ها یکسان هستند. ما می توانیم به استفاده از حلقه ها ، استفاده از استثناء و غیره ادامه دهیم و نیازی به یادگیری مجموعه کاملی از API های جدید نیست.
• این بستر مستقل است. این که آیا ما JVM ، JavaScript یا هر بستر دیگری را هدف قرار می دهیم ، کدی که می نویسیم یکسان است. در زیر پوشش ، کامپایلر از تطبیق آن با هر سیستم عامل مراقبت می کند.

Coroutines یک مفهوم جدید نیست ، چه رسد به اختراع Kotlin. آنها ده ها سال است که وجود دارد و در برخی از زبان های برنامه نویسی دیگر مانند Go محبوبیت دارند. نکته قابل توجه این است که نحوه اجرای آنها در کوتلین ، بیشتر عملکردها به کتابخانه ها واگذار می شود. در حقیقت ، فراتر از کلمه کلیدی معلق ، هیچ کلمه کلیدی دیگری به زبان اضافه نمی شود. این تا حدودی با زبانهایی مانند C# که دارای مجوز هستند و به عنوان بخشی از نحو در انتظار هستند متفاوت است. با کوتلین ، اینها فقط عملکردهای کتابخانه ای هستند.

برای اطلاعات بیشتر ، به مرجع Coroutines مراجعه کنید.