[Series Phỏng Vấn Backend] #1: Lời Giải Cho Sự Phụ Thuộc - Tại Sao Phải Inject Interface?

Chào mừng anh em đến với series Giải Mã Phỏng Vấn Backend. Trong series này, chúng ta sẽ không học vẹt các khái niệm sách giáo khoa. Chúng ta sẽ lấy những câu hỏi hóc búa nhất từ các buổi phỏng vấn thực tế, mổ xẻ nó tận gốc rễ để xem đằng sau những dòng code là tư duy hệ thống như thế nào.

Hôm nay, chúng ta sẽ khởi động với một câu hỏi kinh điển về Dependency Injection (DI) trong Laravel.

1. Bối Cảnh Câu Hỏi (The Context)

Trong một dự án E-commerce, nhà tuyển dụng (hoặc Tech Lead) đưa cho bạn một đoạn code thực tế trong file ShopOnlineSaleService:

protected PickupLocationInterface $pickupLocationRepository;

public function __construct(PickupLocationInterface $pickupLocationRepository)
{
 $this->pickupLocationRepository = $pickupLocationRepository;
}

Nhà tuyển dụng hỏi:

"Thầy/Anh thấy Service này đang phụ thuộc vào một Interface (PickupLocationInterface), chứ không phải một Class cụ thể (ví dụ: PickupLocationRepository). > Tại sao chúng ta lại tiêm (inject) vào một Interface? Việc này mang lại lợi ích gì cho hệ thống? Và câu hỏi phụ: Bản thân Interface không thể khởi tạo thành object, vậy làm thế nào Laravel biết được phải lấy Class cụ thể nào để nhét vào đây?"

Nếu bạn chỉ trả lời "để dễ thay đổi code", bạn chỉ được 5 điểm. Để đạt điểm tuyệt đối và thể hiện đẳng cấp của một kỹ sư phần mềm, đây là câu trả lời dành cho bạn.

2. Phân Tích Chuyên Sâu (The Deep-Dive)

Câu hỏi này chạm đến trái tim của Dependency Inversion Principle (DIP) – chữ D trong nguyên lý SOLID huyền thoại.

Nguyên lý DIP phát biểu: "Các module cấp cao (như Service của chúng ta) không nên phụ thuộc vào các module cấp thấp (như Repository/Database). Cả hai nên phụ thuộc vào một abstraction (Interface/Abstract Class)."

Việc tuân thủ nguyên lý này bằng cách Inject Interface mang lại 3 "siêu lợi ích" cho dự án:

Lợi ích 1: Giảm sự kết dính (Loose Coupling)

Khi tiêm Interface, ShopOnlineSaleService trở nên hoàn toàn "mù" về tầng cơ sở dữ liệu. Nó không cần biết dữ liệu đang được lấy từ MySQL, MongoDB, Redis hay call từ một API Microservice khác. Nó chỉ quan tâm duy nhất một điều: "Kẻ được truyền vào chắc chắn sở hữu những hành động (methods) đã được ký kết trong bản hợp đồng Interface". Sự tách bạch này giúp code của bạn không bị dính chặt vào một công nghệ cụ thể.

Lợi ích 2: Sự linh hoạt tuyệt đối (Flexibility)

Hãy tưởng tượng kịch bản thực tế: Hôm nay dự án dùng MySQL và bạn có class MySQLPickupLocationRepository. Tháng sau, hệ thống scale lên, sếp yêu cầu chuyển toàn bộ việc lấy vị trí sang gọi API từ một service khác.

• Nếu bạn inject Class cụ thể: Bạn phải mò vào ShopOnlineSaleService, sửa lại type-hint, sửa lại use statement... Rủi ro gây bug là rất lớn.
• Nếu bạn inject Interface: Bạn chỉ cần viết một class mới ApiPickupLocationRepository implement cái Interface cũ. Trong ShopOnlineSaleService bạn không cần sửa dù chỉ một dấu phẩy.

Lợi ích 3: Khả năng Unit Test thần tốc (Testability)

Đây là lợi ích lớn nhất và thiết thực nhất. Khi viết Unit Test cho logic của ShopOnlineSaleService, bạn KHÔNG muốn kết nối trực tiếp với Database thật (vì nó chậm và rủi ro thay đổi data). Nhờ việc dùng Interface, bạn có thể dễ dàng tạo ra một Mock Object (đối tượng giả lập) để mô phỏng dữ liệu trả về. Quá trình test diễn ra độc lập, siêu nhanh và không sinh ra "rác" trong database.

3. "Phép Thuật" Của Laravel: Service Container

Trả lời xong phần lợi ích, nhà tuyển dụng sẽ vặn vẹo tiếp: "PHP thuần không tự hiểu được Interface. Vậy thằng nào đã đứng ra new Object và nhét vào constructor cho em?"

Câu trả lời chính là Service Container (hay IoC Container) – trái tim của framework Laravel. Để phép thuật này hoạt động, chúng ta phải làm 2 bước:

Bước 1: Ký kết hợp đồng (Binding) tại Service Provider Bạn phải dạy cho Laravel biết cách xử lý khi có ai đó đòi Interface. Việc này thường được cấu hình trong hàm register() của một Provider (ví dụ: RepositoryServiceProvider):

// file: app/Providers/RepositoryServiceProvider.php

public function register()
{
 // Báo cho Laravel: Khi có class nào đòi Interface A, hãy đưa cho nó Class B
 $this->app->bind(
 \App\Repositories\Contracts\PickupLocationInterface::class, 
 \App\Repositories\Eloquents\PickupLocationRepository::class 
 );
}

Bước 2: Quá trình Auto-Wiring (Tự động tiêm)

Khi hệ thống chạy và một Request gọi đến ShopOnlineSaleService, ở hậu trường, Laravel sẽ làm những việc cực kỳ tinh vi sau:

1. Nó sử dụng Reflection API (một tính năng của PHP cho phép đọc ngược cấu trúc của code).
2. Nó quét hàm __construct của ShopOnlineSaleService và phát hiện: "À, class này đang cần tham số type là PickupLocationInterface".
3. Nó lật cuốn "danh bạ" (Service Container) ra tra cứu xem có ai đã đăng ký Interface này chưa.
4. Nó thấy dòng khai báo ở Bước 1. Lập tức, Laravel tự động chạy lệnh new PickupLocationRepository(), khởi tạo object và âm thầm nhét (inject) vào constructor cho bạn.

Mọi thứ diễn ra mượt mà, không một chút dấu vết!

4. Tổng Kết

Câu hỏi về Interface và Dependency Injection không phải là để làm khó nhau, mà để xem bạn có tư duy thiết kế phần mềm linh hoạt (Agile) hay không. Bằng cách dùng Interface, bạn biến hệ thống của mình thành những khối Lego độc lập. Khi một viên gạch hỏng hoặc lỗi thời, bạn chỉ cần tháo nó ra và lắp viên mới vào, thay vì phải đập đi xây lại toàn bộ tòa nhà.

*** Anh em đã từng gặp câu hỏi hóc búa nào về Architecture Design trong lúc phỏng vấn chưa? Hãy để lại dưới phần bình luận, mình sẽ chọn ra một câu hay nhất để "giải mã" trong số #2 nhé! Đừng quên Upvote để ủng hộ series!