كتابة كود Kotlin Friendly Java

من الخارج ، قد يبدو أن Kotlin قام بتبسيط تطوير Android دون إدخال صعوبات جديدة على الإطلاق: اللغة متوافقة مع Java ، لذلك يمكن ترجمة مشروع Java كبير إليها تدريجيًا دون إزعاج أي شخص ، أليس كذلك؟ ولكن إذا نظرت أعمق ، يوجد في كل صندوق قاع مزدوج ، وفي طاولة الزينة يوجد باب سري. لغات البرمجة هي مشاريع معقدة للغاية بحيث لا يمكن دمجها بدون فروق دقيقة.

بالطبع ، هذا لا يعني أن "كل شيء سيئ ولا تحتاج إلى استخدام Kotlin مع Java" ، ولكن هذا يعني أنه يجب عليك معرفة الفروق الدقيقة وأخذها بعين الاعتبار. في مؤتمر Mobius لدينا ، تحدث سيرجي ريابوف عن كيفية كتابة التعليمات البرمجية على Kotlin والتي يمكن الوصول إليها بسهولة من Java. وقد أحب الجمهور التقرير كثيرًا لدرجة أننا لم نقرر نشر مقطع فيديو فحسب ، بل عملنا أيضًا نسخة نصية لحبر:


لقد كنت أكتب Kotlin لأكثر من ثلاث سنوات ، الآن فقط على ذلك ، ولكن في البداية قمت بسحب Kotlin إلى مشاريع Java الحالية. لذلك ، طرح السؤال "كيفية ربط Java و Kotlin معًا" في طريقي كثيرًا.

في كثير من الأحيان عندما تضيف Kotlin إلى مشروع ، يمكنك أن ترى كيف ...

compile 'rxbinding:xyx' compile 'rxbinding-appcompat-v7:xyx' compile 'rxbinding-design:xyx' compile 'autodispose:xyz' compile 'autodispose-android:xyz' compile 'autodispose-android-archcomponents:xyz' 

... يتحول إلى هذا:

 compile 'rxbinding:xyx' compile 'rxbinding-kotlin:xyx' compile 'rxbinding-appcompat-v7:xyx' compile 'rxbinding-appcompat-v7-kotlin:xyx' compile 'rxbinding-design:xyx' compile 'rxbinding-design-kotlin:xyx' compile 'autodispose:xyz' compile 'autodispose-kotlin:xyz' compile 'autodispose-android:xyz' compile 'autodispose-android-kotlin:xyz' compile 'autodispose-android-archcomponents:xyz' compile 'autodispose-android-archcomponents-kotlin:xyz' 

تفاصيل العامين الماضيين: تكتسب المكتبات الأكثر شعبية أغلفة بحيث يمكن استخدامها من Kotlin بشكل اصطلاحي.

إذا كتبت في Kotlin ، فأنت تعلم أن هناك وظائف ملحق رائعة ، ووظائف مضمنة ، وتعبيرات lambda متوفرة من Java 6. وهذا رائع ، يجذبنا إلى Kotlin ، ولكن السؤال الذي يطرح نفسه. تعد إمكانية التشغيل التفاعلي مع Java واحدة من أكبر ميزات اللغة وأكثرها شيوعًا. إذا كنت تأخذ في الاعتبار جميع الميزات المدرجة ، فلماذا لا تكتب مكتبات فقط في Kotlin؟ سيعملون جميعًا بشكل مثالي خارج الصندوق مع Java ، ولن تحتاج إلى دعم كل هذه الأغلفة ، سيكون الجميع سعداء ومحتوى.

ولكن ، بالطبع ، من الناحية العملية ، ليس كل شيء ورديًا كما هو الحال في الكتيبات ، هناك دائمًا "سمة خط صغير" ، وهناك حواف حادة عند تقاطع Kotlin و Java ، واليوم سنتحدث عن هذا قليلاً.

حواف حادة

لنبدأ بالاختلافات. على سبيل المثال ، هل تعلم أنه في Kotlin لا توجد كلمات رئيسية متقلبة ، متزامنة ، صارمة ، عابرة؟ يتم استبدالها بتعليقات من نفس الاسم موجودة في حزمة kotlin.jvm. لذا ، فإن معظم الحديث يدور حول محتويات هذه الحزمة.

هناك الأخشاب - مثل تجريد المكتبة على قطع الأشجار من زيكا فارتانوف سيئ السمعة. يسمح لك باستخدامه في كل مكان في تطبيقك ، ويتحول كل شيء تريد إرسال السجلات فيه (إلى logcat ، أو إلى خادمك للتحليل ، أو الإبلاغ عن الأعطال ، وما إلى ذلك) إلى مكونات إضافية.

دعونا نتخيل على سبيل المثال أننا نريد كتابة مكتبة مماثلة ، فقط للتحليلات. فك الارتباط أيضًا.

 object Analytics { fun send(event: Event) {} fun addPlugins(plugs: List<Plugin>) {} fun getPlugins(): List<Plugin> {} } interface Plugin { fun init() fun send(event: Event) fun close() } data class Event( val name: String, val context: Map<String, Any> = emptyMap() ) 

نأخذ نفس نمط البناء ، لدينا نقطة دخول واحدة - هذا هو Analytics. يمكننا إرسال الأحداث هناك وإضافة الإضافات ومعرفة ما أضفناه بالفعل هناك.

البرنامج المساعد هو واجهة البرنامج المساعد الذي يلخص API تحليلي معين.

وفي الواقع ، تحتوي فئة الأحداث على المفتاح وسماتنا التي نرسلها. لا يتعلق التقرير هنا بما إذا كان الأمر يستحق استخدام الأغاني الفردية ، لذلك دعونا لا نولد holivar ، لكننا سنشاهد كيفية تمشيط هذا الشيء بأكمله.

الآن الغوص قليلا. فيما يلي مثال على استخدام مكتبتنا في Kotlin:

 private fun useAnalytics() { Analytics.send(Event("only_name_event")) val props = mapOf( USER_ID to 1235, "my_custom_attr" to true ) Analytics.send(Event("custom_event", props)) val hasPlugins = Analytics.hasPlugins Analytics.addPlugin(EMPTY_PLUGIN) // dry-run Analytics.addPlugins(listOf(LoggerPlugin("ALog"), SegmentPlugin))) val plugins = Analytics.getPlugins() // ... } 

من حيث المبدأ ، يبدو كما هو متوقع. نقطة دخول واحدة ، وتسمى الأساليب لا statics. حدث بدون معلمات ، حدث ذو سمات. نتحقق لمعرفة ما إذا كان لدينا مكونات إضافية ، ندفع مكوّنًا إضافيًا فارغًا من أجل تنفيذ نوع من "التشغيل الجاف". أو أضف بعض المكونات الإضافية الأخرى واعرضها وما إلى ذلك. بشكل عام ، حالات المستخدمين القياسية ، آمل أن يكون كل شيء واضحًا حتى الآن.

الآن دعونا نرى ما يحدث في جافا عندما نفعل الشيء نفسه:

 private static void useAnalytics() { Analytics.INSTANCE.send(new Event("only_name_event", Collections.emptyMap())); final Map<String, Object> props = new HashMap<>(); props.put(USER_ID, 1235); props.put("my_custom_attr", true); Analytics.INSTANCE.send(new Event("custom_event", props)); boolean hasPlugins = Analytics.INSTANCE.getHasPlugins(); Analytics.INSTANCE.addPlugin(Analytics.INSTANCE.getEMPTY_PLUGIN()); // dry-run final List<EmptyPlugin> pluginsToSet = Arrays.asList(new LoggerPlugin("ALog"), new SegmentPlugin()); // ... } 

تندلع الضجة مع INSTANCE على الفور في عيني ، وهي ممتدة ، ووجود قيم صريحة للمعلمة الافتراضية مع السمات ، وبعض الحروف بأسماء غبية. نظرًا لأننا بشكل عام ، اجتمعنا هنا لتحويل هذا إلى شيء مشابه للملف السابق مع Kotlin ، فلننتقل في كل لحظة لا نحبها ونحاول تكييفها بطريقة أو بأخرى.

لنبدأ بالحدث. نقوم بإزالة المعلمة Colletions.emptyMap () من السطر الثاني ، ويظهر خطأ مترجم. ما سبب ذلك؟

 data class Event( val name: String, val context: Map<String, Any> = emptyMap() ) 

يحتوي مُنشئنا على معلمة افتراضية نمرر القيمة إليها. نأتي من Java إلى Kotlin ، فمن المنطقي أن نفترض أن وجود معلمة افتراضية يولد منشئين: واحد ممتلئ بمعلمتين ، وواحد جزئي ، يمكن تحديد الاسم فقط. من الواضح أن المترجم لا يعتقد ذلك. دعونا نرى لماذا يعتقد أننا مخطئون.

أداتنا الرئيسية لتحليل جميع التقلبات والانعطافات لكيفية تحويل Kotlin إلى JVM bytecode - Kotlin Bytecode Viewer. في Android Studio و IntelliJ IDEA ، يقع في قائمة Tools - Kotlin - Show Kotlin Bytecode. يمكنك ببساطة الضغط على Cmd + Shift + A وكتابة Kotlin Bytecode في شريط البحث.



هنا ، بشكل مدهش ، نرى رمزًا ثانويًا لما يتحول إليه فصل Kotlin. لا أتوقع أن يكون لديك معرفة ممتازة بالبايت كود ، والأهم من ذلك ، لا يتوقع مطورو IDE ذلك أيضًا. لذلك ، جعلوا زر Decompile.

بعد النقر فوقه ، نرى رمز Java جيدًا تقريبًا:

 public final class Event { @NotNull private final String name; @NotNull private final Map context; @NotNull public final String getName() { return this.name; } @NotNull public final Map getContext() { return this.context; } public Event(@NotNull String name, @NotNull Map context) { Intrinsics.checkParameterIsNotNull(name, "name"); Intrinsics.checkParameterIsNotNull(context, "context"); super(); this.name = name; this.context = context; } // $FF: Synthetic method public Event(String var1, Map var2, int var3, DefaultConstructorMarker var4) { if ((var3 & 2) != 0) { var2 = MapsKt.emptyMap(); } // ... } 

نرى حقولنا ، getters ، المنشئ المتوقع مع معلمتين وسياق ، كل شيء يحدث بشكل جيد. وفيما يلي نرى المُنشئ الثاني ، وهنا مع توقيع غير متوقع: ليس بمعلمة واحدة ، ولكن لسبب ما مع أربعة.

هنا يمكنك أن تشعر بالحرج ، ولكن يمكنك أن تتسلق أعمق قليلاً وتفتش. بداية من الفهم ، سوف نفهم أن DefaultConstructorMarker هي فئة خاصة من مكتبة Kotlin القياسية ، تمت إضافتها هنا حتى لا يكون هناك تعارض مع المنشئين المكتوبين ، حيث لا يمكننا تعيين معلمة نوع DefaultConstructorMarker بأيدينا. والشيء المثير للاهتمام حول int var3 هو قناع البت للقيم الافتراضية التي يجب أن نستخدمها. في هذه الحالة ، إذا كان قناع البت يتطابق مع الاثنين ، فإننا نعلم أنه لم يتم تعيين var2 ، ولم يتم تعيين سماتنا ، ونستخدم القيمة الافتراضية.

كيف نصلح الوضع؟ للقيام بذلك ، هناك تعليق توضيحي خارقJvmOverloads من الحزمة التي تحدثت عنها بالفعل. علينا أن نعلقها على المنشئ.

 data class Event @JvmOverloads constructor( val name: String, val context: Map<String, Any> = emptyMap() ) 

وماذا ستفعل؟ دعونا ننتقل إلى نفس الأداة. الآن نرى منشئنا الكامل ، ومنشئ مع DefaultConstructorMarker ، و ، وها ، منشئ بمعلمة واحدة ، وهو متاح الآن من Java:

 @JvmOverloads public Event(@NotNull String name) { this.name, (Map)null, 2, (DefaultConstructorMarker)null); } 

وكما ترون ، فإنه يفوض كل العمل مع المعلمات الافتراضية إلى مُنشئنا باستخدام أقنعة البت. وبالتالي ، نحن لا ننتج معلومات حول القيمة الافتراضية التي نحتاج إلى وضعها هناك ، نحن فقط نفوض كل شيء في مُنشئ واحد. جميل نتحقق مما نحصل عليه من جانب جافا: المترجم سعيد وغير غاضب.

دعونا نرى ما لا نحبه بعد ذلك. نحن لا نحب هذا INSTANCE ، الذي يعتبر قاسيًا باللون الأرجواني. أنا لا أحب اللون الأرجواني :)



دعونا تحقق ، بسبب ما اتضح. دعونا نلقي نظرة على الرمز الثانوي مرة أخرى.

على سبيل المثال ، نسلط الضوء على دالة init ونتأكد من أن init تكون بالفعل غير ثابتة.



أي ، مهما يقول المرء ، نحتاج إلى العمل مع مثيل من هذا الفصل ونطلق عليه هذه الأساليب. ولكن يمكننا أن نجبر جيل كل هذه الأساليب على أن تكون ثابتة. هناك تعليق توضيحي رائعJvmStatic لهذا الغرض. دعنا نضيفه إلى التهيئة وإرسال الوظائف والتحقق مما يفكر فيه المترجم الآن.

نرى أنه تمت إضافة الكلمة الرئيسية الثابتة إلى الحرف التهيئة النهائية العامة () ، وأنقذنا أنفسنا من العمل مع INSTANCE. سوف نتحقق من ذلك في كود Java.

يخبرنا المترجم الآن أننا نستدعي الطريقة الثابتة من سياق INSTANCE. يمكن تصحيح هذا: اضغط على Alt + Enter ، وحدد "Cleanup Code" ، وفويلا ، يختفي INSTANCE ، كل شيء يبدو كما كان في Kotlin:

  Analytics.send(new Event("only_name_event")); 

الآن لدينا مخطط للعمل مع الأساليب الثابتة. أضف هذا التعليق التوضيحي أينما يهمنا:



والتعليق: إذا كانت الأساليب التي لدينا هي بالطبع طرق المثيل ، فعندئذ على سبيل المثال ، مع الخصائص ، ليس كل شيء واضحًا جدًا. يتم إنشاء الحقول نفسها (مثل المكونات الإضافية) على أنها ثابتة. ولكن يعمل المستوطنون والمستوطنون كطرق المثال. لذلك ، بالنسبة للممتلكات ، تحتاج أيضًا إلى إضافة هذا التعليق التوضيحي لجعل المستوطنين والرسومات ثابتة. على سبيل المثال ، نرى المتغير isInited ، أضف التعليق التوضيحيJvmStatic إليه ، والآن نرى في عارض Kotlin Bytecode أن طريقة isInited () أصبحت ثابتة ، كل شيء على ما يرام.

الآن دعنا ننتقل إلى كود Java ، "للتنظيف" ، وكل شيء يبدو مثل Kotlin ، باستثناء الفاصلة المنقوطة وكلمة جديدة - حسنًا ، لن تتخلص منها.

 public static void useAnalytics() { Analytics.send(new Event("only_name_event")); final Map<String, Object> props = new HashMap<>(); props.put(USER_ID, 1235); props.put("my_custom_attr", true); Analytics.send(new Event("custom_event", props)); boolean hasPlugins = Analytics.getHasPlugins(); Analytics.addPlugin(Analytics.INSTANCE.getEMPTY_PLUGIN()); // dry-run // ... } 

الخطوة التالية: نرى هذا getHasPlugins getter مع البادئات في وقت واحد. بالطبع ، لست خبيرًا كبيرًا في اللغة الإنجليزية ، ولكن يبدو لي أن هناك شيئًا آخر ضمنيًا هنا. لماذا يحدث هذا؟

كما عرفوا عن كثب مع Kotlin ، بالنسبة لأسماء العقارات الخاصة بالرسالة والمستوطنين يتم إنشاؤها وفقًا لقواعد JavaBeans. هذا يعني أن الحروف ستكون بشكل عام مع بادئات الحصول ، والبسط مع بادئات محددة. ولكن هناك استثناء واحد: إذا كان لديك حقل منطقي واسمه يحتوي على البادئة ، فسيتم البدء بـ getter. يمكن رؤية ذلك في مثال حقل isInited أعلاه.

لسوء الحظ ، يجب أن يتم استدعاء الحقول المنطقية بعيدًا دائمًا. لا يرضي isPlugins تمامًا ما نريد أن نظهره دلالة بالاسم. كيف نكون؟

وهذا ليس صعبًا بالنسبة لنا ، لأن هذا هو التعليق التوضيحي الخاص بنا (كما فهمت بالفعل ، سأكرر هذا كثيرًا اليوم). يسمح لك التعليق التوضيحيJvmName بتحديد أي اسم نريده (مدعوم بشكل طبيعي بواسطة Java). أضفه:

 @JvmStatic val hasPlugins @JvmName("hasPlugin") get() = plugins.isNotEmpty() 

دعونا نتحقق مما حصلنا عليه في Java: لم تعد طريقة getHasPlugins موجودة ، ولكن hasPlugins هي شيء بحد ذاته. هذا حل مشكلتنا ، مرة أخرى ، مع تعليق توضيحي واحد. الآن نحل جميع التعليقات التوضيحية!

كما ترى ، هنا نضع التعليق التوضيحي مباشرة على الفهم. ما سبب ذلك؟ مع حقيقة أنه تحت الملكية هو الكثير من كل شيء ، وليس من الواضح ما ينطبقJvmName. إذا قمت بنقل التعليق التوضيحي إلى val hasPlugins نفسها ، فإن المترجم لن يفهم ما يجب تطبيقه عليه.

ومع ذلك ، فإن Kotlin لديه أيضًا القدرة على تحديد مكان استخدام التعليقات التوضيحية مباشرةً. يمكنك تحديد getter الهدف ، الملف بأكمله ، المعلمة ، المفوض ، الحقل ، الخصائص ، وظائف ملحق المستقبل ، المعلمة setter و setter. في حالتنا ، البالغة هي مثيرة للاهتمام. وإذا فعلت ذلك ، فسيكون له نفس التأثير عندما قمنا بتعليق التعليق التوضيحي على الحصول على:

 @get:JvmName("hasPlugins") @JvmStatic val hasPlugins get() = plugins.isNotEmpty() 

وفقًا لذلك ، إذا لم يكن لديك مُدرب مُخصص ، فيمكنك إرفاقه مباشرة بممتلكاتك ، وسيكون كل شيء على ما يرام.

النقطة التالية التي تربكنا قليلاً هي "Analytics.INSTANCE.getEMPTY_PLUGIN ()". لم يعد الأمر هنا حتى باللغة الإنجليزية ، ولكن ببساطة: لماذا؟ الجواب هو نفسه ، ولكن أولاً مقدمة صغيرة.

من أجل جعل الحقل ثابتًا ، لديك طريقتان. إذا قمت بتعريف ثابت كنوع بدائي أو كسلسلة ، وداخل الكائن أيضًا ، فيمكنك استخدام الكلمة الأساسية const ، ثم لن يتم إنشاء عوامل ضبط getter وأشياء أخرى. سيكون ثابتًا عاديًا - ثابتًا نهائيًا خاصًا - وسيتم تحديده ، أي شيء جافا عادي تمامًا.

ولكن إذا كنت تريد عمل ثابت من كائن مختلف عن السلسلة ، فلن تتمكن من استخدام كلمة const لهذا الغرض. هنا لدينا فال EMPTY_PLUGIN = EmptyPlugin () ، وفقًا لها ، من الواضح أن هذا المولع الرهيب قد تم إنشاؤه. يمكننا إعادة تسميةJvmName مع تعليق توضيحي ، وإزالة هذه البادئة ، ولكن لا تزال طريقة - مع أقواس. لذا ، لن تعمل الحلول القديمة ، نحن نبحث عن حلول جديدة.

وهنا لهذا التعليق التوضيحي @ JvmField ، الذي يقول: "أنا لا أريد رسائل هنا ، ولا أريد مستوطنين ، اجعلوني حقلاً." ضعه أمام فال EMPTY_PLUGIN وتحقق من صحة كل شيء.



يعرض عارض Kotlin Bytecode القطعة المميزة التي تقف عليها حاليًا في الملف. نحن الآن نقف على EMPTY_PLUGIN ، وترى هنا أنه تتم كتابة نوع من التهيئة في المنشئ. والحقيقة هي أن البالغة لم تعد موجودة والوصول إليها للتسجيل فقط. وإذا نقرت على فك التحويل ، فسنرى ظهور "EmptyPlugin EMPTY_PLUGIN" النهائي الثابت العام ، وهذا بالضبط ما حققناه. جميل نتحقق من أن كل شيء يرضي الجميع ، ولا سيما المترجم. أهم شيء تحتاج إلى استرضائه هو المترجم.

الوراثة

لنأخذ استراحة من الكود ونلقي نظرة على الأدوية الجنيسة. هذا موضوع ساخن جدا. أو زلق ، الذي لم يعد يحب ذلك. جافا لها تعقيداتها الخاصة ، لكن Kotlin مختلفة. بادئ ذي بدء ، نحن قلقون بشأن الاختلاف. ما هذا

التباين هو طريقة لنقل المعلومات حول هرمية النوع من الأنواع الأساسية إلى المشتقات ، على سبيل المثال ، إلى الحاويات أو إلى الأدوية الجنيسة. هنا لدينا فئتي الحيوانات والكلب مع اتصال واضح للغاية: الكلب هو نوع فرعي ، والحيوان هو نوع فرعي ، والسهم يأتي من النوع الفرعي.



وما العلاقة التي ستكون لها مشتقاتها؟ دعونا نلقي نظرة على بعض الحالات.

الأول هو المكرر. لتحديد ما هو نوع فرعي وما هو نوع فرعي ، سنسترشد بقاعدة الاستبدال Barbara Liskov. يمكن صياغته على النحو التالي: "لا يجب أن يتطلب النوع الفرعي أكثر من ذلك ، ولا يقدم أقل من ذلك."

في حالتنا ، الشيء الوحيد الذي يفعله Iterator هو إعطائنا أشياء مكتوبة ، على سبيل المثال ، Animal. إذا قبلنا Iterator في مكان ما ، فيمكننا وضع Iterator هناك ، والحصول على Animal من الطريقة التالية () ، لأن الكلب هو أيضًا Animal. نحن نقدم ليس أقل ، ولكن أكثر ، لأن الكلب هو نوع فرعي.



أكرر: نحن نقرأ فقط من هذا النوع ، لذلك يتم الحفاظ على العلاقة بين النوع والنوع الفرعي هنا. وتسمى هذه الأنواع المتغير المشترك.

حالة أخرى: العمل. العمل هو وظيفة لا ترجع شيئًا ، ولا تأخذ معلمة واحدة ، ونكتب فقط إلى Action ، أي أنها تأخذ كلبًا أو حيوانًا منا.



وهكذا ، لم نعد هنا نقدم ، ولكن الطلب ، ويجب ألا نطلب المزيد. هذا يعني أن اعتمادنا يتغير. "لا أكثر" لدينا حيوان (حيوان أقل من كلب). وتسمى هذه الأنواع المتناقضة.

هناك حالة ثالثة - على سبيل المثال ، ArrayList ، التي نقرأ ونكتب منها. لذلك ، في هذه الحالة ، ننتهك إحدى القواعد ، نطلب المزيد للتسجيل (كلب ، وليس حيوان). لا ترتبط هذه الأنواع بأي شكل من الأشكال ، ويطلق عليها ثابتة.



لذلك ، في Java ، عندما تم تصميمه قبل الإصدار 1.5 (حيث ظهرت الأدوية البديلة) ، قاموا افتراضيًا بعمل مصفوفات مشتركة. هذا يعني أنه يمكنك تعيين مصفوفة من السلاسل إلى مصفوفة الكائنات ، ثم تمريرها في مكان ما إلى الطريقة التي تتطلب صفيف الكائنات ، ومحاولة دفع الكائن هناك ، على الرغم من أن هذه مصفوفة من السلاسل. كل شيء سوف يقع عليك.

بعد أن تعلموا من التجربة المريرة أنه لا يمكن القيام بذلك ، عند تصميم الأدوية الجنيسة ، قرروا "سنجعل المجموعات ثابتة ، ولن نفعل أي شيء معهم".

وفي النهاية اتضح أنه في مثل هذا الشيء الواضح على ما يبدو يجب أن يكون كل شيء على ما يرام ، ولكن في الواقع ليس على ما يرام:

 // Java List<Dog> dogs = new ArrayList<>(); List<Animal> animals = dogs; 

لكننا بحاجة إلى تحديد ما يمكننا ، بطريقة ما ، ما يمكننا فعله: إذا كنا نقرأ فقط من هذه الورقة ، فلماذا لا نتمكن من نقل قائمة الكلاب هنا؟ لذلك ، من الممكن أن يميز باستخدام حرف البدل نوع الاختلاف الذي سيحتوي عليه هذا النوع:

 List<Dog> dogs = new ArrayList<>(); List<? extends Animal> animals = dogs; 

كما ترى ، يشار إلى هذا الاختلاف في مكان الاستخدام ، حيث نعين الكلاب. لذلك ، يسمى هذا اختلاف موقع الاستخدام.

ما هي سلبيات هذا؟ الجانب السلبي هو أنه يجب عليك تحديد حرف البدل المخيف هذا أينما تستخدم API الخاص بك ، وكل هذا مثمر للغاية في التعليمات البرمجية. ولكن في Kotlin لسبب ما ، يعمل مثل هذا الشيء خارج الصندوق ، ولا تحتاج إلى تحديد أي شيء:

 val dogs: List<Dog> = ArrayList() val animals: List<Animal> = dogs 

ما سبب ذلك؟ مع حقيقة أن الأوراق مختلفة في الواقع. تعني القائمة في Java الكتابة ، بينما في Kotlin تكون للقراءة فقط ، وليس ضمنيًا. لذلك ، من حيث المبدأ ، يمكننا أن نقول على الفور أننا نقرأ فقط من هنا ، وبالتالي يمكننا أن نكون متغيرين. ويتم تعيين هذا بالضبط في تعريف النوع بالكلمة الأساسية للخارج التي تحل محل حرف البدل:

 interface List<out E> : Collection<E> 

وهذا ما يسمى اختلاف موقع الإعلان. وهكذا ، أشرنا إلى كل شيء في مكان واحد ، وحيث نستخدمه ، لم نعد نتناول هذا الموضوع. وهذا nishtyak.

عودة الى الكود

دعونا نعود إلى أعماقنا. هنا لدينا طريقة addPlugins ، وهي تأخذ قائمة:

 @JvmStatic fun addPlugins (plugs: List<Plugin>) { plugs.forEach { addPlugin(it) } }    ,  , List<EmptyPlugin>, ,     : <source lang="java"> final List<EmptyPlugin> pluginsToSet = Arrays.asList(new LoggerPlugin("Alog"), new SegmentPlugin()); 

نظرًا لحقيقة أن القائمة في Kotlin هي متغير مشترك ، يمكننا بسهولة تمرير قائمة ورثة البرنامج المساعد هنا. كل شيء سيعمل ، المترجم لا يمانع. ولكن نظرًا لحقيقة وجود اختلاف في موقع الإعلان حيث حددنا كل شيء ، فلا يمكننا بعد ذلك التحكم في الاتصال بـ Java في مرحلة الاستخدام. ولكن ماذا يحدث إذا أردنا حقًا وجود ورقة إضافية ، فلا نريد أي ورثة هناك؟ لا توجد محددات لهذا ، ولكن ماذا؟ هذا صحيح ، هناك تعليق توضيحي. ويطلق على التعليق التوضيحيJvmSuppressWildcards ، أي أننا نعتقد افتراضيًا أن هذا هو النوع الذي يحتوي على حرف بدل ، فإن النوع هو المتغير المشترك.

 @JvmStatic fun addPlugins(plugs: List<@JvmSuppressWildcards Plugin>) { plugs.forEach { addPlugin(it) } } 

بالحديث عن SuppressWildcards ، نقوم بإلغاء كل هذه الأسئلة ، وتغير توقيعنا بالفعل. حتى أكثر من ذلك ، سأوضح لك كيف يبدو كل شيء في الرمز البيني:



سأزيل التعليق التوضيحي من الرمز في الوقت الحالي. هنا طريقتنا. ربما تعلم أن محو النوع موجود. وفي الرمز الفرعي الخاص بك لا توجد معلومات حول أي نوع من الأسئلة كانت هناك ، بشكل عام ، الأدوية العامة. لكن المترجم يتبع هذا ويوقعه في التعليقات على الرمز الثانوي: وهذا هو نوع السؤال.



الآن نقوم بإدراج التعليق التوضيحي مرة أخرى ونرى أن هذا هو نوعنا دون التشكيك.



الآن سيتوقف رمزنا السابق عن الترجمة على وجه التحديد لأننا قطعنا أحرف البدل. يمكنك أن ترى بنفسك.

قمنا بعمل أنواع متغيرة. .

, List . , getPlugins, . ? , , , . , Java.

 final List<Plugin> plugins = Analytics.getPlugins(); displayPlugins(plugins); Analytics.getPlugins().add(new EmptyPlugin()); 

, - , , - . , . , - .

. Kotlin , , , , , wildcards Java. , , . , List, Plugin. , , , : Plugin, .

. , , usecase, - , .

, , , - . , Java. Kotlin List — read only-, , Java — ? , List wildcard. , . @JvmWildcard : , . , Java . Java « ?»:



List<? extends Plugin>, « ?» , , . script kiddie, « , , , ArrayList, ». , ArrayList , .

 ((ArrayList<Plugin>) Analytics.getPlugins()).add(new EmptyPlugin()); 

, , , defensive-, - . , , , script kiddies .

 @JvmStatic fun getPlugins(): List<@JvmWildcard Plugin> = plugin.toImmutableList() 

, @JvmSuppressWildcard , , , , .

, . , : .

Java. , :

 @Override public void send(@NotNull Event event) throws IOException 

:

 interface Plugin { fun init() /** @throws IOException if sending failed */ fun send(event: Event) // ... } 

Kotlin checked exception. : . , , . Java -. : « Throws - , »:



-, Kotlin? , …

@Throws, . throws- . , IOExeption:

 open class EmptyPlugin : Plugin { @Throws(IOException::class) override fun send(event: Event) {} // ... } 

:

 interface Plugin { fun init() /** @throws IOException if sending failed */ @Throws(IOException::class) fun send(event: Event) // ... } 

? , Java, exception, . , . , - , , @JvmName. .

, Java . …

 package util fun List<Int>.printReversedSum() { println(this.foldRight(0) { it, acc -> it + acc }) } @JvmName("printReversedConcatenation") fun List<String>.printReversedSum() { println(this.foldRight(StringBuilder()) { it, acc -> acc.append(it) }) } 

, Java , . , IDE . , ? , , , List, List. , type erasure. :



, , top-level c. printReversedSum List, List. Kotlin- , Java- . , kotlin.jvm , Java , , Kotlin . — , concatenation — , .

. . extension- reverse.

 inline fun String.reverse() = StringBuilder(this).reverse().toString() inline fun <reified T> reversedClassName() = T::class.java.simpleName.reverse() inline fun <T> Iterable<T>.forEachReversed(action: (T) -> Unit) { for (element in this.reversed()) action(element) } 

reverse , ReverserKt.

 private static void useUtils() { System.out.println(ReverserKt.reverse("Test")); SumsKt.printReversedSum(asList(1, 2, 3, 4, 5)); SumsKt.printReversedConcatenation(asList("1", "2", "3", "4", "5")); } 

, , . , , Java, - . . ? , @JvmName, , .

, , , , , .

 @file:Suppress("NOTHING_TO_INLINE") @file:JvmName("ReverserUtils") 

Java ReverserKt, , ReverserUtils . « 2.1» — , top-level , . , , sums.kt SumsKt, , reversing ReverserUtils. @JvmName, «ReverserUtils», , , , .

, , « , -». ? @JvmMultifileClass, , , .

"@file:JvmMultifileClass", SumsKt ReverserUtils, — . !

, . , , . , , , @JvmName Kotlin.

Kotlin-

, , . , Kotlin- .

, inline-. Kotlin , , Java ? , , , Java. , , Kotlin-only , dex count limit. Kotlin , .

Reified type parameters. Kotlin, - , Java . Kotlin-only , Kotlin, Java reified, .

java.lang.Class. , Java, . . « Retrofit», ( , ):

 class Retrofit private constructor( val baseUrl: String, val client: Client ) { fun <T : Any> create(service: Class<T>): T {...} fun <T : Any> create(service: KClass<T>): T { return create(service.java) } } 

, Java, , KClass, , extension-, KClass Class, Class KClass ( Kotlin, ).

, . Kotlin- KClass, Reified-, :

 inline fun <reified T : Any> create(): T { return create(T::class.java.java) 

. Kotlin , . val api = retrofit.create(Api::class) val api = retrofit.create<Api>() , ::class . Reified-, -.

Unit. Unit, , void Java, . . , . - Scala, Scala , - , , , void.

Kotlin . Kotlin 22 , - . , , Unit, void, Unit. . , Unit? , . .

 inline fun <T> Iterable<T>.forEachReversed(action: (T) -> Unit) { for (element in this.reversed()) action(element) } 

Kotlin: , method reference, , , .

 private fun useMisc() { listOf(1, 2, 3, 4).forEachReversed(::println) println(reversedClassName<String>()) } 

Java? Java :

 private static void useMisc() { final List<Integer> list = asList(1, 2, 3, 4); ReverserUtils.forEachReversed(list, integer -> { System.out.println(integer); return Unit.INSTANCE; }); 

- , - . Void , . , void, . , , , . , Unit . null, . , .

: Typealiases — , , Kotlin, Java, , , . , - . Java- .

: visibility. , internal visibility. , Kotlin package private, - , public. internal. Internal — , . Retrofit internal- validate.

 internal fun validate(): Retrofit { println("!!!!!! internal fun validate() was called !!!!!!") return this } 

Kotlin, . Java? validate? , , internal public. , Kotlin bytecode viewer.



public, , , , , , API . - 80 , .

Java :

 final Api api = retrofit .validate$production_sources_for_module_library_main() .create(Api.class); api.sendMessage("Hello from Java"); } 

. , , , . , let me explain this to you. , ?

 final Api api = retrofit .validate$library() .create(Api.class); api.sendMessage("Hello from Java"); } 

. « ?» … MAGIC!

, - internal, , API. script kiddie Kotlin Bytecode Viewer, . internal visibility.

, . , , , , SkillsMatter. .

, Kotlin-. , - , . Kotlin bytecode viewer .

شكرا لك!

, : 8-9 Mobius , . — , .