هل سيكون بناء جملة التكوين إضافة مفيدة إلى Java؟[مغلق]

Question

أولاً، لا أعرف شيئًا تقريبًا عن نظرية اللغة، وبالكاد أعرف أي لغة أخرى باستثناء لغة جافا، لكن كانت لدي فكرة أعتقد أنها ستكون رائعة، ولكن أريد منكم أن تخبروني:
أ:لماذا تمتص
ب:كيف حصلت اللغة X على ذلك لسنوات
ج:كيف تمتص عقلي
د:كل ما ورداعلاه

ستمنح الفكرة التركيب نفس سهولة إعادة استخدام التعليمات البرمجية extends يفعل.

لذلك إذا كان لديك فصل مثل هذا:

public interface A {  
    public void methodInA();  
}

وبعد ذلك كان لديك فصل مثل هذا:

public class B {  
    private composed A;
    public B() {
        // construct A within constructor
    }
}

ستتمكن بعد ذلك من القيام بذلك:

B myB = new B();
myB.methodInA();

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

@Overrides
public void methodInA(){
    // B's own delegation method
}

تشمل العيوب ما يلي:

• يتم إخفاء الأساليب في التعليمات البرمجية المصدر، مما يجعل مصدر المكالمة أقل وضوحًا، ولكن هذا هو الحال أيضًا مع extends
• إذا كانت الحقول المكونة تشترك في نفس توقيع الطريقة، فيجب حل التعارض (كيف تحل الواجهات المتعارضة هذا؟)
• إذا كنت تريد أن يكون لديك عدة حقول مكونة من نفس النوع، فسيكون هناك تعارض واضح بشأن الحقل الذي سيتم التفويض إليه
• ربما 100 شيء آخر لم أفكر فيه

كما قلت، من الواضح أنني لست مُنظِّرًا لغويًا، ولم أقضي وقتًا طويلًا في التفكير في الأمر، لقد خطرت الفكرة في ذهني للتو وأردت أن أعرف مدى خطأي.أعتقد فقط أنه سيكون رائعًا نوعًا ما.

Answer 1

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

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

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

public class Foo {

  @Delegate(IBar.class)
  private Bar bar;

  // initialize bar via constructor or setter
}

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

public Baz method1(Qux val) {
  return bar.method1(val);
}

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

الآن بعد أن كتبت هذا يبدو رائعًا نوعًا ما.ربما سألعب معها الأسبوع المقبل.سأقوم بتحديث هذا إذا تمكنت من معرفة أي شيء.

Answer 2

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

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

Answer 3

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

ولكن ماذا يحدث إذا كان لديك مثيلات متعددة لـ A؟كيف سيتم حل استدعاء الأسلوب؟في كثير من الأحيان، يتضمن التكوين ارتباطًا واحدًا إلى العديد، لذلك يحتوي B على العديد من مثيلات A.ما يحدث بعد ذلك؟

وأنا أتفق مع العيوب المذكورة.قد يسبب ببساطة الكثير من الارتباك أكثر مما يستحق.

Answer 4

تحقق مما يسمى "Mixins" في بعض اللغات، و"Roles" في نظام Perl 5 Moose OO.

Answer 5

هناك أيضا الفرق بين تعبير و تجميع لاعتبار.كيف يعرف المترجم ما إذا كنت تقصد العلاقات "is-a" أو "has-a"؟

• هل يصبح الرسم البياني للكائن بالكامل مؤهلاً لجمع البيانات المهملة أم رأس الرسم البياني فقط؟

يوفر زوجان من أدوات وأطر رسم خرائط ORM الموجودة فوقها/حولها belongsTo أو has-many العلاقات بين الكائنات المستمرة وبعضها يوفر أيضًا الحذف المتتالي (للتكوين).لا أعرف جهة واحدة توفر السكر النحوي البسيط الذي تبحث عنه.

في الواقع، بعد التفكير مرة أخرى، قد توفر لغة (مصطلحات) MetaClass وMetaProgramming الخاصة بـ Groovy شيئًا مشابهًا جدًا، مع تفويض "السحر التلقائي".

Answer 6

يُسمح بالوراثة المتعددة في لغة C++، وأنا أعلم أن الأمر مختلف ولكنه يسير على نفس عملية التفكير.تم تصميم Java بحيث لا تسمح بالوراثة المتعددة، بحيث يكون هناك قدر أقل من الارتباك، وبالتالي الأخطاء والاستغلالات.

ما اقترحته يتعارض بشكل مباشر مع مبادئ Java.

بعد قولي هذا، سيكون رائعًا (ليس مفيدًا بالضرورة).أنا مبرمج جافا قمت بالتبديل من لغة C++.أحب أن أكون قادرًا على ارتكاب أخطائي.