دانستنی‌ها

چرا کاتلین؟ ۸ دلیل که می‌تواند برنامه‌نویسان جاوا را برای تغییر قانع کند. (قسمت سوم)

جاوا به چه شکلی در می‌آمد اگر کسی آن‌ را امروز از نو طراحی می‌کرد؟ احتمالا چیزی شبیه کاتلین

در قسمت‌های اول و دوم این مطلب، ۶ مورد از دلایل تغییر از جاوا به کاتلین را با هم بررسی کردیم. در این مطلب ۲ مورد دیگر به همراه جمع بندی را مطالعه خواهیم کرد.

۷- سربار کردن اپراتورها

در کاتلین برخی توابع می‌توانند از طریق اپراتور‌های از پیش‌ تعریف‌شده صدا شوند. من چون در زندگی قبلی‌ام یک ریاضی‌دان بوده‌ام(!) به این قابلیت ارادت خاصی دارم. با کمک سربار کردن اپراتورها بسیاری از عملیات‌ها روی کلاس‌های ریاضیاتی می‌توانند به شکل طبیعی‌تری نوشته شوند. مثلا کلاس‌های Fraction و Matrix از اپراتور‌های سربار‌شده‌ی جمع و ضرب و … استفاده می‌کنند. حتی کلاس‌های غیر ریاضی هم می‌توانند از مزیت سربار کردن اپراتور‌ها استفاده کنند، مثلا استفاده از اپراتور == به جای تابع equals یا استفاده از براکت ([ ]) به جای تابع get مثلا داخل myList[n]  یا myMap[“key”] می‌تواند مفید باشد.

البته زبان ++C هم امکان سربار کردن اپراتورها را می‌دهد اما به‌شخصه رویکرد کاتلین را ترجیح می‌دهم.

در ادامه لیست‌(ناکاملی) از توابعی که با استفاده از اپراتور‌ها می‌توانند صدا شوند را می بینیم:

نام تابععملگر
()plus+
()times*
()plusAssign=+
()equals==
()compareTo>
()get[]
()rangeTo..
()containsin
()inc++

قوانین سربار کردن اپراتور در کاتلین

در مورد سربار کردن اپراتور در کاتلین خوب است به چند نکته مهم توجه کنیم:

  • توابعی که قرار است اپراتوری را سربار کنند، باید با کلیدواژه operator مشخص شوند. این مورد در تکه کد زیر بهتر نشان داده می‌شود.
  • وقتی این قابلیت با تایپ‌سیستم یکپارچه کاتلین ترکیب می‌شود، به ما امکان استفاده از == بدون نیاز به نگرانی بابت اینکه چه زمانی باید از این تابع و چه زمانی از equals استفاده کنیم را می‌دهد. همه ما‌ها در جایی از برنامه‌نویسی جاوا به جای equals به اشتباه از == استفاده کرده‌ایم. همچنین برای چک کردن هویت (برابری رفرنس‌ها) کاتلین عملگر === (۳ تا مساوی) را تعبیه کرده است. همچنین دقت کنید که حتی در صورتی که در بررسی برابری a==b اگر a برابر null باشد باز هم جای نگرانی نیست چرا که آن وقت به برابری === تبدیل می‌شود یعنی null === b.
  • با اینکه برای ++ فقط یک تابع داریم (inc) اما کاتلین همواره به درستی از نتیجه این تابع استفاده می‌کند و x++ و ++x به شکل‌های متفاوتی کامپایل می‌شوند. به شکل مشابه کاتلین می‌داند که زمانی که از اپراتور‌های >= و < و .. استفاده می‌شود از نتیجه‌ی تابع compareTo چگونه استفاده کند.

در کد زیر یک کلاس را می‌بینید که چند اپراتور را سربار کرده است.

و در ادامه یک نمونه استفاده از آن کلاس را می‌توانید ببینید. دقت کنید که با کمک { } از قالب‌های رشته‌ (string template) استفاده شده است.

اشیا سطح بالا و الگوی سینگلتون

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

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

استفاده از این کلاس به شکل زیر است:

یادداشت مترجم: دقت کنید که همین که فیلد را به شکل static تعریف کنید و به شکل برخط مقدار دهید هم به لطف بارگذاری «تنبل» کلاس‌ها در جاوا از مزیت بارگذاری تنبل این شی بهره‌مند می‌شوید و نیاز به کار بیشتر نیست. همچنین دقت کنید که اگر لازم است کلاستان در محیط هم‌روند امن باشد باید خودتان متد‌هایش را امن کنید و سنکرون کردن getIsntance کافی نیست.

در کاتلین، الگوی سینگلتون به کمک «تعریف شی سطح بالا» ممکن می‌شود (top-level object declaration). به استفاده از کلمه‌ کلیدی object به جای class دقت کنید.

استفاده از متدهای این کلاس به شکل زیر خواهد بود:

اگرچه به این شکل، روش کاتلین ساده و سرراست است، اما در صورتی که سازنده ما چند پارامتر داشته باشد با پیچیدگی مواجه می‌شود.

 

ویژگی‌های بیشتر

اگرچه در این مطلب ۳ قسمتی چندین ویژگی مهم کاتلین را بررسی کردیم اما این زبان ویژگی‌های بیشتری دارد که معرفی هریک نیاز به مطلب جداگانه‌ای دارد. همچنین این زبان نسبت به جاوا برخی ویژگی‌ها را هم ندارد که جای خالیشان حس می‌شود مثلا فیلد‌های استاتیک.

 

آیا مهاجرت از جاوا به کاتلین ارزشش را دارد؟

بسیاری از زبان‌ها برای بهبود زبان های برنامه‌نویسی قبلی ساخته شده‌اند. کاتلین و اسکالا و کلوژر برای جایگزینی جاوا آمده‌اند. آیا تبلیغ گوگل برای جایگزینی جاوا با کاتلین در اندروید کافی است؟

برای بیش از ۲۰ سال، زبان ترجیحی من جاوا بوده است، اگرچه جاوا زبان بسیار خوبی است اما بدخواهان خود را هم دارد! در طول زمان جاوا تلاش کرده و تکامل یافته تا کاستی‌هایش برطرف شوند و کارایی برنامه‌نویسان افزایش پیدا کند. اما تکامل در یک زبان برنامه‌نویسی فعلی، نیاز به دقت قابل توجه در سازگاری با نسخه‌های قدیمی دارد، برای همین گاهی ساختن یک زبان جدید جایگزین بهتری است.

آیا کاتلین بهتر از جاوا است؟ در بسیاری از زمینه‌ها جواب مثبت است. اما آیا این خوبی‌ها ارزش مهاجرت را دارند؟ این سوالیست که خودتان باید جواب دهید اما قطعا کاتلین لیاقت توجه جدی شما را دارد.

 

همچنین دوست‌داران می‌توانند از این مطالب نکات بیشتری بیاموزند:

https://proandroiddev.com/the-kotlin-guide-for-the-busy-java-developer-93dde84a77b7

https://medium.com/pinterest-engineering/kotlin-for-grumpy-java-developers-8e90875cb6ab

https://www.ideamotive.co/blog/a-complete-kotlin-guide-for-java-developers

 

 

 

منبع: https://www.infoworld.com/article/3396141/why-kotlin-eight-features-that-could-convince-java-developers-to-switch.html

با اندکی تغییر و تلخیص

.

.

.

.

با ما همراه باشید


آدرس کانال تلگرام: JavaCupIR@

آدرس اکانت توییتر: JavaCupIR@

آدرس صفحه اینستاگرام: javacup.ir

صفحه ویرگول: javcup

آدرس گروه لینکدین: Iranian Java Developers

 

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا