الفرق بين المراجعتين لصفحة: «Kotlin/delegation»
أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:الانتقال الفرعيّ Delegation في Kotlin}}</noinclude> أثبت نموذج الانتقال الفرعيّ فعّاليته كب...' |
ط تعديل مصطلح متحول |
||
(1 مراجعات متوسطة بواسطة نفس المستخدم غير معروضة) | |||
سطر 1: | سطر 1: | ||
<noinclude>{{DISPLAYTITLE:الانتقال الفرعيّ Delegation في Kotlin}}</noinclude> | <noinclude>{{DISPLAYTITLE:الانتقال الفرعيّ Delegation في Kotlin}}</noinclude> | ||
أثبت نموذج الانتقال الفرعيّ فعّاليته كبديلٍ جيّدٍ عن وراثة تعريف الاستخدام (implementation inheritance) إذ تدعم لغة 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> تفيد بأنّ | </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
".