🚫 چه زمانی نباید از Design Patternها استفاده کنیم؟
یکی از بزرگ‌ترین اشتباهات برنامه‌نویس‌ها این است که فکر می‌کنند هر مسئله‌ای باید با یک Design Pattern حل شود.
در حالی که بسیاری از Patternها برای حل مشکلات پیچیده طراحی شده‌اند، نه برای پیچیده‌تر کردن کدهای ساده.
گاهی یک متد ساده یا یک
if دقیقاً همان چیزی است که نیاز دارید. 👇1️⃣ Adapter
❌ زیاده‌روی است وقتی:
فقط قرار است یک یا دو نوع داده را تبدیل (Map) کنید.
✅ به‌جای آن:
یک Mapper ساده یا Helper Method بنویسید.
2️⃣ Decorator
❌ زیاده‌روی است وقتی:
فقط می‌خواهید یک Validation یا Log ساده اضافه کنید.
✅ به‌جای آن:
از Pipeline، Middleware یا حتی منطق مستقیم استفاده کنید.
3️⃣ Facade
❌ زیاده‌روی است وقتی:
زیرسیستم شما API واضح و ساده‌ای دارد.
✅ به‌جای آن:
مستقیماً همان Service را فراخوانی کنید.
4️⃣ Abstract Factory
❌ زیاده‌روی است وقتی:
فقط یک یا دو نوع شیء می‌سازید.
✅ به‌جای آن:
از Constructor یا Factory Method ساده استفاده کنید.
5️⃣ Strategy
❌ زیاده‌روی است وقتی:
رفتار فقط چند حالت ساده دارد.
✅ به‌جای آن:
یک
if/else یا switch کاملاً کافی است.6️⃣ Builder
❌ زیاده‌روی است وقتی:
شیء فقط چند Property اختیاری دارد.
✅ به‌جای آن:
از Object Initializer یا پارامترهای Optional استفاده کنید.
7️⃣ Factory Method
❌ زیاده‌روی است وقتی:
منطق ساخت شیء بسیار ساده است.
✅ به‌جای آن:
از
new یا یک Helper استفاده کنید.8️⃣ Chain of Responsibility
❌ زیاده‌روی است وقتی:
جریان اجرای شما کوتاه و ثابت است.
✅ به‌جای آن:
یک Pipeline ساده از متدها بسازید.
9️⃣ Template Method
❌ زیاده‌روی است وقتی:
فقط بخش کوچکی از الگوریتم تغییر می‌کند.
✅ به‌جای آن:
از Delegate یا یک متد مشترک استفاده کنید.
🔟 Bridge
❌ زیاده‌روی است وقتی:
فقط یک بُعد تغییر در سیستم دارید.
✅ به‌جای آن:
ءComposition یا یک Interface ساده کافی است.
1️⃣1️⃣ Command
❌ زیاده‌روی است وقتی:
عملیات ساده هستند و نیازی به Queue، Undo یا Retry ندارند.
✅ به‌جای آن:
مستقیماً متد موردنظر را صدا بزنید.
1️⃣2️⃣ State
❌ زیاده‌روی است وقتی:
فقط چند State ساده دارید.
✅ به‌جای آن:
یک
enum همراه با switch استفاده کنید.1️⃣3️⃣ Proxy
❌ زیاده‌روی است وقتی:
فقط یک Wrapper کوچک نیاز دارید.
✅ به‌جای آن:
یک Helper یا Wrapper ساده بنویسید.
1️⃣4️⃣ Observer
❌ زیاده‌روی است وقتی:
فقط یک یا دو Receiver دارید.
✅ به‌جای آن:
از Callback یا فراخوانی مستقیم متد استفاده کنید.
1️⃣5️⃣ Composite
❌ زیاده‌روی است وقتی:
قرار نیست با Itemها و Groupها رفتار یکسانی داشته باشید.
✅ به‌جای آن:
منطق List و Item را جدا نگه دارید.
1️⃣6️⃣ Visitor
❌ زیاده‌روی است وقتی:
مدل دائماً تغییر می‌کند و تعداد عملیات کم است.
✅ به‌جای آن:
ءPattern Matching یا
switch انتخاب بهتری است.1️⃣7️⃣ Prototype
❌ زیاده‌روی است وقتی:
کپی گرفتن از اشیاء ساده است.
✅ به‌جای آن:
از Copy Constructor یا Mapper استفاده کنید.
1️⃣8️⃣ Flyweight
❌ زیاده‌روی است وقتی:
مصرف حافظه مشکل اصلی سیستم نیست.
✅ به‌جای آن:
از Objectهای معمولی و Cache هدفمند استفاده کنید.
1️⃣9️⃣ Interpreter
❌ زیاده‌روی است وقتی:
قوانین سیستم کم و ثابت هستند.
✅ به‌جای آن:
از Parser ساده یا Configuration Table استفاده کنید.
2️⃣0️⃣ Singleton
❌ زیاده‌روی است وقتی:
فقط یک سرویس مشترک می‌خواهید.
✅ به‌جای آن:
آن را به‌صورت Singleton در DI Container ثبت کنید، نه اینکه الگوی Singleton را پیاده‌سازی کنید.
2️⃣1️⃣ Mediator
❌ زیاده‌روی است وقتی:
فقط چند سرویس محدود با هم تعامل دارند.
✅ به‌جای آن:
از فراخوانی مستقیم Service به Service استفاده کنید.
🎯 جمع بندی
ءDesign Patternها ابزار هستند، نه هدف.
بهترین معماری، معماری‌ای نیست که بیشترین Pattern را داشته باشد؛ بلکه معماری‌ای است که ساده‌ترین راه‌حل ممکن را برای مسئله‌ی واقعی انتخاب کند.
همان‌طور که Martin Fowler می‌گوید:
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." 💡گاهی بهترین Pattern، استفاده نکردن از Pattern است. 😉