Nhận diện abstraction sai — over-engineering trap và cách sửa

TL;DR: Abstraction mạnh, nhưng abstraction sai tệ hơn không có abstraction — nó khoá design vào dự đoán sai và biến code thành ceremony. Bài này dạy cách nhận diện 4 trap over-engineering: interface chỉ có 1 implementation, abstraction không ai dùng polymorphic, premature abstraction (abstract trước khi đủ thông tin), và abstraction giả tạo (caller vẫn hardcode concrete). Công cụ phòng thủ: YAGNI và rule of 3 — chờ 3 case thực tế mới abstract. Phần cuối là case study payment system: abstraction đúng trông như thế nào, và vì sao nó tự nhiên đạt Open/Closed Principle. Kèm 5 pitfall tổng hợp với code sai/đúng đối chiếu.

Bài 01 dạy bạn quy trình 5 bước để tạo abstraction. Bài này dạy kỹ năng ngược lại — và quan trọng không kém: nhận ra khi nào abstraction là thừa, sai, hoặc quá sớm.

Codebase legacy nào cũng có vài chục BaseFooService, AbstractBarHandler, IBazManager mà không một dòng code nào dùng chúng polymorphic. Mỗi abstraction thừa là một file thêm để đọc, một tầng indirection để nhảy qua khi debug — chi phí trả hàng ngày, lợi ích không bao giờ đến. Học cách nhận diện chúng sớm rẻ hơn nhiều so với refactor sau 2 năm.

1. Khi nào KHÔNG trừu tượng — 4 trap over-engineering

Abstraction mạnh, nhưng lạm dụng tệ hơn không dùng. Dấu hiệu over-engineering:

Trap 1 — Interface cho 1 implementation

interface UserRepository {
    User findById(long id);
}

class UserRepositoryImpl implements UserRepository {
    User findById(long id) { ... }
}

Interface UserRepository có chỉ 1 implementation UserRepositoryImpl. Abstraction thừa — chỉ tăng 1 file, không thêm giá trị.

Trừ khi: có test double (mock) — nhưng modern testing dùng Mockito mock class trực tiếp, không cần interface.

Rule: YAGNI (You Ain't Gonna Need It). Chỉ abstract khi có ≥2 impl thực tế hoặc chắc chắn cần thay trong tương lai gần.

Trap 2 — Abstraction không có use case

Code legacy đầy BaseFooService, AbstractBarHandler, IBazManager mà không có code thực sự polymorphic. Abstract được thêm "cho đúng pattern" — giờ là dead weight.

Rule: mỗi abstraction phải trả lời được "code nào dùng abstraction này thay vì concrete?". Không trả lời được thì xoá abstraction.

Trap 3 — Abstraction quá sớm (premature abstraction)

// Nghi "mot ngay nao do se co cac loai notification"
interface Notifier {
    void send(Notification n);
}

class EmailNotifier implements Notifier {
    void send(Notification n) { ... }
}

Hiện tại chỉ có email. SMS, push notification — tương lai có thể. Viết abstraction ngay — chi phí thêm class, nhưng chưa dùng polymorphism.

Tương lai khi thêm SMS, requirements có thể khác — abstraction hiện tại không phù hợp. Phải sửa abstraction + email impl + thêm SMS impl. Tốn hơn bắt đầu concrete + refactor khi thực sự cần.

Rule: rule of 3. Khi có 3 implementation (không phải 2) thường mới đủ rõ ràng để abstract.

Trap 4 — Abstraction không thay đổi được

Code dùng new EmailNotifier() trực tiếp trong 50 chỗ. "Abstraction" chỉ có trong class, nhưng caller hardcode nên không thể thay. Abstraction giả tạo — tên interface nhưng coupling cụ thể.

Fix: dependency injection (Spring @Autowired, constructor inject). Caller nhận Notifier, không new trực tiếp.

flowchart TD
    A{Co bao nhieu implementation thuc te?} -->|1| B[Concrete class - YAGNI]
    A -->|2| C{Chac chan se co impl thu 3?}
    A -->|3 tro len| D[Abstract - pattern da ro]
    C -->|Khong chac| B
    C -->|Co| E{Co code nao dung no polymorphic khong?}
    E -->|Khong| B
    E -->|Co| D

2. Case study — design "payment system"

Để thấy abstraction đúng trông như thế nào (đối chiếu với 4 trap trên), xét bài tập thực tế: design thanh toán với nhiều provider.

Phân tích

Thực thể cụ thể:

• Credit card Stripe
• Credit card PayPal
• E-wallet MoMo
• Bank transfer Vietcombank
• Crypto payment Bitcoin

Use case: user chọn 1 phương thức, charge số tiền, nhận kết quả success/fail.

Chú ý: ở đây có 5 implementation thực tế ngay từ đầu — vượt rule of 3, abstraction không hề premature.

Abstraction

Điểm chung: charge(amount) trả về result. Đó là core abstraction.

interface PaymentProvider {
    PaymentResult charge(BigDecimal amount, PaymentContext context);
    RefundResult refund(String transactionId);
    String providerName();
}

record PaymentResult(boolean success, String transactionId, String errorCode) {}

Mỗi provider implement riêng:

class StripeProvider implements PaymentProvider {
    public PaymentResult charge(BigDecimal amount, PaymentContext ctx) {
        // HTTP call Stripe API
    }
}

class MoMoProvider implements PaymentProvider { ... }
class CryptoProvider implements PaymentProvider { ... }

Code caller — không biết provider cụ thể

class CheckoutService {
    private final Map<String, PaymentProvider> providers;   // injected

    public void pay(String providerId, BigDecimal amount) {
        PaymentProvider p = providers.get(providerId);
        PaymentResult r = p.charge(amount, buildContext());
        if (r.success()) markOrderPaid(r.transactionId());
        else handleFailure(r.errorCode());
    }
}

Thêm provider Stripe, MoMo, Bitcoin — CheckoutService không đổi 1 dòng. Đây là power of abstraction.

Đối chiếu với 4 trap:

• Có 5 implementation thật (không phạm trap 1, trap 3).
• CheckoutService chính là code dùng abstraction polymorphic (không phạm trap 2).
• Provider được inject qua Map, không new hardcode (không phạm trap 4).

Open/Closed Principle

Pattern trên là ví dụ của OCP (Open for extension, Closed for modification — SOLID):

• Open for extension: thêm PaymentProvider mới bằng class mới.
• Closed for modification: CheckoutService không sửa khi thêm provider.

Abstraction đúng thì OCP đến tự nhiên. Abstraction sai khiến mỗi lần thêm feature phải sửa code cũ — hệ thống fragile.

3. Pitfall tổng hợp

❌ Nhầm 1: Abstraction vô nghĩa cho 1 implementation.

interface UserRepository { User findById(long id); }
class UserRepositoryImpl implements UserRepository { ... }   // Chi co 1 impl

✅ Concrete class trước. Abstract khi có nhu cầu thực sự.

❌ Nhầm 2: Abstraction quá sớm.

// Nghi "tuong lai se co nhieu loai"
interface Foo { ... }
class FooV1 implements Foo { ... }

✅ Rule of 3 — chờ đến khi có ≥2-3 impl thực tế.

❌ Nhầm 3: God abstraction — 1 interface chứa mọi method.

interface Document {
    void print();
    void scan();
    void fax();
    void email();
}
// Impl "BasicPrinter" phai throw UnsupportedOperationException cho scan/fax

✅ Interface Segregation: tách Printable, Scannable, Faxable, Emailable. Class implement đúng interface.

❌ Nhầm 4: Abstraction leak — method lộ chi tiết impl.

interface Cache {
    Map<String, Object> getInternalMap();   // Lo Map - caller depend implementation
}

✅ Method chỉ expose behavior: get(key), put(key, value). Đổi từ Map sang Redis không break API.

❌ Nhầm 5: Abstraction không test được.

class Service {
    EmailSender sender = new EmailSender();   // hardcoded
}

✅ Dependency injection: Service(EmailSender sender). Test inject mock.

4. 📚 Deep Dive

5. Tóm tắt

• Abstraction sai tệ hơn không có abstraction — nó khoá design vào dự đoán sai, thêm indirection vô ích.
• 4 trap: (1) interface 1 implementation, (2) abstraction không ai dùng polymorphic, (3) premature abstraction, (4) abstraction giả tạo — caller vẫn new concrete.
• YAGNI: không xây cho nhu cầu tưởng tượng. Rule of 3: 2 case có thể là trùng hợp, 3 case mới là pattern.
• Test một abstraction: "code nào dùng nó thay vì concrete?" — không trả lời được thì xoá.
• Abstraction giả tạo fix bằng dependency injection — caller nhận interface qua constructor, không tự new.
• Case study payment: 5 provider thực tế + caller polymorphic + injection = abstraction đúng, OCP tự nhiên.
• Refactor concrete thành abstraction khi cần (Extract Interface) rẻ hơn nhiều so với gỡ abstraction sai đã ăn sâu.

6. Tự kiểm tra

interface Cache {
  HashMap<String, Object> getInternalMap();   // Lo HashMap
}

interface Cache {
  Optional<Object> get(String key);
  void put(String key, Object value);
  void evict(String key);
}

Bài tiếp theo: extends và super — kế thừa từ class cha