یکی از نشونه‌های رایج طراحی نه‌چندان خوب، متد‌های Pass-through هست. یعنی متدی که تقریبا هیچ کاری نمی‌کنه و فقط ورودی‌ها رو به متد کلاس دیگه پاس میده. اینجا getUser هیچ منطق جدیدی اضافه نکرده و فقط نقش واسطه رو داره.

مشکل اینجاست که این متدها فقط تعداد APIهای کلاس رو بیشتر می‌کنن، بدون اینکه قابلیت جدیدی به سیستم اضافه کنن. علاوه بر اون وابستگی هم ایجاد می‌کنن؛ مثلا اگر اینترفیس getUser داخل UserRepository تغییر کنه، این متد هم باید تغییر کنه.

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

با برخورد به چنین کلاس‌هایی باید پرسید: دقیقا مسئولیت هر کدوم از این کلاس‌ها چیه؟ جواب این سوال خیلی وقت‌ها باعث میشه یکی از این کارها رو انجام بدید:
- کلاس سطح پایین رو مستقیما در اختیار استفاده‌کننده قرار بدید.
- مسئولیت‌ها رو بین کلاس‌ها دوباره تقسیم کنید.
- یا اگر عملا از هم جدا نیستن، اون‌ها رو با هم ادغام کنید.

#A_Philosophy_of_Software_Design

@techstuff100