وراثت کلاس داده با Delegation در کاتلین – از صفر تا صد

فرض کنید پروژه‌ای در کاتلین دارید که در آن یک کلاس Person وجود دارد. این کلاس همه مشخصه‌های مورد نیاز برای توصیف یک فرد شامل نام، تاریخ تولد، نشانی و غیره را دارد. ما این کلاس را به صورت یک «کلاس داده» (Data Class) درمی‌آوریم تا کار کردن با همه این مشخصه‌ها آسان‌تر شود. با این حال با Person به عنوان یک «موجودیت» (entity) برخورد می‌کنیم، یعنی یک Person به خاطر Person بودنش به یک شناسه متمایز انتساب می‌یابد. بدین ترتیب مشکلی پیش می‌آید و آن این است که وقتی Person هنوز Person نشده است، یعنی پیش از آن که شناسه‌ای به آن انتساب دهیم، چه طور می‌توانیم با آن کار کنیم؟ در این مقاله راه‌حل این مسئله از طریق Delegation در کاتلین توضیح داده می‌شود.

‌id-های تهی‌پذیر

Person در مراحل ابتدایی راه‌اندازی یک id تهی‌پذیر دارد:

چنان که می‌بینید ما یک id تهی‌پذیر (nullable) تعیین کرده‌ایم. بدین ترتیب متغیری را وهله‌سازی می‌کنیم، آن را در اختیار سیستم قرار می‌دهیم و سپس متغیری با id تعیین‌شده دریافت می‌کنیم.

فرض کنید توسعه‌دهنده دیگری یک مشخصه تهی‌پذیر را می‌بیند، بی‌درنگ مشخصه را پاک می‌کند، نام کلاس را به PersonInfo تغییر می‌دهد و یک کلاس Person جدید با همان فیلدها که به صورت دستی کپی شده‌اند، به علاوه بر id غیر تهی‌پذیر می‌سازد:

سپس متدهای سهولت تبدیل اضافه شده‌اند. این تنها روشی است که می‌توان برای دیدن کلاس Person بدون id استفاده کرد. این رویکرد قابل درک است، اما وارد کردن اشیای انتقال داده که تا این حد به قلب سیستم نزدیک هستند، منجر به لایه‌بندی سیستمی تبدیل‌ها می‌شود و هر لایه‌ای که اضافه شود بر پیچیدگی و ناپایداری کلی می‌افزاید تا این که در یک زمان، دیگر Person از روی موجودیت قابل شناسایی نیست.

سپس توسعه‌دهنده دیگری می‌آید و کلاً امکان استفاده از delegation را نخواهد داشت. بدین ترتیب به نتیجه زیر می‌رسیم:

مزیت‌های رویکرد نوین

کد فوق محدود به دو کلاس و یک اینترفیس است، اما مزیت‌های زیر را دارد:

فیلم آموزش برنامه نویسی کاتلین – توسعه اندروید Android با Kotlin – تکمیلی در فرادرس

کلیک کنید

• یک تعریف منفرد از Person در اینترفیس وجود دارد و تغییر دادن آن در سطح کامپایلر شما را ملزم به انتشار تغییرات می‌کند.
• هر کس یک کلاس داده است و از این رو بُردی به دست می‌آوریم.
• با این که Person از PersonInfo ارث‌بری نمی‌کند، اما در مورد هر چیزی که در PersonDefinition مشارکت دارد به آن delegation می‌کند و از این رو همه getter-ها و setter-ها و غیره دریافت می‌شوند.
• نیازی به ترجمه کد نیست، چون یک Person هم اینک در یک PersonInfo وجود دارد.
• دیگر نیازی به مقادیر تهی‌پذیر نداریم و از این رو نیازی به بررسی تهی بودن id هم نخواهیم داشت.

شاید به نظر بیاید همه این کارها برای رها شدن از شر یک id تهی‌پذیر کاری بیهوده است، اما این روش مزیت خود را در زمان بزرگ شدن و افزایش پیچیدگی اپلیکیشن‌ها نشان می‌دهد.

اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

• مجموعه آموزش‌های برنامه‌نویسی اندروید
• آموزش مقدماتی زبان برنامه‌ نویسی کاتلین (Kotlin) برای توسعه اندروید (Android)
• مجموعه آموزش‌های برنامه‌‌نویسی
• ساخت اپلیکیشن ضبط صدا با کاتلین (Kotlin) — به زبان ساده
• برنامه نویسی اندروید با کاتلین — راهنمای شروع به کار

==