۱. مفهوم بنیادین: TDA چیست؟

به زبان ساده، اصل Tell, Don't Ask به این معناست که شما نباید از یک شیء داده‌هایش را بپرسید تا خودتان روی آن پردازش انجام دهید؛ بلکه باید به آن شیء بگویید که چه کاری انجام دهد.

در طراحی شی‌گرا، داده‌ها (State) و رفتارها (Behavior) باید در کنار هم بسته‌بندی شوند (Encapsulation). اما بسیاری از توسعه‌دهندگان ناخودآگاه به سبک رویه‌ای (Procedural) کد می‌نویسند: داده‌ها را از یک شیء بیرون می‌کشند، تغییری می‌دهند و دوباره آن را ذخیره می‌کنند.

تفاوت فلسفی

• روش Ask (اشتباه): شما مدیر میکرو-منیجری هستید که مدام از کارمند خود می‌پرسید: «پرونده کجاست؟ خودکار داری؟ وقت داری؟» و سپس خودتان کار را انجام می‌دهید.

• روش Tell (صحیح): شما فرمانده‌ای هستید که دستور می‌دهید: «این گزارش را برای من آماده کن.» اینکه کارمند چگونه، با چه ابزاری و در چه زمانی (در چارچوب محدودیت‌ها) این کار را می‌کند، به خودش مربوط است.

۲. کالبدشکافی یک مشکل: سندرم "پرسیدن"

برای درک بهتر، بیایید یک سناریوی رایج را بررسی کنیم. فرض کنید سیستمی برای مدیریت سفارشات داریم. می‌خواهیم بررسی کنیم که آیا کاربر تخفیف دارد یا خیر و اگر دارد، آن را اعمال کنیم.

رویکرد اشتباه (Asking)

در این رویکرد، سرویس (Service Layer) داده‌ها را از مدل بیرون می‌کشد و تصمیم‌گیری می‌کند.

// کد بد: نقض اصل Tell, Don't Ask

Order order = getOrder(123);
if (order.getStatus().equals("NEW") && order.getTotalAmount() > 1000) {
    double discount = order.getTotalAmount() * 0.10;
    order.setTotalAmount(order.getTotalAmount() - discount);
    order.save();
}

چرا این کد بد است؟

1. نشت منطق (Leaky Logic): منطق محاسبه تخفیف که باید متعلق به Order باشد، به لایه سرویس نشت کرده است.

2. وابستگی شدید (Coupling): لایه بیرونی دقیقاً می‌داند که Order دارای فیلدهای status و totalAmount است. اگر فردا نام این فیلدها تغییر کند، کد سرویس می‌شکند.

3. کپسوله‌سازی ضعیف: ما عملاً داده‌های داخلی شیء را عریان کرده‌ایم و هر کسی می‌تواند آن‌ها را تغییر دهد.

۳. راه حل: رویکرد "گفتن"

حالا بیایید همان منطق را با رعایت اصل TDA بازنویسی کنیم. ما به شیء Order می‌گوییم: «تخفیف را اعمال کن» و او خودش مسئول بررسی شرایط است.

رویکرد صحیح (Telling)

// کد خوب: رعایت اصل Tell, Don't Ask

// در لایه سرویس
Order order = getOrder(123);
order.applyDiscountIfEligible(); // ما فقط دستور می‌دهیم
order.save();

// ---------------------------

// در کلاس Order (Domain Model)
public void applyDiscountIfEligible() {
    if (this.status.equals("NEW") && this.totalAmount > 1000) {
        double discount = this.totalAmount * 0.10;
        this.totalAmount -= discount;
    }
}

چه اتفاقی افتاد؟

• منطق تجاری (Business Logic) به جایی برگشت که به آن تعلق دارد: داخل Domain Model.

• لایه بیرونی (Caller) هیچ اطلاعی از نحوه محاسبه تخفیف یا شرایط آن ندارد.

• تغییر در قوانین تخفیف فقط نیازمند تغییر در کلاس Order است، نه در تمام سرویس‌هایی که از آن استفاده می‌کنند.

۴. TDA و معماری نرم‌افزار

اصل Tell, Don't Ask فقط محدود به تمیزی کد (Clean Code) نیست؛ بلکه تأثیر عمیقی بر معماری کلان نرم‌افزار دارد.

۴.۱. مدل دامنه کم‌خون (Anemic Domain Model)

یکی از بزرگترین ضدالگوها (Anti-patterns) در معماری نرم‌افزار، "مدل دامنه کم‌خون" است. این زمانی رخ می‌دهد که کلاس‌های دامنه شما (مانند User, Order, Product) فقط شامل Getter و Setter هستند و هیچ رفتاری ندارند. تمام منطق در کلاس‌های سرویس (Service Classes) تلنبار می‌شود.

رعایت نکردن TDA علت اصلی به وجود آمدن مدل‌های کم‌خون است. با اعمال TDA، شما به سمت Rich Domain Model (مدل دامنه غنی) حرکت می‌کنید، جایی که اشیاء هوشمند هستند و مسئولیت داده‌های خود را بر عهده دارند. این قلب تپنده طراحی دامنه-محور (DDD) است.

۴.۲. انسجام (Cohesion) و وابستگی (Coupling)

در معماری، ما همواره به دنبال High Cohesion (انسجام بالا) و Low Coupling (وابستگی کم) هستیم.

• وقتی شما "می‌پرسید" (Ask)، وابستگی بین فراخواننده و ساختار داخلی شیء را افزایش می‌دهید.

• وقتی شما "می‌گویید" (Tell)، داده و منطق را در یک جا نگه می‌دارید که باعث افزایش انسجام می‌شود.

۵. نشانه‌های نقض اصل TDA

چگونه بفهمیم که در حال نقض این اصل هستیم؟ به دنبال "بوهای بد کد" (Code Smells) زیر باشید:

1. زنجیره گترها (Getter Chains): کدهایی مثل order.getCustomer().getAddress().getZipCode(). این یعنی شما دارید در دل اشیاء حفاری می‌کنید تا به داده برسید. (این مورد با قانون دمیتر - Law of Demeter نیز همپوشانی دارد).

2. تعداد زیاد Setter: اگر کلاسی دارید که تمام فیلدهایش public void set... دارند، احتمالا آن کلاس کنترلی روی وضعیت (State) خود ندارد و دیگران آن را مدیریت می‌کنند.

3. منطق شرطی روی داده‌های شیء دیگر: مشاهده if هایی که روی فیلدهای یک شیء دیگر تصمیم‌گیری می‌کنند.

نکته مهم: وجود Getter به خودی خود بد نیست، اما استفاده از آن برای تصمیم‌گیری خارج از شیء، نقض TDA است.

۶. استثناها: کی باید "بپرسیم"؟

هیچ اصلی در مهندسی نرم‌افزار مطلق نیست. مواقعی وجود دارد که استفاده از TDA ممکن نیست یا منطقی به نظر نمی‌رسد:

• لایه نمایش (UI/Presentation): وظیفه UI نمایش اطلاعات است. برای نمایش موجودی حساب به کاربر، چاره‌ای جز getBalance() ندارید. TDA بیشتر مربوط به تغییر وضعیت (State Change) و منطق تجاری است، نه خواندن داده (Reading Data).

• DTOs (Data Transfer Objects): این اشیاء ذاتاً برای حمل داده طراحی شده‌اند و نباید رفتار (Behavior) داشته باشند. در اینجا دسترسی مستقیم به داده‌ها صحیح است.

• گزارش‌گیری (Reporting): وقتی نیاز دارید داده‌های زیادی را تجمیع و تحلیل کنید، معمولاً پرسیدن داده‌ها از اشیاء مختلف اجتناب‌ناپذیر است.

۷. چگونه TDA را پیاده‌سازی کنیم؟ (گام‌های عملی)

برای حرکت به سمت این اصل در پروژه خود، مراحل زیر را دنبال کنید:

1. شناسایی: به دنبال بلوک‌های کدی بگردید که داده‌ای را از یک شیء می‌گیرند، محاسبه‌ای انجام می‌دهند و نتیجه را برمی‌گردانند.

2. حرکت دادن رفتار: آن بلوک محاسبه را کپی کرده و به عنوان یک متد جدید داخل کلاسی که داده‌ها متعلق به آن است، قرار دهید.

3. نام‌گذاری معنایی: نام متد را بر اساس "قصد" (Intent) انتخاب کنید، نه پیاده‌سازی.

   • بد: setOrderStatusToShipped()

   • خوب: shipOrder()

4. حذف دسترسی‌ها: اگر ممکن است، دسترسی مستقیم (Getter/Setter) به آن فیلد خاص را محدود یا حذف کنید تا مطمئن شوید همه از رفتار جدید استفاده می‌کنند.

۸. نتیجه‌گیری

اصل Tell, Don't Ask یادآور این نکته است که اشیاء در برنامه‌نویسی فقط "کیف‌هایی از داده" نیستند؛ آن‌ها موجودیت‌هایی هوشمند هستند که باید مسئولیت رفتار خود را بر عهده بگیرند.

رعایت این اصل منجر به:

• کاهش تکرار کد.

• تمرکز منطق در جای درست.

• سهولت در تست‌نویسی (Unit Testing).

• و در نهایت، خلق معماری نرم‌افزاری می‌شود که در برابر تغییرات مقاوم است.

دفعه بعد که خواستید کدی بنویسید و دستتان روی get... رفت، لحظه‌ای درنگ کنید و بپرسید: «آیا دارم مدیریت خرد می‌کنم؟ یا می‌توانم به این شیء دستور دهم که خودش این کار را انجام دهد؟»