https://virgool.ir/feed/@naderzade.mohsenمهندس نرم افزار کامپیوتر، توسعه دهنده اندرویدfa2026-11-12 02:38:47https://files.virgool.ir/upload/users/243964/avatar/eHsNUj.pnghttps://virgool.ir/@naderzade.mohsenhttps://virgool.ir/fboard/di-در-برنامه-نویسی-بخش-اول-l7igtj6nc3o9سلام خدمت همه دوستای عزیزم ، من یعنی محسن نادرزاده ، اومدیم با یه مقاله دیگه ، مدتها بود که به خاطر درگیریهای دانشگاهم نمیتونستم روی یادگیری مهارتهای جدید کار کنم و کمی از تکنولوژیهای جدید اندروید دور بودم ، ولی به تازگی با چک لیستی که من تهیه کردم ، شروع کردم به یادگیری اونها که یکیش di بود . اولین جایی که به عنوان سورس یادگیری رفتیم سراغش ، وب سایت دوست و یار همیشگی برنامه نویسا یوتیوب عزیز بود . به پیشنهاد یکی از عزیزان رفتیم سراغ چنل CodingInflow که احتمالا برای خیلی از شما همکاران آشناست . در یک سری مجموعه مقالات قرار هستش که چیزایی که من از آموزشهای این چنل در مورد DI یاد گرفتم رو براتون منتشر کنم ، بیشتر از این منتظرتون نمیزارم ، بریم سراغ بخش اول مقاله :اول از همه بیایم باهم ببینیم اصلا Dependency توی کلمه Dependency Injection معنیش چیه ؟معنی dependency : منظور از dependency آبجکتهایی هستش از کلاس های مختلف ، که یک کلاس میتونه برای انجام کار های خودش ، به اونها نیاز داشته باشه. مثلا در نظر بگیرید که ما دو کلاس به نامهای A و B داریم . کلاس A برای انجام وظیفه های خودش به نمونه یا instance ای از کلاس B نیاز داره. در چنین حالتی گفته می شود که کلاس B ، جزو Dependency های کلاس A هستش.حالا بریم سراغ کلمه دوم یعنی Injection :وقتی از این کلمه توی برنامه نویسی برای مفهوم DI استفاده می کنیم منظورمون این هستش که Dependency های یک کلاس، باید خارج از کلاس تهیه و ساخته بشن و بعد به کلاس داده بشن تا کلاس بتونه کارشو انجام بده و در حقیقت خود کلاس نباید مسئولیتی برای فراهم کردن Dependency های خودش داشته باشه.توی تکه کد بالا ، ما یک کلاس Car داریم که مفهوم اتومبیل در دنیای واقعی رو نشون میده . یک اتومبیل برای اینکه بهش اتومبیل یا وسیله نقلیه اطلاق بشه ، دو مفهوم اساسی رو نیاز داره ، یکی موتور اتومبیل و دیگری چرخهای اون هستش . در مثال بالا ، کلاس Car ما دو پارامتر رو که کلاسهای موتور یا Engine و کلاس چرخ ها یا Wheels باشن رو به عنوان پارامتر ورودی متد سازنده دریافت می کنه، یعنی ما برای ساختن یک instance از این کلاس باید دو تا instance از کلاسهای Engine و Wheels رو هم فراهم کنیم. در زمانی که ما چنین سناریویی داریم چند روش داریم تا این Dependency ها را برای کلاس فراهم کنیم :1- ساختن آبجکتهای مورد نیاز داخل خود کلاس : توی چنین حالتی ، ما وقتی داریم آبجکتی از Dependency کلاس (مثلا کلاس Engine) رو داخل کلاس تعریف می کنیم ، توی همون لاین هم میایم اون رو مقداردهی یا اصطلاحا initialize می کنیم . اما این کار اشتباهه ، شاید کدمون کار کنه ولی این کار اصولی نیست، چرا که بالاتر گفتیم کلاس نباید خودش مسئولیتی برای فراهم کردن Dependency های خودش داشته باشه و با اینکار اصولا خود کلاس ما خودش مسئول ساختن dependency هاش هستش که این خب این اشتباهه.2- دریافت dependency ها از طریق متد سازنده 3- دریافت dependency ها از طریق متدهای Setterاگه بخوایم حالت شماره یک رو در دنیای واقعی در نظر بگیریم ، باید مثال خط مونتاژ اتومبیلی رو در نظر بگیریم که کارکنان این خط وقتی نوبت به نصب چرخها و موتور میرسه ، باید از صفر یعنی پیچ ها و تهیه مواد اولیه شروع به ساختن موتور و چرخها کنن و اینکار رو برای هر اتومبیل داخل خط انجام بدن در حالی که این کار اصولی نیست و می بایست موتور و چرخها ، به صورت موازی با بدنه اتومبیل در خط تولید جداگانه ای تولید بشن و کارکنان خط مونتاژ فقط مسئولیت نصب اونها روی بدنه اتومبیل رو داشته باشن. توی چنین حالتی اگه ساختار موتور تغییری بکنه کار کارکنان خط مونتاژ با مشکل مواجه نمیشه.فراهم کردن Dependency های کلاس از روش شماره دو یا روش شماره سه چند مزیت داره : اول مسئولیت ساخت dependency ها از خود کلاس گرفته میشه و اصطلاحا ما کلاس رو از ساختن dependency های خودش میایم و Decouple می کنیم. از مزایای Decouple شدن این موضوع ها از هم دیگه، میشه به Unit test اشاره کرد چرا که توی Unit test ، هدف تست یک کامپوننت ایزوله جدای dependency های اون کامپوننت هستش.توی پروژه های بزرگ موارد زیادی وجود داره که Dependency های کلاس ما ، جزو Dependency های پر هزینه هستش مثل Database ، وب سرویس و... . و ما هنگام Unit test نیازی نداریم تا این Dependency ها رو تست کنیم.معمولا توی unit test به جای استفاده از آبجکتهای واقعی این Dependency های پر هزینه ، این Dependency ها رو اصطلاحا mock یا شبیه سازی می کنیم و فقط از آبجکتهایی استفاده می کنیم که صرفا رفتار اونها رو میاد و برای ما شبیه سازی میکنه. یک سری سناریو هم توی برنامه نویسی ممکنه پیش بیاد که ما مجبور هستیم تا از یک آبجکت مشترک برای تامین dependency های چندین کلاس استفاده کنیم. مثال خط مونتاژ اتومبیل رو توی ذهنتون دوباره تجسم کنید، فرض کنید که بعد از اتمام مونتاژ هر اتومبیل ، راننده ای باید اتومبیل ساخته شده رو به بیرون خط مونتاژ ، هدایت کنه ، توی چنین حالتی لازم نیست تا برای هر اتومبیل جدید، یک راننده جداگانه داشته باشیم و ما می تونیم از یک راننده برای تمام اتومبیلها استفاده کنیم. توی برنامه نویسی هم این سناریو گاهی پیش میاد، مثلا شما از یک instance از کلاس HttpClient ممکنه برای انجام چند کار مختلف و متفاوت مرتبط با شبکه استفاده کنید برای مثال استفاده از یک http client برای دانلود و اپلود و همچنین ارسال درخواستهای http به سرور. توی حالتی که ما dependency های خودمون رو از طریق متد سازنده دریافت می کنیم انجام چنین کاری غیرممکنه اما اگه از di استفاده کنیم اینکار قابل انجامه.پس تا اینجای مطالب میشه نتیجه گرفت که DI یک دیزاین پترن محسوب میشه نه یک لایبری . توی هر اپلیکیشن هم به نوعی از DI استفاده میشه . ما اگه بخوایم توی حوزه برنامه نویسی اندروید چند مثال بزنیم ، زمانی که ما برای یک ریسایکلر ویو با استفاده از متد setAdapter ، اداپتر ست می کنیم در حال انجام DI هستیم، حتی زمانی که یک مقدار متنی یا String رو به متد سازنده یک کلاس پاس میدیم هم باز در حال انجام DI هستیم بنابراین ، برای اینکه DI را در نرم افزار و پروژه خود را داشته باشیم ، الزامی برای استفاده از لایبری نداریم.توی بخش بعدی مقاله ، ما به معرفی لایبری Dagger ، و اینکه اصلا این لایبری چی هستش و چرا ما باید از این لایبری یا لایبریهای مشابه استفاده کنیم ، اشاره می کنیم. بچه ها محتوای این مقاله با زحمتهای خانم الهه آرین عزیز و من تهیه شده و میشه گفت در حقیقت نسخه ترجمه شده ای از آموزشهای کانال یوتیوب CodingInflow هستش . اگر جایی در مقالات ما اشتباهی دیدید ، خوشحال میشیم باهامون درمیون بزارید ، ما مشتاق یادگیری هستیم و خوشحال میشیم شما عزیزان و اساتید پیشنهادات و انتقاداتتون رو برای ما بنویسید . در آخر باید تشکر کنم ازتون که تا اینجای مقاله رو خوندید :))))) دمتون گرم دوستتون داریم . محسن نادرزادهمحسن نادرزادهFri, 01 Oct 2021 17:10:12 +0330https://virgool.ir/coderlife/قسمت-صفر-از-فصل-اول-کتاب-kotlin-in-action-zvkt3vt0ydm0خب قسمت صفر از فصل اول کتاب رو شروع می کنم. قبل از هر چیزی بگم که این مجموعه مقالات توسط سرکار خانم الهه آرین و آقای محسن نادرزاده نوشته میشه و به قول الهه، اگه الهه نبود ، مقاله، مقاله نبود، نقاله بود.:))))) اما خب بریم سراغ فصل اول کتاب، این فصل تحت عنوان کاتلین: چی و چرا ؟، مطالب زیر رو پوشش میده که من در این قسمت از مقاله فقط به بعضی از اونها اشاره می کنم و الباقی رو به خاطر طولانی نشدن مقاله skip می کنم:· خلاصه ای از زبان کاتلین· ویژگیهای زبان کاتلین· قابلیتهای کاتلین برای توسعه اپلیکیشنهای اندرویدی و برنامه نویسی server-side· تفاوتهایی که کاتلین رو از سایر زبانها جدا می کنهو در نهایت به نحوه نوشتن و اجرای کد در کاتلین می پردازه.کاتلین یه زبان برنامه نویسی جدید بر پایه پلتفرم زبان برنامه نویسی جاوا هست. از این زبان میشه در هر جایی که در حال حاضر زبان جاوا استفاده میشه مثل برنامه نویسی server-side و اپلیکیشنهای اندرویدی و... ، استفاده کرد. از لحاظ میزان پرفورمنس و کارآیی کاتلین با جاوا تفاوت چندانی ندارن و همینطور کاتلین با تمامی لایبریهای در حال حاضر جاوا سازگاری داره و شما می تونید از اونها در کاتلین هم استفاده کنید.به عکس بالا توجه کنید ، داخل این عکس شما می تونید یک تکه کد به زبان کاتلین رو مشاهده کنید که بعضی از قابلیتهای هیجان انگیز و جدید زبان کاتلین رو به خوبی نشون میده.خب بریم سراغ جزئیات و توضیحات عکس بالا، توی این عکس به زبان کاربر ما یه کلاس Person تعریف کردیم که دو تا property داره ، name و age . به صورت پیشفرض برای property سن یا Age این کلاس به صورت پیشفرض مقدار null تعریف شده . این مقدار باعث میشه زمانی که توی تکه کد بالا ما سنی برای ابجکت Alice تعریف نکنیم، مقدار سن یا Age این ابجکت null قرار بگیره. توی تکه کد بالا از تابع maxBy برای پیدا کردن کاربری که بیشترین سن رو داره استفاده کردیم. Lambda expression ای که به این تابع پاس داده شده یه پارامتر ورودی داره که به صورت پیشفرض برای اسم این پارامتر ما از it استفاده کردیم. توی این تصویر ما یک عملگر تازه داریم که توی زبان جاوا وجود نداره و این عملگر یا operator یکی از عملگرهای چهارگانه زبان کاتلین برای کنترل و جلوگیری از خطای معروف و آزاردهنده nullpointer exception هستش . این عملگر ?: عملگر Elvis نام داره و شیوه استفاده از این عملگر به صورت زیر هستش :ObjectName?:0به جای عبارت ObjectName نام ابجکت مد نظر ما قرار میگیره و بعدش این عملگر قرار میگیره ، مقدار صفری که در عبارت فوق وجود داره باعث میشه که در صورتی که اون ابجکت به هر علتی null بود، مقدار صفر به ما برگرده توی کد بالا هم در صورتی که age ما مقدار null داشته باشه، این عملگر باعث میشه مقدار صفر به ما برگرده. توی تکه کد بالا از اونجایی مقداری برای سن Alice تعریف نشده، عملگر Elvis برای این ابجکت مقدار صفر در نظر میگیره و ابجکت بعدی یعنی ابجکت Bob چون سن براش مشخص شده ، به عنوان بزرگترین فرد توی خروجی چاپ میشه.حالا وقت اون شده که کمی کاتلین رو با جزئیات بیشتری بشناسیم، اول باید بدونیم کاتلین توی چه دسته بندی از زبانهای برنامه نویسی قرار میگیره؟ static یا dynamic ؟زبان کاتلین مثل زبان جاوا، یه زبان static محسوب میشه، وقتی یه زبان static باشه، تمامی دستوراتی که ما می نویسیم در زمان کامپایل ارزیابی و validate میشن و کامپایلر می تونه بررسی کنه که آیا اصلا property یا متد مد نظر ما توی کلاس و آبجکت مورد استفاده وجود داره یا نه؟ در مقابل، زبان های dynamic زبانهایی هستند که شما می تونید هر نوع داده و دیتایی رو توی متغیرها ذخیره کنید یا توی توابع برگردونید، و بررسی در دسترس بودن یا نبود متد ها و property ها توی این دسته از زبانهای برنامه نویسی، توی زمان اجرا یا runtime صورت میگیره از جمله مزایای زبانهای dynamic میشه به افزایش سرعت توسعه اشاره کرد اما یکی از بزرگترین معایب این زبانها برای مثال این هستش که املای نام کلاسها و ابجکتها بررسی نمیشه و این امر میتونه موجب خطا در زمان اجرا بشه.به علاوه کاتلین شما رو برخلاف جاوا مجبور به مشخص کردن نوع داده هر متغیری که تعریف می کنید، نمی کنه. در بسیاری از مواقع نوع داده متغیر میتونه توسط کامپایل با توجه به context اون متغیر و استفاده ای که از اون شده، تعیین بشه. به مثال زیر توجه کنید:val x=1توی مثال بالا ما یه متغیر به اسم x تعریف کردیم و اون رو با 1 مقداردهی کردیم، پس به خاطر همین مقدار دهی، کاتلین نوع داده این متغیر رو از نوع عدد صحیح یا Int در نظر میگیره. نکته ای که وجود داره این هستش که به قابلیت تشخیص نوع داده متغیر توسط کامپایلر Type inference گفته میشه.تو ادامه می خوام بعضی از مزایای زبانهای static type رو بگم براتون:· کارآیی یا Performance بهتر: برای مثال فراخوانی کردن متدها سریعتر چرا که در زمان اجرا نیاز نیست تا ابتدا بفهمیم که کدام متد می بایست اجرا گردد.· اطمینان بیشتر: از انجایی که کامپایلر کد های ما در زمان کامپایل بررسی می کند پس امکان کرش کردن نرم افزار در زمان اجرا، به کمترین حد خود می رسد.· نگهداری یا Maintainability بهتر : در این نوع زبانها کار با کد های نا آشنا برای برنامه نویس ساده تره چون می تونیم ببینیم کد با چه نوع آبجکتهایی داره کار می کنه.در زبان کاتلین، به خاطر پشتیبانی کردن این زبان از type inference مشخص کردن نوع متغیرها در هنگام تعریف انها اجباری نداریم و این یک مزیت نسبت به زبان جاوا است.یکی دیگر از ویژگیهای مهم زبان کاتلین نسبت به زبان جاوا، پشتیبانی از nullable ها است که به ما کمک می کنه تا از بروز خطای ازاردهنده و مشهور Null pointer exception جلوگیری کنیم.خب فکر می کنم برای قسمت صفر از مجموعه مقالات کتاب kotlin in action این حجم از مطالب کافی باشه. ما توی قسمت بعدی در مورد یکی دیگر از قابلیتهای هیجان انگیز و جدید زبان کاتلین به اسم function types صحبت می کنیم .محسن نادرزادهمحسن نادرزادهSat, 26 Jun 2021 11:44:19 +0430