preloder
دانستنی‌ها

Constructorهای عالی این‌چنین باید باشند

Constructorها عالی هستند. اما برای داشتن کد تمیز و قابل فهم‌تر باید نکاتی را در استفاده از Constructorها در نظر بگیریم.

 

در کد، هدف باید تنظیم کردن همه چیز در constructor باشد و تا جای ممکن باید از setterها در کد اجتناب کرد چرا که ثبات و تغییرناپذیری در برنامه تا جای ممکن باید حفظ شود و setterها دشمن این مساله هستند.

به علاوه، این تنها کاری است که constructor باید انجام دهد. هیچ منطق پیچیده‌ای را نباید در Constructor اشیا قرار داد. در واقع باید جایی تنها برای فیلدهای اشیا باشد. هرچیز دیگر مثل اتصال به سرویس‌های دیگر باید در متد init قرار گیرد. ترجیحا این متد باید فاقد پارامتر بوده و هرکاری که لازم است تا شی را به وضعیت صحیح ببرد در این متد انجام می‌گیرد.

به عنوان یک قانون، همواره سعی کنید از یک constructor استفاده کنید. این کار فهم کد را راحت‌تر می‌کند. اشیا شما باید مجموعه‌ای از قابلیت‌ها داشته باشند که همواره براساس مجموعه‌ای از وابستگی‌ها اجرا می‌شود. اگر شما، به عنوان فراخواننده، نیازی به این قابلیت‌ها نداشتید، آن‌گاه از قابلیت بدون عملیات استفاده می‌کنید.

که این مساله در جاوا ۸ نیز واضح‌تر خواهد بود.

یکی از مهم‌ترین بخش‌های کد این است که شما نباید هرگز null را پاس بدهید. به‌کارگیری چنین قانون ساده‌ای در کد به این معناست که شما می‌توانید تعداد زیادی خطوط کد را که برای چک کردن null بودن یا نبودن است، حذف کنید.

اگر کد شما قابل تغییر نیست، آن‌گاه چک کردن nullها را در constructor انجام دهید. به عبارتی در انتهای constructor مطمئن باشید که تمام فیلدها تنظیم شده و شئ شما آماده است.

گاهی پاسخ این مساله، constructorهای چندگانه در نظر گرفته می‌شود، که پیاده‌سازی پیش‌فرض را فراهم می‌کنند. constructorهای چندگانه کد را پیچیده می‌کنند و فهم آن را دشوار می‌سازند. اما داشتن پیاده‌سازی پیش فرضی برای end userها خوب است. مثل زیر:

یک مثال عملی:

بیایید نگاهی به کد زیر بیندازیم:

این کد به چند دلیل فاجعه است!

  • nullها چپ راست و وسط رها شده‌اند. این کار فهم اتفاقی که دارد می‌افتد را سخت کرده و منجر به کد اضافی برای چک کردن nullها شده است.
  • وجود constructor چندگانه به خصوص وقتی که اولی فقط null دیگری را پاس می‌دهد.
  • ساخت شیئ دیگر در constructor، این خیلی بد نیست و احتمالا شما هم چنین حسی نسبت به آن دارید. اما چون که تنها یک پارامتر را می‌پذیرد نوعی decorator به حساب می‌آید. چرا شئ مورد نیاز را پاس ندهیم؟
  • به نظر می‌رسد که شئ مورد نیازی را پاس می‌دهد اما تنها آن را دوباره wrap می‌کند تا از آن مطمئن باشد.

اول می‌توان اولین constructor را حذف کرد. هرکس که آن را بخواهد، null پاس خواهد داد.

دوم اگر شما می‌خواهید مردم را بپذیرید، نباید null پاس داد. پس می‌توان کد چک کردن null بودن Swagger را حذف کرد. اگر این مشکل‌زا شود، برنامه به سرعت منهدم خواهد شد و ما می‌توانیم کدهای وابسته آن را اصلاح کنیم. پس خواهیم داشت:

خب الان بهتر شد. حالا دیگر نیازی به wrap برای چک کردن null نیست. DefaultReaderConfig تنها پیاده‌سازی در دسترس خواهد بود. اما اجازه دهید فرض کنیم این گونه نیست آن‌گاه کد را تغییر می‌دهیم تا شی‌ را مستقیما پاس بدهیم و نه اینکه داخل constructor بسازیم.

حالا کد خیلی تمیزتر به نظر می‌رسد. اما اگر کسی configای برای پاس دادن نداشت چه می‌شود؟ پیاده‌سازی پیش فرض!

در نتیجه ما از شر دو constructor در ReaderConfig راحت خواهیم شد و کد تمیزتر و ساده‌تری برای فهم خواهیم داشت.

منبع:

https://dzone.com/

[تعداد: 0    میانگین: 0/5]
برچسب ها
نمایش بیشتر

نوشته های مشابه

پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا