2️⃣ ءConstructor Overloadهای متعدد
ءPrimary Constructor تنها یک Signature را پشتیبانی می‌کند.
اگر نیاز به چندین Constructor مختلف داشته باشید، باید از Constructorهای ثانویه و زنجیره کردن آن‌ها با
this(...) استفاده کنید.این رویکرد خیلی سریع پیچیده و ناخوانا می‌شود.
3️⃣ تعداد زیاد Dependencyها
وقتی تعداد Dependencyها از ۵ یا بیشتر عبور می‌کند، تعریف Primary Constructor شروع به شلوغ شدن می‌کند.
در چنین شرایطی معمولاً مشکل اصلی Constructor نیست.
مشکل این است که کلاس بیش از حد مسئولیت دارد.
در این سناریو Refactor کردن کلاس راه‌حل بهتری نسبت به استفاده از ترفندهای ظاهری برای قالب‌بندی کد است.
✅ جمع‌بندی
بعد از استفاده از Primary Constructorها در چندین پروژه، به این نتیجه رسیده‌ام:
برای تمام کلاس‌های سرویس مبتنی بر Dependency Injection از Primary Constructor استفاده می‌کنم.
حذف Boilerplate در این سناریو کاملاً ارزشمند است.
برای ساخت Entityها و Value Objectها نیز می‌توانند مفید باشند؛ مخصوصاً زمانی که می‌خواهید پارامترهای ضروری را در سطح Type اجبار کنید.
پارامترهای Primary Constructor فیلد readonly نیستند؛ بلکه به‌صورت mutable capture ذخیره می‌شوند و این مهم‌ترین نکته‌ای است که باید بدانید.
در کلاس‌های سرویس بابت این موضوع نگرانی خاصی ندارم، زیرا احتمال بروز خطا بسیار پایین است.
برای Typeهایی که Validation سنگین دارند، Constructorهای متعدد دارند یا وابستگی‌های زیادی دریافت می‌کنند، همچنان از Constructorهای سنتی استفاده می‌کنم.
در مجموع، این مهاجرت برای من ارزشمند بود.
کلاس‌های سرویس کوتاه‌تر شده‌اند، خوانایی بیشتری دارند و با شناخت درست از محدودیت‌ها، می‌توان با اطمینان از Primary Constructorها استفاده کرد.
تا مطلب بعدی، موفق باشید 🚀
🔖هشتگ‌ها:
#primaryconstructor