مظهر Kotlin هو مكافأة مهمة للمطورين. إن اللغة عالية المستوى التي تتكامل بسهولة مع Java توسع بشكل كبير قدرات المبرمجين. ومع ذلك ، فإننا نواجه باستمرار في أي لغة بعض المشاكل ، والتي ، على العكس من ذلك ، تخلق قيودًا ، وبالطبع لم يكن كوتلن استثناءً. سنتحدث عنها اليوم.
كان Kotlin متحمسًا للمجتمع ، حيث تبسط لغة البرمجة الجديدة إلى حد كبير كتابة التعليمات البرمجية ، لتحل محل Java. هذا ملحوظ بشكل خاص على Android ، حيث تظهر إصدارات جديدة من Java ، بعبارة ملطفة ، "مع صرير". يتم تحديث العديد من الأجهزة بتأخيرات طويلة ، وأكثر من ذلك - فهي لا تتلقى تحديثات البرامج الثابتة على الإطلاق. في أفضل الأحوال ، ينتهي دعم الجهاز بعد عامين تقريبًا من إصداره ، والذي يعد بتحديث نظام واحد بحد أقصى. ومع ذلك ، يستمر الناس في استخدام الأجهزة ، مما يعني أن على المطورين الاعتماد على أحدث إصدار من Android 8 (حتى الآن) ، وعلى Android 5 ، أو حتى الإصدارات الأقدم ، حيث لا يوجد بالتأكيد أحدث ، ولكن حتى التنفيذ الحالي لـ Java. كمرجع ، الآن يبلغ إجمالي حصة Android 7 و 8 - تلك الإصدارات حيث يتم دعم Java 8 بواسطة مكتبات النظام - 42.9٪ ، والباقي هو Java 7.
قد يقول البعض أن Java تم إهمالها. ولكن هناك أيضًا رأي مفاده أن Java هي لغة جيدة "كما هي" ولا يجب لمسها. إنه مثل GCD (أكبر عامل مشترك) في الرياضيات. يحتوي على مجموعة من وظائف الرجل ، وبالنسبة لأولئك الذين يحتاجون إلى ميزات إضافية اليوم ، تتوفر لغات خاصة تعمل بالفعل على JVM. لقد ولدت بالفعل الكثير من هذه اللغات: Scala و Clojure و JRuby و Jython و Groovy وغيرها ، الأقل شهرة. ومع ذلك ، فإن Kotlin لديه عدد من المزايا. تتيح هذه اللغة للمبرمج مزيدًا من الحرية: فهي تسمح لك باستخدام الأجزاء الجاهزة في جافا في نفس الوقت ، والجمع بين التعليمات البرمجية القديمة والجديدة.
ولكن مع كل مزايا اللغة الجديدة ، التي لا نزاع فيها بأي شكل من الأشكال ، خلال عملية التطوير ، تم العثور على بعض العيوب فيها. واليوم سيكون من المثير للاهتمام سماع رأي الزملاء حول ما إذا كانوا يتدخلون في العمل بنفس الطريقة التي نقوم بها.
لا يمكن إخفاء العرض؟
تعد الحزم ، كالمعتاد ، طريقة شائعة إلى حد ما لتنظيم الفصول حسب مساحة الاسم. لكن زياداتهم ليست هذا فقط ، بل إنها تعمل أيضًا في جاوة كوسيلة للحد من ظهور الطبقات وأعضائها.
دعني أذكرك أنه في Java هناك 4 فئات مختلفة تسمح لك بالتمييز بين الرؤية. لا يوجد سوى اثنين منهم للفصول - يمكن رؤيتها إما داخل الحزمة (الحزمة الخاصة) أو مفتوحة تمامًا (عامة). ولكن يمكن بالفعل جعل الطريقة أو الحقل خاصًا (لن يكون الوصول إليه متاحًا خارج الفصل) ، ولا يكون مرئيًا إلا للحزمة (الحزمة الخاصة) ، ويمكن صنعها بحيث تكون الطريقة مرئية أيضًا للورثة ، في عبوتها وخارجها (محمي) ، و يمكنك أيضًا جعلها مرئية للجميع (عامة).
قدمت Java 9 القدرة على تقسيم التعليمات البرمجية إلى وحدات ، والآن أصبح من الممكن جعل جزء من التعليمات البرمجية مرئيًا في كل مكان داخل الوحدة ، ولكن ليس من الخارج. وتبين أنها مفيدة جدًا لبناء واجهة برمجة تطبيقات معقولة.
في كلمة واحدة ، الخيارات في Java أكثر من كافية. ولكن في Kotlin لسبب ما ، اقتصروا على تقديم الرؤية العامة والخاصة ، وكذلك رؤية الورثة. بالإضافة إلى ذلك ، فقد أدخلوا تمييزًا حسب الوحدات ، ولكن أصبح من المستحيل التمييز بين الوصول إلى الأساليب والفئات حسب الحزم. لم تعد الوحدة عبارة عن بناء للغة نفسها ، وغالبًا ما يفهم الناس أشياء مختلفة تمامًا حسب هذا المصطلح. يعرّف Kotlin الوحدة رسميًا بأنها "
مجموعة من ملفات Kotlin التي تم تجميعها معًا ."
الصيد هو أن الوحدة النمطية ، كقاعدة عامة ، تؤدي إلى تكاليف موارد إضافية. في نفس الوقت ، إذا قمت بإنشاء حزمة منفصلة ووضعت فئات فيها بوظائف مرئية فقط في هذه الحزمة ، فلا توجد مشاكل ، لأنه سيتم تجميع جميع الحزم معًا ولن تكون هناك حاجة إلى موارد إضافية.
هذا واضح بشكل خاص إذا قمت ، على سبيل المثال ، بجمع المشاريع في Gradle ، كالمعتاد ، يتم تجميع تطبيقات Android. عادة ما تكون الوحدات كبيرة نسبيًا بحيث تكون وحدة وظيفية كاملة. داخل وحدة واحدة ، لا يمكن جعل الطريقة مرئية لأحدها ولا تكون مرئية للفئات الأخرى. وإذا أردنا أن نجعل ظهور الأساليب أكثر دقة ، تنشأ مشكلة.
هنا ، أريد أن أذكر الحزم على الفور ، لأنه في Kotlin لم يختف هذا الجوهر ، ولكن للأسف ، لا يؤثر على الرؤية. بالطبع ، يمكنك دائمًا إنشاء المزيد من الوحدات النمطية ، ولكن نظرًا لميزات Gradle ، فهذا ببساطة غير منطقي: ستنخفض سرعة البناء. نعم ، من الممكن وضع الفصول في ملف واحد ، ولكن في حالة مشروع كبير ، سيصبح الملف "ثقيلًا" حقًا. لذلك ، أود أن أحصل على طريقة أخرى للاختباء ، على سبيل المثال ، على غرار جافا.
لا تعالجها ... حتى لو كانت ضرورية
والثاني مثير للجدل إلى حد ما (لأن البعض يعتبر استخدامه أخبارًا سيئة) ، ولكن مع ذلك ، فإن النقص هو عدم وجود استثناءات محددة. هذه الأدوات موجودة في Java ، لكن Kotlin قرر عدم تنفيذها. تحتوي
الوثائق الرسمية على مثال حول الواجهة القابلة للإلحاق. يمكنك إرفاق سلاسل بـ Appendable ، وبما أن السلاسل يمكنها الاتصال بالكائنات المتعلقة بـ I / O ، على سبيل المثال ، عند الكتابة إلى ملف أو بالشبكة ، فمن المحتمل أن تحصل على IOException عند استدعاء طرق الواجهة. ومثل هذه الحالات تجعل استخدام الاستثناءات المحددة غير ملائم.
يشرح منشئو اللغة حجتهم على النحو التالي: إذا استخدمنا StringBuilder ، والوصول إليها من خلال Appendable ، اتضح أننا بحاجة إلى معالجة IOException ، حتى إذا كنت متأكدًا من أنها لا يمكن أن تحدث بشكل أساسي:
Appendable log = new StringBuilder(); try { log.append(message); } catch (IOException e) {
مخرج من الموقف: الاستثناء "تم القبض عليه" ، لكنهم لا يفعلون شيئًا به ، وهو بالطبع ليس جيدًا. ومع ذلك ، يبرز السؤال: إذا عملنا بشكل واضح مع StringBuilder من خلال واجهة Appendable - فلماذا لا نتفاعل مباشرة مع StringBuilder؟ هناك فرق مهم: عند العمل مع Appendable ، إذا لم نكن نعرف ما هو التنفيذ المحدد الذي يكمن تحته ، يصبح استثناء الإدخال / الإخراج ممكنًا حقًا ، لكن StringBuilder لن يعطيه بالضبط ، ويتم الإعلان عن الطرق المقابلة فيه ، على الرغم من أنها تنفيذ الواجهة. لذلك المثال ضيق جدا ...
من المثير للاهتمام بشكل خاص أن مؤلفي الوثائق يشيرون إلى الفصل 77 في Java الفعال ، والذي ينص على أنه لا يمكن اكتشاف الاستثناءات وتجاهلها. ولكن فقط في الفصول التالية مكتوب أن الاستثناءات المحددة يمكن ويجب استخدامها إذا تم ذلك بحكمة. إذا تم اقتباس ذلك بشكل انتقائي ، يمكن تبرير أي وجهة نظر.
ونتيجة لذلك ، نجح مطورو Kotlin في جعل جميع الأساليب ، من حيث الجوهر ، يمكن أن تطرح نوعًا من الاستثناء. ولكن أين هي أدوات معالجة الأخطاء في اللغة الجديدة؟ كيف نفهم الآن أين قد يظهر استثناء؟ على مستوى اللغة ، للأسف ، لا نجد مساعدة في هذه الأمور ، وحتى مع شفرة المصدر (وهي بعيدة عن أن تكون متاحة دائمًا دون مراعاة الحيل المختلفة) ، من الصعب فهم ما يجب فعله في كل موقف محدد.
إذا سألت المطورين سؤالاً ، فإنهم ببساطة يتجاهلون أكتافهم ويقولون أنه
في اللغات الأخرى لا توجد استثناءات محددة ولا شيء ، بل يقومون أيضًا بإنشاء برامج كبيرة وموثوقة. لكنهم يكتبون بنجاح بلغات فاشلة بصراحة ، هذه ليست حجة. في StackOverflow ، يقولون لسؤال مماثل "
أنت بحاجة إلى قراءة الوثائق " - إجابة جيدة ومريحة للغاية في مثل هذه المواقف. فقط الوثائق قد لا تكون موجودة ، قد تكون غير مكتملة أو قديمة - المترجم لا يتحقق منها. أخيرًا ، قد لا تجد الجواب فيه.
نعم ، صحيح أن التحقق من الاستثناءات يمكن أن يؤدي إلى واجهات برمجة تطبيقات غير ملائمة. عند التحقق من وجود استثناءات من الواضح أنها زائدة عن الحاجة حتى يكون المترجم "راضياً" ، يجب أن تكتب try ... catch وأنشئ بالفعل رمزًا غير هام ، لأنه لا يتم فعل أي شيء عند معالجة هذه الاستثناءات. وحقيقة أنه من غير المناسب استخدامها في التعليمات البرمجية الوظيفية هي أيضًا صحيحة. لكن الاستثناءات المحددة هي مجرد أداة يمكن استخدامها بكفاءة عالية عند الضرورة.
من غير الواضح لماذا استغلت اللغة هذه الفرصة ، إذا كانت فلسفة Kotlin هي الثقة في المزيد من الأدوات للمبرمج (على الأقل ، بدا لنا) ، وإذا كان مؤلف الشفرة يمكن أن يصف بشكل صحيح أين سيكون هناك أي استثناءات ، فلماذا لا تصدقه؟ خذ نفس العوامل المثقلة التي تم إزالتها من Java ، لأنها يمكن أن تؤدي إلى ظهور واجهات برمجة التطبيقات بإجراءات غير واضحة - كان هذا لحماية المبرمجين من أنفسهم. على النقيض من ذلك ، فإن Kotlin لديه القدرة على زيادة التحميل على المشغلين والقيام بأشياء أخرى كثيرة - فلماذا لا توجد استثناءات محددة؟ هل كان بمقدور المبدعين فعل ذلك لأنه ببساطة لم يكن مثل Java؟
نحن في انتظار التغيير ...
الحد الأقصى الذي يمكننا الاعتماد عليه في Android هو Java 7 أو Java 8 (ولكن مع بعض القيود والمحاذير) ، بينما تقترب Java 11 بالفعل. باستخدام Kotlin ، البرمجة على Android أسهل بكثير ، يتم تقليل عدد أسطر النص .
لا يسع المرء إلا أن يأمل أن يكمل المطورون هذه اللغة المفيدة للغاية بتلك الميزات غير المتوفرة اليوم لأسباب واضحة. ربما في الإصدارات المستقبلية ، ستكون هناك أدوات جديدة لتحليل الاستثناءات في IDE ، بالإضافة إلى فئات الخصوصية الجديدة. ولكن ، على ما يبدو ، هذا هو الحال في أفضل حالة للمستقبل البعيد ، حيث لم يبد مطورو اللغة حتى أي وعود.