جمعبندی حرفهای
چطور Pattern مناسب را انتخاب کنیم؟
محتوای درس چطور Pattern مناسب را انتخاب کنیم؟
در این درس یک جنبه مهم از طراحی شیءگرا را با نگاه کاربردی بررسی میکنیم.
هدف یادگیری
- بتوانید مفهوم «چطور Pattern مناسب را انتخاب کنیم؟» را با زبان خودتان توضیح دهید.
- بتوانید مسئلهای را که این تکنیک حل میکند از روی کد تشخیص دهید.
- بتوانید تشخیص دهید چه زمانی استفاده از آن اشتباه یا اضافهکاری است.
مسئله اصلی چیست؟
کپسولهسازی الگوریتمهای قابل تعویض پشت یک قرارداد مسئله اصلی معمولاً زمانی شروع میشود که یک تصمیم طراحی در چند نقطه از سیستم تکرار میشود و هر تغییر، چند فایل و چند کلاس را درگیر میکند.
مدل ذهنی ساده
سناریوی ذهنی این درس: محاسبه تخفیف یا هزینه ارسال با الگوریتمهای مختلف. به جای اینکه Client همه جزئیات را بداند، یک مرز طراحی ایجاد میکنیم تا بخش متغیر پشت یک قرارداد یا ساختار مشخص قرار بگیرد.
پیادهسازی نمونه در C#
نمونه کد آموزشی
نمونه کد این درس در بخش کد درس قرار داده شده است.
کد قبل از Refactoring چه بویی میدهد؟
- if/switch بزرگ که رفتار، نوع یا حالت را در چند نقطه تصمیم میگیرد.
- ساخت مستقیم وابستگیها با new در لایه Business/Application.
- تکرار منطق cross-cutting مثل Logging، Retry یا Validation.
مراحل Refactoring
1. نقطه تغییر را مشخص کنید و دقیقاً بگویید کدام تصمیم ناپایدار است.
2. یک قرارداد کوچک و معنادار برای بخش متغیر تعریف کنید.
3. Concrete implementationها را پشت قرارداد منتقل کنید.
4. Client را فقط به قرارداد وابسته کنید.
5. با تست، رفتار قبل و بعد را یکسان نگه دارید و سپس پیچیدگی اضافی را حذف کنید.
چه زمانی استفاده کنیم؟
وقتی چند الگوریتم برای یک هدف داریم و انتخاب باید قابل تغییر باشد. اگر تنها یک پیادهسازی ساده دارید و احتمال تغییر واقعی کم است، Pattern ممکن است صرفاً تعداد فایلها را زیاد کند.
نکته تخصصی این درس
از محور تغییر انتخاب کنید: ساخت → Creational، ترکیب/اتصال → Structural، رفتار/تعامل → Behavioral.
خطاهای رایج
- استفاده از Pattern فقط چون معروف است، بدون مسئله مشخص.
- ساخت interface برای هر کلاس حتی وقتی هیچ جایگزینی یا boundary وجود ندارد.
- مخلوط کردن مسئولیت Pattern با Business Rule و ایجاد کلاسهای همهکاره.
Best Practice
- قرارداد را کوچک و بر اساس نیاز Client طراحی کنید.
- نام کلاسها را بر اساس نقش دامنه/کاربرد انتخاب کنید، نه صرفاً نام Pattern.
- قبل از اضافه کردن abstraction یک تغییر واقعی یا تستپذیری لازم را نشان دهید.
- برای سناریوهای async، cancellation و exception handling را بخشی از قرارداد در نظر بگیرید.
تمرین
- یک نمونه کوچک از چطور Pattern مناسب را انتخاب کنیم؟ برای سامانه فروش آنلاین طراحی کنید.
- کد خود را طوری بازنویسی کنید که یک implementation جدید بدون تغییر Client اضافه شود.
- یک حالت پیدا کنید که استفاده از این Pattern overengineering باشد و دلیلش را بنویسید.
جمعبندی
مهمترین نکته این درس این است که «چطور Pattern مناسب را انتخاب کنیم؟» یک اسم برای کلاسبندی کد نیست؛ یک راه شناختهشده برای مدیریت یک نوع مشخص از تغییر است. اگر مسئله وجود دارد، Pattern کمک میکند نقطه تغییر محدود و قابل تست شود؛ اگر مسئله وجود ندارد، سادهترین طراحی معمولاً بهتر است.
درس 84 از 89 در آموزش جامع Design Patterns در C# و .NETنمونه کد
public interface IShippingStrategy { decimal Calculate(Order order); }
public sealed class ExpressShipping : IShippingStrategy
{
public decimal Calculate(Order order) => 150_000 + order.Weight * 8_000;
}
خروجی مورد انتظار
خروجی این درس شامل اجرای نمونه مرتبط با «چطور Pattern مناسب را انتخاب کنیم؟» و درک کاربرد آن در سناریوهای واقعی C# و .NET است.