الفرق بين المراجعتين لصفحة: «Kotlin/delegation»

من موسوعة حسوب
أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:الانتقال الفرعيّ Delegation في Kotlin}}</noinclude> أثبت نموذج الانتقال الفرعيّ فعّاليته كب...'
 
ط تعديل مصطلح متحول
 
(1 مراجعات متوسطة بواسطة نفس المستخدم غير معروضة)
سطر 1: سطر 1:
<noinclude>{{DISPLAYTITLE:الانتقال الفرعيّ Delegation في Kotlin}}</noinclude>
<noinclude>{{DISPLAYTITLE:الانتقال الفرعيّ Delegation في Kotlin}}</noinclude>
أثبت نموذج الانتقال الفرعيّ فعّاليته كبديلٍ جيّدٍ عن وراثة تعريف الاستخدام (implementation inheritance) إذ تدعم لغة Kotlin هذه الميّزة مما بشكل طبيعيّ دون الحاجة إلى أيّ نوع قياسيّ من الشيفرات، وبالتالي فإنّ الصنف المُشتقّ (<code>Derived</code>) يرِث من الواجهة (<code>Base</code>) وينقل فرعيًا (delegate) كلَّ توابعه العامّة (public methods) إلى كائنٍ مُحدَّدٍ، كما في الشيفرة الآتية:<syntaxhighlight lang="kotlin">
أثبت نموذج الانتقال الفرعيّ فعّاليته كبديلٍ جيّدٍ عن وراثة تعريف الاستخدام (implementation inheritance) إذ تدعم لغة Kotlin هذه الميّزة بشكلٍ طبيعيّ دون الحاجة إلى أيّ نوع قياسيّ من الشيفرات، وبالتالي فإنّ الصنف المُشتقّ (<code>Derived</code>) يرِث من الواجهة (<code>Base</code>) وينقل فرعيًا (delegate) كلَّ توابعه العامّة (public methods) إلى كائنٍ مُحدَّدٍ، كما في الشيفرة الآتية:<syntaxhighlight lang="kotlin">
interface Base {
interface Base {
     fun print()
     fun print()
سطر 15: سطر 15:
     Derived(b).print() // سيطبع القيمة 10
     Derived(b).print() // سيطبع القيمة 10
}
}
</syntaxhighlight>إذ إنّ عبارة <code>by</code> في قائمة النوع الأعلى (supertype) للصنف <code>Derived</code> تفيد بأنّ المتحول <code>b</code> سيُخزَّن داخليًا في كائنات الصنف <code>Derived</code> ، وسيُولِّد المترجِم (compiler) كافَّة التوابع الموجودة في <code>Base</code> والتي ستوجَّه للمتحول <code>b</code>.
</syntaxhighlight>إذ إنّ عبارة <code>by</code> في قائمة النوع الأعلى (supertype) للصنف <code>Derived</code> تفيد بأنّ المعامل <code>b</code> سيُخزَّن داخليًا في كائنات الصنف <code>Derived</code> ، وسيُولِّد المترجِم (compiler) كافَّة التوابع الموجودة في <code>Base</code> والتي ستوجَّه للمعامل <code>b</code>.


وتبقى إعادة التعريف (override) فعّالةً لأن المُترجِم سيستخدِم إعادة تعريف الاستخدام (override implementations) الموجودة بدلًا من تلك المنقولة فرعيًّا للكائن؛ أيّ إذا أضفنا إعادة التعريف: <code>override fun print() { print("abc") }‎</code> للصنف <code>Derived</code> فستظهر العبارة "<code>abc</code>" بدلًا من القيمة "<code>10</code>".
وتبقى إعادة التعريف (override) فعّالةً لأن المُترجِم سيستخدِم إعادة تعريف الاستخدام (override implementations) الموجودة بدلًا من تلك المنقولة فرعيًّا للكائن؛ أيّ إذا أضفنا إعادة التعريف: <code>override fun print() { print("abc") }‎</code> للصنف <code>Derived</code> فستظهر العبارة "<code>abc</code>" بدلًا من القيمة "<code>10</code>".

المراجعة الحالية بتاريخ 16:27، 4 يوليو 2018

أثبت نموذج الانتقال الفرعيّ فعّاليته كبديلٍ جيّدٍ عن وراثة تعريف الاستخدام (implementation inheritance) إذ تدعم لغة Kotlin هذه الميّزة بشكلٍ طبيعيّ دون الحاجة إلى أيّ نوع قياسيّ من الشيفرات، وبالتالي فإنّ الصنف المُشتقّ (Derived) يرِث من الواجهة (Base) وينقل فرعيًا (delegate) كلَّ توابعه العامّة (public methods) إلى كائنٍ مُحدَّدٍ، كما في الشيفرة الآتية:

interface Base {
    fun print()
}

class BaseImpl(val x: Int) : Base {
    override fun print() { print(x) }
}

class Derived(b: Base) : Base by b

fun main(args: Array<String>) {
    val b = BaseImpl(10)
    Derived(b).print() // سيطبع القيمة 10
}

إذ إنّ عبارة by في قائمة النوع الأعلى (supertype) للصنف Derived تفيد بأنّ المعامل b سيُخزَّن داخليًا في كائنات الصنف Derived ، وسيُولِّد المترجِم (compiler) كافَّة التوابع الموجودة في Base والتي ستوجَّه للمعامل b.

وتبقى إعادة التعريف (override) فعّالةً لأن المُترجِم سيستخدِم إعادة تعريف الاستخدام (override implementations) الموجودة بدلًا من تلك المنقولة فرعيًّا للكائن؛ أيّ إذا أضفنا إعادة التعريف: override fun print() { print("abc") }‎ للصنف Derived فستظهر العبارة "abc" بدلًا من القيمة "10".

مصادر