تفاوت برنامه نویسی declarative و imperative

امروز میخوایم در مورد دوتا مفهوم صحبت کنیم تفاوت برنامه نویسی declarative و imperative در واقع همان برنامه نویسی بیانی و برنامه نویسی دستوری می توان معنا کرد.

برنامه نویس بيانی یا declarative

نوعی از برنامه نويسی است که، مقصد را بيان ميکنيد یا به عبارتی دیگر تمرکزش بر این است که چه می خواهيم و به رسيدن به مقصد توجه دارد ونحوه رسيدن به مقصد اهميت ندارد.

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

برنامه نویسی imperative یا دستوری

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

حالا دلیل توضیح این مطالب چه بود؟

در واقع یک قانونی وجود دارد که آن را می توان یک اصل نیز نامید "The Rule of Least Power" یا اصل حداقل قدرت که اینطور بیان می شود که برای توسعه نرم افزار ما باید تا جایی که ممکن است از زیر ساختی استفاده کنیم که کمترین قدرت را به ما بده و بیشترین قدرت را در دل خود به همراه داشته باشد.

بذارید برای درک بهتر یک مثالی بزنیم:

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

خب این موضوع در محصولات خود شرکت سود آوری دارد و کجا می بینیمش بیاین در قالب طراحی سایت مثال بزنیم اگر فرض بگیریم ما یک شرکت طراحی سایت داریم فرض کنیم ما می خوایم با ای پی آی API میخوایم ارتباط برقرار بکنیم و از داخل دیتاهایی که به ما برگردانده میشود ما میخوایم ی سری اسلاید شو رو بگیریم یا بهتر و راحتتر بگم در واقع ما می خوایم داخل سایت یه سری اسلاید شو رو دریافت کنیم (می خوایم دیتایی که از API میاد و بگیریم در اسلاید شو به نمایش بگذاریم) این میشه مقصود ما، حالا اگر ما بخوایم این دیتارو از API بگیریم در ابتدا باید API رو کال کنیم اون API وظیفه کال کردنش با ماست پس ما باید کدی بنویسیم که این وسط بتونیم ارتباطی بر قرار کنم با API این API احتمالا در یک Sub domain دیگری هاست شده، Cross Domain هست، بنابراین تابع پروتکل CORS هست (cross-origin resource sharing)

پس باید من این هم مد نظر قرار بگیرم چه بسا احتمال داره من جلوتر اطلاعات کاربری و بفرستم چون کاربری که log in شده شاید باید دیتای متفاوتی ببینه بنابر این من این هم باهاش درگیر می شم.

درواقع در گام بعدی من درگیر می شم با اینک این اطلاعات و من چطوری بخونم اصلا فرمت ارسال و دریافت اطلاعات چی هست درست در حال حاضر شما در حال استفاده از جیسون هستید ولی 5 یا 6 سال پیش اطلاعات جیسون نبود و xml بود که هنوز بسیاری از سیستم های اطلاعاتی بانکی نیز هنوز xml هستند و ما الان داریم از جیسون استفاده میکنیم شاید جلوتر از جی آر پی سی  (gRPC) استفاده میکنیم.

بنابر این نیاز هست ما اینجا دیتا رو بشناسیم فرمت انتقال دیتا رو بشناسیم و جایگاه این دیتارو بشناسیم که این دیتای مورد نظر ما کجا قرار دارد بین تمامی دیتاهایی که دریافت کردیم در واقع آدرس دقیق جیسون و بدونم تو کدوم نود قرار دارد  ما اگر بخواهیم دستوری حرکت imperative کنیم که خودمان به ای پی آی متصل بشیم اطلاعات کاربری و مدنظر قرار بدیم اطلاعات Cross Domain CORS رو مد نظر قرار بدم پروتکل رو بشناسم نستینگ Nesting و بشناسیم جی پد رو بشناسم و همه ی اینا میشه وظیفه ی من.

خب این خوب نیست ما می خوایم کسی که Front End هست فقط بیاد بگه این API و کال کن و از دلش این و بکش بیرون با حداقل استپ ها با حداقل دستورات و ما بقیه کار رو زیر ساخت شرکت انجام بده و این معماری برای این است که قصد داریم به سمت declarative پیش بریم.

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

اصولا تمامی بخش های خدماتی دارند به این سمت میرند که شما فقط نتیجه و مقصود رو بیان کنید و شما فقط نتیجه رو ببینید و شما باید هزینه ی رسیدن پرداخت کنید شاید تا 20 سال پیش اگر شما قرار بود یخچالی بخرید باید میرفتید بازار، ماشینی میگرفتید، انتخاب میکرد، تمامیه هماهنگ هارو انجام میدادید، نصاب میاواردید و.... 0 تا 100 مراحل با خودتان بود اما الان کاری که خیلی از سایت های فروشگاهی انجام دادند این خدمات و خودشون ارائه می دهند و مراحل کار در واقع declarative شده، یخچال میاد نصبش میکنند و فقط شما هزینش و پرداخت میکنید.

سخن آخر

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