TDA (Tell, Don’t Ask): Cara Berpikir OOP yang Jarang Diajarkan di Kampus

Banyak developer yang sudah bisa ngoding tapi belum benar-benar berpikir seperti engineer.
Salah satu prinsip sederhana tapi berdampak besar dalam dunia OOP adalah TDA (Tell, Don’t Ask) — “Jangan tanya data dari object, tapi suruh object itu melakukan aksinya sendiri.”

Konsep ini kedengarannya sepele, tapi kalau kamu paham dan menerapkannya, struktur kode akan jadi lebih rapi, modular, dan mudah di-maintain.

1. Apa Itu TDA?

TDA (Tell, Don’t Ask) berarti:

Jangan ambil data dari object untuk diolah di luar.
Sebaliknya, “beritahu” object itu apa yang harus dilakukan.

Atau versi singkatnya:

Jangan “bertanya” ke object, tapi “perintahkan” dia.

2. Contoh Kasus Tanpa TDA (Cara Lama)

Misalnya kita punya object user:

const user = {
  name: "Nanang",
  isAdmin: true
}

if (user.isAdmin) {
  console.log(`${user.name} can access dashboard`)
}

Sekilas terlihat biasa aja, kan?
Tapi ini melanggar prinsip TDA, karena kita mengambil data isAdmin dari luar object untuk menentukan perilaku.

Artinya, object user tidak benar-benar berperilaku seperti dirinya sendiri.
Kita yang harus tahu logika internalnya dari luar — ini bikin kode sulit di-maintain.

3. Versi dengan TDA (Cara Lebih Baik)

Kita ubah pendekatannya:

class User {
  constructor(name, isAdmin) {
    this.name = name;
    this.isAdmin = isAdmin;
  }

  accessDashboard() {
    if (this.isAdmin) {
      console.log(`${this.name} can access dashboard`)
    } else {
      console.log(`${this.name} cannot access dashboard`)
    }
  }
}

const user = new User("Nanang", true);
user.accessDashboard();

Sekarang kita “menyuruh” object melakukan sesuatu, bukan “bertanya” datanya.
Object User punya tanggung jawab penuh terhadap tindakannya sendiri.

4. Kenapa Ini Lebih Baik?

✅ Encapsulation lebih kuat
Logika internal (isAdmin) tidak bocor ke luar.

✅ Kode lebih mudah dirawat
Kalau nanti ada aturan baru (misal role moderator), cukup ubah di dalam class.

✅ Lebih mudah diuji (testable)
Behavior object bisa diuji langsung tanpa tergantung struktur data luar.

✅ Lebih natural secara OOP
Kamu memperlakukan object sebagai entitas yang hidup, bukan sekadar kumpulan data.

5. Analogi Dunia Nyata

Bayangkan kamu punya barista di kafe.

Versi tanpa TDA:
Kamu tanya ke barista: “Kamu punya kopi nggak? Kamu bisa bikin cappuccino nggak?”
Lalu kamu ambil bahan dan bikin sendiri.

Versi dengan TDA:
Kamu cukup bilang: “Tolong buatkan saya cappuccino.”
Barista yang tahu cara bikinnya. Kamu tidak perlu tahu detail prosesnya.

💡 Itulah Tell, Don’t Ask — fokus pada apa yang perlu dilakukan, bukan bagaimana dilakukan.

6. Penerapan di React (Contoh Nyata)

Misalnya kamu punya component React:

// ❌ Melanggar TDA
if (user.role === "admin") {
  showAdminMenu()
}

Ubah jadi:

// ✅ Mengikuti TDA
user.showMenu()

Lalu logic siapa yang boleh melihat menu diletakkan di dalam object atau hook user.
Dengan begitu, component React kamu tetap bersih dan tidak tahu detail internal role user.

7. Kesimpulan

TDA membantu kita menulis kode yang lebih modular, ekspresif, dan mudah dikembangkan.
Daripada membuat object seperti sekadar wadah data, jadikan mereka aktor yang tahu cara bertindak.

Saya pribadi dulu sering “melanggar” prinsip ini tanpa sadar — suka ambil data dari object lalu olah di luar. Tapi setelah memahami TDA, kode terasa jauh lebih rapi dan terstruktur.

🎯 Intinya:

Tell objects what to do — don’t ask them what they know.