آشنایی با Structural Design Patterns

قبل از ورود به Patternهای این خانواده، باید بفهمیم این گروه دقیقاً چه نوع درد معماری را درمان می‌کند.

هدف یادگیری

• بتوانید مفهوم «آشنایی با Structural Design Patterns» را با زبان خودتان توضیح دهید.
• بتوانید مسئله‌ای را که این تکنیک حل می‌کند از روی کد تشخیص دهید.
• بتوانید تشخیص دهید چه زمانی استفاده از آن اشتباه یا اضافه‌کاری است.

مسئله اصلی چیست؟

شناخت مسئله‌های تکرارشونده در طراحی و انتخاب راه‌حل متناسب با context. مسئله اصلی معمولاً زمانی شروع می‌شود که یک تصمیم طراحی در چند نقطه از سیستم تکرار می‌شود و هر تغییر، چند فایل و چند کلاس را درگیر می‌کند.

مدل ذهنی ساده

سناریوی ذهنی این درس: طراحی یک سرویس .NET که باید قابل توسعه، تست و نگهداری باشد.. به جای اینکه Client همه جزئیات را بداند، یک مرز طراحی ایجاد می‌کنیم تا بخش متغیر پشت یک قرارداد یا ساختار مشخص قرار بگیرد.

نقشه این خانواده

• Adapter / Facade
• Decorator / Proxy
• Bridge
• Composite / Flyweight

در ادامه هر Pattern را با یک سؤال ثابت بررسی می‌کنیم: مشکل چیست، ساختار چه می‌گوید، کد قبل چه ایرادی دارد، Refactoring چگونه انجام می‌شود و در پروژه واقعی کجا ارزش دارد.

خطاهای رایج

• استفاده از Pattern فقط چون معروف است، بدون مسئله مشخص.
• ساخت interface برای هر کلاس حتی وقتی هیچ جایگزینی یا boundary وجود ندارد.
• مخلوط کردن مسئولیت Pattern با Business Rule و ایجاد کلاس‌های همه‌کاره.

Best Practice

• قرارداد را کوچک و بر اساس نیاز Client طراحی کنید.
• نام کلاس‌ها را بر اساس نقش دامنه/کاربرد انتخاب کنید، نه صرفاً نام Pattern.
• قبل از اضافه کردن abstraction یک تغییر واقعی یا تست‌پذیری لازم را نشان دهید.
• برای سناریوهای async، cancellation و exception handling را بخشی از قرارداد در نظر بگیرید.

تمرین

• یک نمونه کوچک از آشنایی با Structural Design Patterns برای سامانه فروش آنلاین طراحی کنید.
• کد خود را طوری بازنویسی کنید که یک implementation جدید بدون تغییر Client اضافه شود.
• یک حالت پیدا کنید که استفاده از این Pattern overengineering باشد و دلیلش را بنویسید.

جمع‌بندی

مهم‌ترین نکته این درس این است که «آشنایی با Structural Design Patterns» یک اسم برای کلاس‌بندی کد نیست؛ یک راه شناخته‌شده برای مدیریت یک نوع مشخص از تغییر است. اگر مسئله وجود دارد، Pattern کمک می‌کند نقطه تغییر محدود و قابل تست شود؛ اگر مسئله وجود ندارد، ساده‌ترین طراحی معمولاً بهتر است.

درس بعدی