من کوتلین را در Android امتحان کردم و دیگر به جاوا بر نمی گردم

 

 

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

 

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

 

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

 

همانطور که از عنوان عنوان حدس زده اید ، گذرگاه من روان و لذت بخش بود و نوشتن در کلتین را در مقایسه با جاوا بسیار لذت بخش دیدم. بنابراین لیستی از ویژگی هایی را که من را متقاعد کرد تا به سمت کوتلین حرکت کنم ، به شما ارائه می دهم. (چون جزیره ای به نام کوتلین هم هست ، فهمیدی؟: P)

 

ایمنی خالی

به نظر می رسد null-Safety اولین ویژگی Kotlin است که به ذهن برنامه نویس با پس زمینه جاوا می رسد. مرجع تهی یکی از ویژگی های موجود در اکثر زبان های برنامه نویسی است. ممکن است مفید به نظر برسد ، اما مشکل ساز شد و بسیاری از موارد را برای خرابی و خرابی برنامه معرفی کرد.

 

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

 

var foo = "string" // خوب

var bar = null // خطای کامپایل

var baz: رشته؟ = null // خوب

فقط می توان null را به ویژگی یک نوع nullable ، با حاشیه نویسی اختصاص داد؟. برای اجرای دستورات حاوی چنین انواع ، کامپایلر ما را مجبور می کند از تماس امن استفاده کنیم.

 

bar.callFunc () // خطای کامپایل ، نوار ممکن است تهی باشد

نوار؟ .callFunc () // خوب

به جای خرابی ، تماس امن ارزیابی نمی شود و اگر در نقطه ای از زنجیره مقدار null وجود داشته باشد ، null بر نمی گرداند. با استفاده از؟ این به ما کمک می کند تا از چک های تهی انباشته شده با دستور if جلوگیری کنیم و همچنین با استفاده از Optionals رها شویم ، بنابراین ما کد خواندنی تر می نویسیم و از مقادیر null به شکل دقیق تری استفاده می کنیم.

 

کلاس داده

ایجاد کلاس هایی که به منظور ذخیره داده ها هستند معمولاً ساده است. اعضا را اعلام کنید ، تغییرپذیر باشند یا خیر و مelyدبانه از IDE خود بخواهید که کد صفحه بویلر را مطابق با قرارداد جاوا Bean تولید کند. کلتین دارای عملکرد خاصی است-کلاس داده ، که به منظور ایجاد چنین کلاسهایی حتی ساده تر و کمتر مستعد خطا است.

 

کلاس داده MyClass (val foo: String، var boo: Int)

و این همه مردم است! این کامپایلر است ، نه IDE ، که وظیفه دارد ویژگیها را از سازنده اصلی بگیرد و از آنها برای ایجاد همه روشهای اضافی استفاده کند. این باعث می شود که کلاس داده شما اساساً فهرستی از ویژگی ها را بدون همه توابع ایجاد شده که هرگز برای خواندن آنها زحمت نمی کشید ، ایجاد کند.

 

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

 

یکی دیگر از عملکردهای ایجاد شده ، copy () است ، که (duh) نمونه ما را کپی می کند. این امر به طور قابل ملاحظه ای مفید است هنگامی که ما نیاز به مقابله با یک شی داده تغییر ناپذیر داریم ، که در طول زمان تغییر می کند ، یعنی حالت فرم.

 

myClassInstance = myClassInstance.copy (foo = "foo")

و این مثال ما را به…

 

خواص نامگذاری شده

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