اندازه‌ی قلم متن
تخمین مدت زمان مطالعه‌ی مطلب:
پنج دقیقه
این کد بد بو در دسته «جلوگیری کنندگان از تغییر» قرار می‌گیرد. اگر زمان ایجاد یک کلاس فرزند برای کلاسی، مجبور به ایجاد یک کلاس فرزند متناظر آن برای کلاس دیگری باشید، با این کد بد بود مواجه هستید.
معمولا زمانی این اتفاق می‌افتد که یک درخت ارث بری به درخت ارث بری دیگری وابسته باشد. به‌طوری که هر یک از کلاس‌های موجود در آن، با یک کلاس در درخت دیگر متناظر باشند و ارتباط داشته باشند. این امر ایجاد تغییرات در کد را با مشکل مواجه خواهد کرد.
به طور مثال:
public abstract class InvoiceGenerator
{
public abstract dynamic Generate();
}
public abstract class AmountCalculator
{
public abstract decimal Calculate(dynamic item);
} public class StandardInvoiceGenerator : InvoiceGenerator
{
public override dynamic Generate()
{
return new object();
}
}
public class StandardInvoiceAmountCalculator : AmountCalculator
{
public override decimal Calculate(dynamic item)
{
return 1;
}
}
public class PrepaymentInvoiceGenerator : InvoiceGenerator
{
public override dynamic Generate()
{
return new object();
}
}
public class PrepaymentInvoiceAmountCalculator : AmountCalculator
{
public override decimal Calculate(dynamic item)
{
return 1;
}
} در این مثال کلاسی به نام InvoiceGenerator وجود دارد که کلاس پدر تولید کنندگان فاکتور است و کلاس دیگری نیز وجود دارد به نام AmountCalculator که کلاس پدر محاسبه قیمت است. هر یک از سازندگان فاکتور، یک کلاس متناظر در درخت Caluclatorها دارند؛ برای محاسبه قیمت آیتم‌های آن نوع فاکتور. به طور خاص در این مثال فاکتور استاندارد و فاکتور پیش پرداخت نوشته شده است (در این مثال فقط یک سطح از ارث بری پیاده سازی شده است و تمامی کلاس‌ها مستقیما از کلاس پدر به ارث برده می‌شوند. در صورت وجود چند سطح ارث بری، مشکل پیچیده‌تر نیز خواهد شد).
حال فرض کنید قصد افزودن یک کلاس را برای ایجاد «فاکتور گزارش مخارج» (فاکتوری برای ثبت مخارجی که کارکنان زمان انجام کار برای کارفرما متحمل می‌شوند) دارید.
در این حالت نیاز است که یک کلاس ExpenseReportInvoiceGenerator ساخته شود و متناظر با آن نیاز خواهد بود کلاس ExpenseReportAmountCalculator ساخته شود.
چرا چنین بویی به راه می‌افتد
دلایل بوجود آمدن چنین بویی به سه دسته تقسیم می‌شوند:
- تشخیص نادرست روابط بین کلاس‌ها
- استفاده نامناسب از الگوهای طراحی
- تشخیص نادرست مسئولیت‌های کلاس‌ها و طراحی نامناسب آن
روش‌های اصلاح این کد بد بو
اصلاح چنین بوی بدی آسان نیست؛ زیرا درخت‌های ارث بری موازی، همیشه اتفاقی اشتباه نیستند و معمولا زمانیکه اصل Single responsibility در کدها به طور وسیعی رعایت شود، احتمال به‌وجود آمدن چنین الگویی وجود دارد؛ مانند مثالی که ذکر شد. در مثال مطرح شده اصل Single responsibility به درستی رعایت شده‌است.
در برخورد با چنین بویی معمولا سه راه وجود دارد.
اول: عدم تغییر درخت‌های ارث بری موازی
معمولا در مواردی مانند مثال ذکر شده در این مطلب، بهترین گزینه، عدم تغییر درخت ارث بری است. اگر رعایت کردن اصل single responsibility مهمتر از سادگی در ایجاد تغییرات باشد، این گزینه یک انتخاب خوب خواهد بود. یکی از مزایای دست نخوردن کدهایی مانند مثال مذکور، سهولت در نوشتن تست‌های واحد است.
دوم: تبدیل درخت ارث بری به یک درخت ارث بری ناقص
در این روش می‌توان interface هایی را برای AmountCalculator و InvoiceGenerator ساخت و کلاس‌هایی که این دو interface را پیاده سازی می‌کنند؛ مانند:
public interface IInvoiceGenerator
{
dynamic Generate();
}
public interface IAmountCalculator
{
decimal Calculate(dynamic item);
}
public class StandardInvoiceGenerator : IInvoiceGenerator, IAmountCalculator
{
public dynamic Generate()
{
return new object();
}
public decimal Calculate(dynamic item)
{
return 1;
}
}
public class PrepaymentInvoiceGenerator : IInvoiceGenerator, IAmountCalculator
{
public dynamic Generate()
{
return new object();
}
public decimal Calculate(dynamic item)
{
return 1;
}
} با این تغییر، بخشی از اصل single responsibility نادیده گرفته شده‌است. اما با وجود یک درخت ارث بری فیزیکی، درخت منطقی موجود دست نخورده باقی مانده و در صورت نیاز می‌توان دوباره اقدام به جداسازی مسئولیت‌ها کرد. این جداسازی بیشتر اوقات زمانی اتفاق می‌افتد که یکی از جنبه‌های مسئولیتی یک کلاس، در جای دیگری به صورت مستقل مورد استفاده قرار گیرد.
سوم: از بین بردن درخت ارث بری موازی
این روش تقریبا مشابه روش ذکر شده در بخش دوم است. تنها با این تفاوت که در این روش، رابطه منطقی ارث بری موازی نیز حذف می‌شود؛ مانند:
public abstract class InvoiceGenerator
{
public abstract dynamic Generate();
public abstract decimal CalculateItemAmount(dynamic item);
}
public class StandardInvoiceGenerator : InvoiceGenerator
{
public override dynamic Generate()
{
throw new NotImplementedException();
}
public override decimal CalculateItemAmount(dynamic item)
{
throw new NotImplementedException();
}
}
public class PrepaymentInvoiceGenerator : InvoiceGenerator
{
public override dynamic Generate()
{
throw new NotImplementedException();
}
public override decimal CalculateItemAmount(dynamic item)
{
throw new NotImplementedException();
}
} در این روش دو درخت ارث بری از نظر منطقی و فیزیکی با یکدیگر ادغام شده‌اند. البته همان طور که در بخش یک گفته شد، بهترین گزینه برای مثال ذکر شده در این مطلب، دست نخوردن آن است. این روش زمانی مناسب است که موجودیت‌های ادغام شده از نظر ذاتی به قدری به یکدیگر شباهت داشته باشند که عملا بتوانیم آنها را یک موجودیت مستقل در نظر بگیریم.
جمع بندی
روش‌های رفع بوی بد «درخت‌های ارث بری موازی» به زمینه ایجاد آنها وابستگی شدیدی دارد. به همین دلیل نمی‌توان راه حلی کلی را برای آن ارائه داد. سه روش ذکر شده در این مطلب در واقع سه نوع رفتاری هستند که می‌توان با چنین بوی بدی داشت. بسته به زمینه ایجاد این بوی بد و شرایط کد می‌توان هر یک از این روش‌ها را انتخاب نمود. نکاتی مانند سهولت نگهداری، تست نویسی آسان و خوانایی کد، فاکتورهایی هستند که می‌توانند در تصمیم گیری مد نظر قرار گیرند.