برنامه نویسی واکنشی

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

به عنوان مثال ، در یک برنامه‌نویسی دستوری *،* a := b + c به این معنی است که حاصل b + c  در همان لحظه‌ی محاسبه عبارت به  a اختصاص داده میشود و بعداً مقادیر b و c را می توان بدون هیچ تاثیری بر مقدار a تغییر داد  . از طرف دیگر ، در برنامه نویسی *واکنشی ،* هر زمان که مقادیر b یا c تغییر کند مقدار a به صورت خودکار تغییر میکند ، بدون اینکه برنامه مجبور به اجرای دوباره‌ی جداگانه دستور  a := b + c باشد تا بتواند مقدار کنونی مقدار a را بدست آورد.
```
var b = 1
var c = 2
var a = b + c
b = 10
console.log (a) // 3 (حاصل ۱۲ نیست زیرا عملگر "=" یک عملگر واکنشی انتصابی نیست)

// اکنون تصور کنید که یک عملگر ویژه "$ =" دارید که مقدار یک متغیر را تغییر می دهد (کد را در سمت راست اپراتور اجرا می کند و نتیجه را به متغیر سمت چپ اختصاص می دهد) نه تنها در زمان اجرای اولیه ، بلکه همچنین زمانی که متغییر های ارجاع شده(در سمت راست عملگر) تغییر می کنند.
var b = 1
var c = 2
var a $ = b + c
b = 10
console.log (a) // 12
```
مثال دیگر ، زبان توصیف سخت افزار مانند Verilog است ، جایی که برنامه نویسی واکنشی باعث می شود تغییرات هنگام انتشار از طریق مدارها مدل شوند.

برنامه نویسی واکنشی به عنوان روشی برای ساده سازی ایجاد رابط های کاربری  و انیمیشن تقریباً بلا درنگ پیشنهاد شده است.

به عنوان مثال ، در مدل-نما-کنترل‌گر (MVC) ، برنامه نویسی واکنشی می تواند تغییرات در  *مدل* زیرین را به صورت خودکار در رابط گرافیکی مرتبط منعکس کند. 

## رویکردهای ایجاد زبانهای برنامه نویسی واکنشی
چندین روش محبوب در ایجاد زبان‌های برنامه‌نویسی واکنشی به کار گرفته شده‌اند. مشخصات زبان‌های اختصاصی که مختص محدودیت‌های دامنه مختلف هستند. چنین محدودیت‌هایی معمولاً به شکل بلادرنگ ،محاسبات تعبیه‌شده یا توصیف سخت‌افزار مشخص می‌شوند. رویکرد دیگر شامل توصیف زبان‌های هدف عمومی است که شامل پشتیبانی از واکنش‌پذیری است. رویکردهای دیگر در تعریف، و استفاده از کتابخانه‌های برنامه‌نویسی، یا زبان‌های خاص دامنه تعبیه‌شده، که امکان واکنش‌پذیری در کنار یا روی زبان برنامه‌نویسی را فراهم می‌کنند، بیان می‌شوند. مشخصات و استفاده از این رویکردهای مختلف منجر به تبادل قابلیت زبان می‌شود. به طور کلی، هر چه یک زبان محدودتر باشد، کامپایلرهای مرتبط و ابزارهای تجزیه و تحلیل آن بیشتر قادر به اطلاع‌رسانی به توسعه دهندگان هستند (به عنوان مثال، در انجام تجزیه و تحلیل برای اینکه آیا برنامه‌ها قادر به اجرا در زمان واقعی هستند یا خیر). تبادل عملکردی در ویژگی ممکن است منجر به بدتر شدن کاربرد کلی یک زبان شود. ​

## مدل های برنامه نویسی و معناشناسی
برنامه نویسی واکنشی مفاهیم و  انواع مختلفی دارد که می توانیم آنها را به موراد  زیر تقسیم کنیم:
* همزمانی: آیا مدل اساسی زمان همزمان است یا  ناهمزمان ؟
* جبرگرایی: قطعیت در برابر عدم قطعیت در فرایند ارزیابی و نتایج
* فرایند به روزرسانی: بازخوانی در مقابل جریان داده در مقابل بازیگر

## تکنیک ها و چالش های پیاده سازی

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

#### تغییر الگوریتم های انتشار
متداول ترین روش های انتشار داده :
* **Pull** : مصرف کننده مقدار (value consumer) در واقع *فعال است* ، یعنی به طور منظم منبع مشاهده شده را برای مقادیر جستجو می کند و هر زمان که مقدار مربوطه در دسترس باشد ، واکنش نشان می دهد. به این روش  بررسی منظم رویدادها یا تغییرات مقادیر معمولاً  *نظرسنجی* گفته می شود.
* **Push** : مصرف کننده مقدار هر زمان که مقدار در دسترس قرار بگیرد  مقداری را از منبع دریافت می کند. این مقادیر خود به خود به دست می‌آیند ، به عنوان مثال حاوی تمام اطلاعات لازم هستند و نیازی نیست اطلاعات بیشتری توسط مصرف‌کننده اضافه شود.
* **Push-pull** : مصرف کننده مقدار *اعلان تغییر را* دریافت می کند ، که شرح مختصری از تغییر است ، به عنوان مثال "بعضی ار مقادیر  تغییر کردند" - این قسمت *فشار(push) است* . با این حال ،  این اعلان شامل تمام اطلاعات لازم نیست (یعنی مقادیر حقیقی را ندارد) ، بنابراین مصرف کننده باید پس از دریافت اعلان ، برای اطلاعات بیشتر (مقدار خاص) منبع را جستجو کند - این قسمت *کشش(pull) است* . این روش معمولاً هنگامی استفاده می شود که حجم زیادی از داده ها وجود داشته باشد که مصرف کنندگان ممکن است به آن علاقه‌مند باشند. بنابراین برای کاهش توان عملیاتی و  تأخیر ، فقط اعلان های سبک ارسال می شوند. و سپس آن دسته از مصرف کنندگانی که به اطلاعات بیشتری نیاز دارند ، آن اطلاعات خاص را درخواست می کنند. اشکال این روش این است که ممکن است پس از ارسال یک اعلان ، توسط بسیاری از درخواست ها برای  اطلاعات اضافی منبع بمباران شود.

##### چه زمانی از push استفاده کنیم ؟
در سطح پیاده سازی ، *واکنش رویداد* شامل انتشار از طریق اطلاعات نمودار است که نشان دهنده  وجود تغییر است. در نتیجه ، محاسباتی که تحت تأثیر چنین تغییری قرار می گیرند منسوخ می شوند و باید برای اجرای مجدد مشخص شوند. چنین محاسباتی معمولاً با بسته شدن انتقالی تغییر در منبع مرتبط آن مشخص می شود. *سپس انتشار تغییر* ممکن است منجر به بروزرسانی مقدار نشست نمودار شود.

اطلاعات منتشر شده از نمودار می تواند تشکیل شده از حالت کامل یک گره باشد ، یعنی نتیجه محاسبات گره درگیر. در این حالت ، خروجی قبلی گره نادیده گرفته می شود. یک روش دیگر شامل *تکثیر دلتا* یعنی *تکثیر تغییر فزاینده است* . در این حالت ، اطلاعات در امتداد *لبه های* نمودار تکثیر می شوند ، که فقط شامل *دلتا هستند* و نحوه تغییر گره قبلی را توصیف می کنند. این رویکرد به ویژه هنگامی مهم است که *گره ها* مقدار زیادی از *داده های حالت(state data) را در خود* نگه می دارند که در غیر اینصورت هزینه محاسبه  مجدد آنها از ابتدا گران خواهد بود.

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

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

*در ساخت نمودار وابستگی* دو روش اصلی وجود دارد:
# نمودار وابستگی ها به طور ضمنی در یک *حلقه رویداد* حفظ می شود. ثبت بازخوانی های واضح ، سپس منجر به ایجاد وابستگی های ضمنی می شود. بنابراین ، *وارونگی کنترل* که از طریق بازخوانی ایجاد می شود ، در جای خود رها می شود. با این حال ، عملی ساختن بازخوانی ها (به عنوان مثال بازگرداندن مقدار حالت به جای مقدار واحد) ، ضروری است که این بازخوانی ها ترکیب شوند.
# نمودار وابستگی  برای هر برنامه خاص است  و توسط یک برنامه نویس تولید می شود. این کار آدرس دهی به *وارونگی کنترل بازخوانی* به دو روش را تسهیل می کند: یا یک نمودار به *طور صریح* مشخص شده است (معمولاً با استفاده از یک *[[زبان خاص دامنه]]* (DSL) ، که ممکن است تعبیه شده باشد) ، یا نمودار به طور ضمنی با بیان و تولید با استفاده از یک زبان کهن الگوی موثر و تعریف شده است.

### چالش های پیاده سازی در برنامه نویسی واکنشی

#### اشکالات (Glitches)
هنگام تکثیر تغییرات ، می توان دستورات تکثیر را به طوری  انتخاب کرد که مقدار یک عبارت نتیجه طبیعی برنامه منبع نباشد. ما می توانیم این مسئله را با یک مثال به راحتی نشان دهیم. فرض کنید `seconds`  یک مقدار واکنشی است که هر ثانیه تغییر می کند تا زمان فعلی را نشان دهد (در واحد ثانیه). این عبارت را در نظر بگیرید:
```
t = seconds + 1
g = (t> seconds)
```

بندانگشتی
چون `t` باید همیشه بزرگتر از `seconds` ، این عبارت باید همیشه با مقدارtrue  ارزیابی شود. متأسفانه ، این می تواند به ترتیب ارزیابی بستگی داشته باشد. ,وقتی `seconds` نغییر میکند ، دو عبارت باید به روز شوند: `seconds + 1` و شرط. اگر  مورد اول قبل از مورد دوم ارزیابی شود ، این  نامتغیرثابت باقی خواهد ماند. اگر ، ابتدا شرط با استفاده از مقدار قدیمی `t` و مقدار جدید `seconds` ، ابتدا به روز شود ، این عبارت به یک مقدار نادرست ارزیابی می شود. به این *اشکال(Glitch) گفته می شود* .

برخی از زبانهای واکنشی بدون اشکال هستند و این ویژگی را اثبات می کنند این امر معمولاً با مرتب سازی توپولوژیکی عبارات و به روزرسانی مقادیر به ترتیب توپولوژیکی حاصل می شود. با این حال ، این می تواند پیامدهای عملکردی مانند تأخیر در تحویل مقادیر (به دلیل ترتیب انتشار) داشته باشد. بنابراین ، در بعضی موارد ، زبانهای واکنشی اشکالات را مجاز می دانند و توسعه دهندگان باید از این احتمال که ممکن است مقادیر به طور موقت با منبع برنامه مطابقت نداشته باشند آگاه باشند و برخی عبارات ممکن است چندین بار ارزیابی شوند (به عنوان مثال `t> seconds` ممکن است دو بار ارزیابی شود: یک بار با رسیدن مقدار جدید `seconds` ، و یک بار دیگر `t` به روزرسانی t).

#### وابستگی های چرخه ای
مرتب سازی توپولوژیکی وابستگی ها به  نمودار دایره ای چرخشی (DAG) بودن نمودار وابستگی بستگی دارد. در عمل ، یک برنامه ممکن است یک نمودار وابستگی تعریف کند که دارای چرخه باشد. معمولاً ، زبانهای برنامه نویسی واکنشی با قرار دادن مقداری عنصر در امتداد "لبه پشتی" انتظار دارند چنین چرخه هایی "شکسته شود" تا اجازه دهد به روزرسانی واکنشی خاتمه یابد. به طور معمول ، زبان ها عملیاتی مانند `delay` ارائه می دهند که توسط مکانیزم  به روزرسانی برای این منظور استفاده می شود ، زیرا `delay` بیانگر این است که مواردی که در ادامه مطرح میشود باید در "مرحله بعدی" ارزیابی شوند ( و اجازه می دهد ارزیابی فعلی خاتمه یابد).

#### تعامل با حالت تغییر پذیر
زبانهای واکنشی معمولاً فرض می کنند که عبارات آنها کاملاً کاربردی هستند . این به یک مکانیزم بروزرسانی اجازه می دهد تا سفارشات مختلفی را که برای انجام آنها به روز می شود انتخاب کند و سفارش خاص را بدون مشخص بگذارد (در نتیجه امکان بهینه سازی را فراهم می کند). با این وجود ، هنگامی که یک زبان واکنشی در یک زبان برنامه نویسی با حالت تعبیه شده است ، انجام برنامه های تغییر پذیر برای برنامه نویسان امکان پذیر است. نحوه بهبود این تعامل مشکلی است که همچنان حل نشده است. 

در بعضی موارد ، ممکن است راه حل های جزئی اصولی وجود داشته باشد. دو راه حل از این دست عبارتند از:
* یک زبان ممکن است مفهوم "سلول قابل تغییر" را ارائه دهد. یک سلول قابل تغییر ، سلولی است که سیستم بروزرسانی واکنشی از آن آگاه است ، بنابراین تغییرات ایجاد شده در سلول به بقیه برنامه واکنشی گسترش می یابد. این بخش غیر واکنشی برنامه را قادر می سازد تا جهش سنتی انجام دهد در حالی که کد واکنشی را قادر می سازد تا از این به روزرسانی آگاه و پاسخ دهد ، بنابراین ثبات رابطه بین مقادیر موجود در برنامه را حفظ می کند. مثالی از یک زبان واکنشی که چنین سلول را فراهم می کند FrTime است. 
* کتابخانه های شی گرا به درستی محصور شده ، مفهوم حالت محصور شده ای را ارائه می دهند. در تئوری ، بنابراین برای چنین کتابخانه ای امکان تعامل روان با بخش واکنش دهنده یک زبان وجود دارد. به عنوان مثال ، می توان تماس گیرنده ها را در گیرنده های کتابخانه شی گرا نصب کرد تا به موتور به روزرسانی راکتیو درباره تغییرات وضعیت اطلاع داده شود و تغییرات در جز component واکنش پذیر را می توان از طریق گیرنده ها به کتابخانه شی گرا هدایت کرد. FrTime از چنین استراتژی استفاده می کند. 

#### به روز رسانی پویا نمودار وابستگی ها
در برخی از زبانهای واکنشی ، نمودار وابستگی ها *ثابت است* ، یعنی نمودار در طول اجرای برنامه ثابت است. در زبان های دیگر ، نمودار می تواند *پویا باشد* ، یعنی با اجرای برنامه می تواند تغییر کند. برای یک مثال ساده ، این مثال گویا را در نظر بگیرید (جایی که `seconds` مقدار واکنشی است):
```
t =
  if ((seconds mod 2) == 0):
    seconds + 1
  else:
    seconds - 1
  end
t + 1
```
در هر ثانیه ، مقدار این عبارت به یک عبارت واکنشی متفاوت تغییر می کند که `t + 1` به آن بستگی دارد. بنابراین نمودار وابستگی ها در هر ثانیه به روز می شود.

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

## مفاهیم

### درجات صراحت
زبانهای برنامه نویسی واکنشی می توانند از زبانهای کاملاً واضح که جریانهای داده با استفاده از فلش (arrow)  تنظیم می شوند ، تا  در جایی که جریان داده ها از سازه های زبان که شبیه برنامه های ضروری یا کاربردی است ، متغیر باشند. به عنوان مثال ، در یک برنامه نویسی واکنش پذیر عملکردی (FRP) که به طور ضمنی لیفت شده است ، یک فراخوانی تابع ممکن است به طور ضمنی باعث ایجاد یک گره در نمودار جریان داده شود. کتابخانه های برنامه نویسی واکنشی برای زبانهای پویا (مانند کتابخانه های "Lisp" Cells و Python "Trellis") می توانند یک نمودار وابستگی از تجزیه و تحلیل زمان اجرا از مقادیر خوانده شده در هنگام اجرای یک تابع ایجاد کنند ، که به مشخصات جریان داده اجازه می دهد تا بصورت  و پویا باشند.

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

### ایستا یا پویا
برنامه نویسی واکنشی می تواند کاملاً ایستا باشد در جایی که جریان داده ها به صورت استاتیک تنظیم شده باشد ، یا در جایی که جریان داده می تواند در حین اجرای یک برنامه تغییر کند ، پویا باشد.

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

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

### تمایز جریان داده
در حالت ایده‌آل ، همه تغییرات داده بلافاصله منتشر می شوند ، اما در عمل نمی توان به این امر اطمینان داشت. در عوض ممکن است لازم باشد که به بخشهای مختلف نمودار جریان داده ، اولویتهای ارزیابی متفاوتی داده شود. این را می توان **برنامه نویسی واکنشی متمایز** نامید. 

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

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

### مدل های ارزیابی برنامه نویسی واکنشی
ارزیابی برنامه های واکنشی لزوماً براساس چگونگی ارزیابی زبان های برنامه نویسی مبتنی بر پشته نیست. در عوض ، هنگامی که برخی از داده ها تغییر می کنند ، تغییر به تمام داده هایی که از داده هایی که تغییر داده شده اند به طور جزئی یا کامل استخراج می شوند ، انتشار می یابد. این تکثیر تغییر را می توان از راه های مختلفی به دست آورد ،  که شاید طبیعی ترین راه یک طرح باطل / تنبل-تجدید(invalidate/lazy-revalidate ) ارزیابی مجدد باشد.

انتشاز تغییر با استفاده از پشته میتواند  به راحتی مشکل ساز شود.اگر ساختار داده شکل خاصی داشته باشد به دلیل پیچیدگی بروزرسانی نمایی بالقوه است. یکی از این اشکال را می توان به عنوان "شکل الماس های مکرر" توصیف کرد ، و دارای ساختار زیر است: A n → B n → A n + 1 ، A n → C n → A n + 1 ، جایی که n = 1،2. . . این مشکل می تواند تنها با انتشار اعتبار نامعتبر هنگامی که برخی از داده ها قبلاً اعتبار ندارند ، برطرف شود و بعداً با استفاده از ارزیابی تنبل ، داده ها  مجدداً تأیید شوند.

یک مشکل ذاتی برای برنامه نویسی واکنشی این است که بیشتر محاسباتی که در یک زبان برنامه نویسی معمولی ارزیابی و فراموش می شوند ، باید در حافظه به عنوان ساختارهای داده نشان داده شوند. این به طور بالقوه می تواند باعث شود برنامه نویسی واکنشی را به شدت حافظه مصرف کند. با این حال ، تحقیق در مورد آنچه که *کاهش* نامیده می شود ، می تواند به طور بالقوه بر این مشکل غلبه کند. 

از طرف دیگر ، برنامه نویسی واکنشی نوعی از آنچه می توان به عنوان "موازی سازی صریح" توصیف کرداست و بنابراین می تواند برای استفاده از قدرت سخت افزار موازی مفید باشد.

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

## رویکردها

### امری ضروری
می توان برنامه نویسی واکنشی را با برنامه دستوری معمولی ترکیب کرد. در چنین الگویی ، برنامه های دستوری بر ساختار داده های واکنش پذیر عمل می کنند.  چنین تنظیماتی مشابه برنامه های دستوری محدودیت است . با این حال ، در حالی که برنامه نویسی دستوری محدودیت های دو جهته را کنترل می کند ، اما برنامه نویسی واکنشی، محدودیت های جریان داده یک طرفه را مدیریت می کند.

### شی گرا
برنامه نویسی واکنشی شی گرا (OORP) ترکیبی از برنامه نویسی شی گرا و برنامه نویسی واکنشی است. شاید طبیعی ترین راه برای ایجاد چنین ترکیبی به شرح زیر باشد: به جای روش ها و زمینه ها ، اشیا  *واکنشی* دارند که به طور خودکار مجدداً ارزیابی می شوند ، وقتی که سایر واکنش هایی که به آن بستگی دارند ، اصلاح شده باشند.

اگر یک زبان OORP روش های دستوری خود را حفظ کند ، در گروه برنامه نویسی واکنشی دستوری قرار می گیرد.

### عملکردی
برنامه نویسی واکنش پذیر عملکردی (FRP) یک الگوی برنامه نویسی برای برنامه نویسی واکنشی بر روی برنامه نویسی عملکردی است .

### بازیگر
از بازیگران برای طراحی سیستمهای واکنشی ، اغلب در ترکیب با برنامه نویسی واکنش کاربردی (FRP) برای توسعه سیستمهای واکنشی توزیع   استفاده شده است.

### مبتنی بر قانون
دسته نسبتاً جدیدی از زبان های برنامه نویسی از قید ها (قوانین) به عنوان مفهوم اصلی برنامه نویسی استفاده می کنند. این شام     ل واکنش به حوادث است که همه محدودیت ها را حل میکند. این نه تنها واکنش های مبتنی بر رویداد را تسهیل می کند ، بلکه باعث می شود برنامه های واکنشی در درستی نرم‌افزار نقش داشته باشند. یک مثال از زبان برنامه نویسی واکنش پذیر مبتنی بر قاعده ، Ampersand است که در جبر رابطه ایجاد شده است. 

## پیاده سازی ها
* ReactiveX ، یک API برای اجرای برنامه نویسی واکنشی با جریان ها ، مشاهدات و اپراتورها با چندین پیاده سازی زبان از جمله RxJs ، RxJava ،. NET ، RxPy و RxSwift.
* Elm (زبان برنامه نویسی) ترکیب واکنشی رابط کاربری وب.
* Reactive Streams ، استاندارد JVM برای پردازش جریان ناهمزمان با فشار برگشت ناپذیر
* ObservableComputations ، یک کراس پلت فرم. اجرای NET.

## جستارهای وابسته
* قابل مشاهده (محاسبه) ، قابل مشاهده در برنامه نویسی واکنشی.

## منابع

## پیوند به بیرون
* بررسی برنامه نویسی واکنش پذیر مقاله ای در سال 2013 توسط E. Bainomugisha ، A. Lombide Carreton ، T. Van Cutsem ، S. Mostinckx و W. De Meuter که بررسی و طبقه بندی رویکردهای برنامه نویسی واکنش پذیر موجود را ارائه می دهد.
* پروژه MIMOSA از INRIA - ENSMP ، یک سایت کلی درباره برنامه نویسی واکنشی.
* رد کردن الگوی Observer مقاله 2010 توسط اینگو مایر ، تیارک رومپف و مارتین اودرسکی که چارچوب برنامه نویسی واکنشی را برای زبان برنامه نویسی Scala ترسیم می کند.
* لغو الگوی مشاهده گر با Scala. عکس العمل نشان دهید مقاله سال 2012 اینگو
* RxJS ، کتابخانه Reactive Extensions برای "نوشتن برنامه های ناهمزمان [...] با استفاده از توالی های قابل مشاهده"
* مقابله با جوخه ناجور برای برنامه نویسی واکنشی: مقاله بازیگر-راکتور مدل 2020 که برای جلوگیری از مسائلی که هنگام ترکیب کد ضروری با کد راکتیو ارائه می شود ، مدل "بازیگران" و "راکتورها" را پیشنهاد می کند
رده:پارادایم‌های برنامه‌نویسی