سلب مسئولیت
این متن در ابتدا به دلیل رونویسی از کلاس دوره “3 ستون برای صعود به سیستم های توزیع شده” از سفر Dev + کارآمد ، توسط AI مولد تصور شد. اگر ترجیح می دهید با فیلم دنبال کنید ، فقط بازی کنید.
https://www.youtube.com/watch؟v=pz5Droxzblq
مقدمه
در قسمت امروز می خواهم در مورد تغییر ذهنیت صحبت کنم وقتی که شما پارادایم با هدف را به سمت کاربردی ترک می کنید ، اما از این مسیر به سمت دیگر ، نه آنقدر از عملکردی تا شی گرا. این تأمل از سوالی ناشی شد که از من در کانال سؤال کرد: “آیا تغییر روشی که فکر می کنید وقتی برنامه نویسی را با Clojure شروع کردید ، برای شما بسیار دشوار بود؟”
پاسخ من حتی برای خودم تعجب آور بود: “من به شما اعتراف خواهم کرد که برای من هیچ چیز تغییر نکرده است. من هنوز هم می خواهم همان نوع برنامه را بنویسم ، اما یک ساعت این برنامه را با جاوا می نویسم و یک بار دیگر این برنامه را با زبانی مانند Clojure یا هر دیگری که کاملاً کاربردی باشد می نویسم.”
نگرانی های اصلی در انتقال بین پارادایم ها
من تصمیم گرفتم این تأمل را عمیق تر کنم و نگرانی های اصلی را که شخص می تواند هنگام ترک یک زبان شیء با زبان کاربردی داشته باشد ، ذکر کردم. بیایید به هر یک نگاه کنیم.
1
از تفکر از نظر اشیاء و حالت ها عبور کنید تا به عملکرد داده ها و تحولات فکر کنید.
راستش ، من خیلی در مورد آن فکر نمی کنم. پیش از این ، من یک کلاس با ویژگی ها و روش هایی داشتم که پارامترها را دریافت می کنند و کاری انجام می دهند. اکنون من تابعی دارم که پارامترهایی را با داده هایی که در آن کار می کند دریافت می کند ، و چندین کارکرد که اغلب در متن های مختلف این پارامتر مشابه را دریافت می کنند. برای من ، خیلی تغییر نمی کند.
2. تغییر ناپذیری
با تغییر داده ها سازگار نشوید ، اما نسخه های جدید تبدیل شده را ایجاد کنید.
باز هم ، این به من تغییر زیادی نکرد. کد مورد نظر من قبلاً بسیار تحت تأثیر ایده تغییر ناپذیری بود ، نه به معنای افراطی همیشه ایجاد نسخه های جدید اشیاء ، بلکه به این معنا که: “من یک پارامتر دریافت کردم و در حالت آن پارامتر حرکت نمی کنم زیرا نمی دانم از کجا آمده است ، نمی دانم کسی قبلاً حرکت کرده است یا می خواهد بعد از عملکرد من با آن وضعیت آشفتگی کند.”
ایده های به حداقل رساندن تغییر حالت و تمرکز آن در یک نقطه خاص قبلاً در کد من رایج بود. بدیهی است ، در Clojure شما گزینه تغییر حالت ها را ندارید ، اما به این دلیل نیست که من این گزینه را در جاوا یا جاوا اسکریپت دارم که باید از آن استفاده کنم.
3. توابع خالص
مفهوم توابع را بدون عوارض جانبی درک کرده و به کار بگیرید.
من قبلاً تحت تأثیر این مفهوم بودم. اگر من تابعی دارم که یک پارامتر دریافت می کند و باید این مقدار را در پایگاه داده ذخیره کنم ، به خودم اجازه نمی دهم که این کار را در عملکرد میانی انجام دهم ، زیرا نمی دانم چه کسی قبل از ذخیره تماس گرفته است.
البته کارکردهای من در زبانهایی مانند جاوا و جاوا اسکریپت در حال حاضر به عملکردهای خالص نزدیک می شوند. آنها به معنای کامل خالص نیستند ، زیرا یک عملکرد خالص یکی از عوارض جانبی است و همیشه نتیجه مشابه را برای همان پارامترها برمی گرداند. به عنوان مثال ، اگر به یک تاریخ وارد شوید یا به عنوان مثال ، از نظر فنی عملکرد دیگر خالص نیست. اما این نگرانی من بود.
4
حلقه های سنتی را با تماس های بازگشتی برای تکرار جایگزین کنید.
این نکته واقعاً نیاز به تلاش شناختی بیشتری دارد. از انجام حلقه هایی با بازگشت استفاده نشده بود. با این حال ، با استفاده از زمان استفاده از Clojure ، فهمیدم که تقریباً هر حلقه در مجموعه ها در توابع آماده مانند MAP ، فیلتر ، کاهش یا در ترکیب این توابع اجرا شده است. این نیز در جاوا مدرن وجود دارد. شما به ندرت نیاز به ایجاد یک الگوریتم بازگشتی پیچیده در منطق تجارت روزمره دارید.
5. توابع مرتبه بالاتر
استفاده از توابع را به عنوان یک پارامتر تسلط دهید.
من قبلاً از برنامه نویسی زیادی در جاوا استفاده کردم ، از جمله کارآمد Dev + Journey بخشی از دوره را دارد که من در مورد استفاده از الگوهای روش دریافت توابع به عنوان یک آرگومان صحبت می کنم. علاوه بر این ، من قبلاً در JavaScript خیلی برنامه ریزی کرده ام ، بنابراین هزینه کردن توابع به عنوان یک استدلال برای به دست آوردن قابلیت آزمایش از قبل برای من رایج بوده است.
6. ترکیب توابع
بیاموزید که به جای روشهای بزرگ ، توابع کوچک را ترکیب کنید.
این تفاوت بین پارادایم ها برای من چندان معنی ندارد. دقیقاً همانطور که جالب است که عملکردهای کوچکی داشته باشید ، همچنین جالب است که روش هایی با اندازه محدود در برنامه نویسی با جهت شیء داشته باشید.
7. فکر اعلامی
به جای “چگونگی” توصیف نتیجه مطلوب ، روی “que” تمرکز کنید.
من فکر می کنم در عمل ، تئوری کمی متفاوت است. وقتی من در Clojure برنامه نویسی می کنم ، هنوز هم احساس می کنم آنچه را که می خواهم اتفاق بیفتد ، درست مثل جاوا می گویم. کسی می تواند بگوید که من فقط ساختارهایی را اعلام می کنم که مترجم به روش خودش اجرا خواهد کرد ، در حالی که در جاوا می گویم دقیقاً چگونه این کار را انجام دهم ، اما برای من تفاوت چندانی ندارد.
من این تفاوت را با وضوح بیشتری احساس کردم که کتابخانه های کد واکنشی برای جاوا به وجود آمد ، جایی که شما توابع را اعلام کردید و چگونه نقشه برداری کردید ، و این بیانیه را برای انجام (همزمان یا ناهمزمان ، در یک یا چند هسته ، با آزمایش مجدد و غیره) به کتابخانه برگردانید. اما در برنامه نویسی روزمره ، موقعیت ها خود را ارائه نمی دهند. من یک جریان تجاری برای پیاده سازی دارم ، چندین تماس از توابع برقرار می کنم ، و من چیزی انتزاعی اعلام نمی کنم – می گویم که می خواهم به این روش انجام شود.
8. پردازش مجموعه های کاربردی
حلقه ها را با عملیات با نقشه جایگزین کنید ، فیلتر کنید و کاهش دهید.
این تقریباً در تمام زبانهای مدرن است. همه به شما امکان می دهند این عملیات را با توابع و روشهای آماده -دات انجام دهید.
9. عدم وجود ساختارهای کنترل سنتی
با فقدان حلقه های معمولی برای/در حالی سازگار شوید.
این به نظر می رسد با نقطه 4 و 8 تکراری است. در مورد ساختمانهایی مانند اگر/دیگری ، کسی می تواند بگوید که در زبان های عملکردی اگر یک عملکرد باشد ، اما در کد آن یک IF باقی مانده است – مکانیسمی که چیزی را به صورت مشروط انجام می دهد. برای من ، هیچ تفاوتی ندارد که آیا این یک عملکرد است یا نه.
10. کاربرد و کاربرد جزئی
تکنیک های خاص برنامه نویسی عملکردی را درک کنید.
من از این نیز در جاوا استفاده کرده بودم. اگر من یک عملکرد با سه پارامتر داشته باشم و فقط می توانم بخشی از آنها را برطرف کنم ، عملکرد دیگری را که انتظار پارامتر باقیمانده را دارد ، حل می کنم و برمی گردانم. باز هم ، این روش تفکر من را خیلی تغییر نکرد.
پایان
در پایان ، من تفاوت بزرگی بین پارادایم ها احساس نمی کنم. من فکر می کنم این به این دلیل است که من قبلاً اصول بسیاری از دنیای کاربردی را بر روی کد با هدف شیء خود اعمال کردم.
من شخصاً این ایده را دوست دارم که یک کلاس داشته باشم که در آن مقادیر با هم می خواهم به طور مرتب با کارکردهایی که بر روی این مقادیر کار می کنند استفاده کنم. من انسجام را دوست دارم ، و یک زبان با هدف شیء این را به طور عملی به صورت رایگان به من می دهد. باربارا لیسکوف این موضوع را دقیقاً پیشنهاد کرد: جمع آوری یک ساختار داده با مجموعه ای از کارکردهایی که به طور مرتب روی آن کار می کنند.
از طرف دیگر ، من ایده های زبانهای کاربردی را نیز دوست دارم: عوارض جانبی را به حداقل برسانید ، این اثرات را در یک نقطه خاص متمرکز کنید ، تا حد امکان عملکردهای خالص داشته باشید (که تست ها را تسهیل می کند) و عملکردهای خود را به عنوان آرگومان برای به دست آوردن انعطاف پذیری ارائه می دهید.
از آنجا که ماهرترین زبان من جاوا است ، من قبلاً بسیاری از این اصول عملکردی را برای برنامه ریزی در آن جذب کرده بودم. بنابراین وقتی انتقال را انجام دادم تفاوت زیادی نداشتم.
با سفر کارآمد Dev + آشنا شوید
کارآمد Dev + Journey یک آموزش متمرکز بر رشد شما در حرفه خود به عنوان شخصی است که به طور فزاینده ای در ارائه نرم افزاری تخصص دارد که دارای ارزش با حداکثر کیفیت و سیالیت است.
سفر این مسیر را از طریق یک رویکرد یکپارچه ، کار بر روی جنبه های مختلفی که بر کیفیت تحویل نهایی تأثیر می گذارد ، مانند: مهندسی الزامات ، طراحی کد ، معماری ، تست ها و غیره هموار می کند.
این تنها مکانی است که خواهید یافت که 100 ٪ متمرکز بر رشد شما به عنوان یک فرد توسعه دهنده نرم افزار کامل است.
برای کسب اطلاعات بیشتر ، به https://devefilecy.com بروید
