Tầm quan trọng của Loose Coupling trong hệ thống Backend

FLOW TRÊN BAO GỒM 6 BƯỚC:

• Step 1: Chúng ta có 1 đoạn code Tight Coupling (ví dụ nên lấy 1 đoạn thôi, nhiều quá khó đọc lém)
• Step 2: Implement IoC sử dụng Factory Pattern
• Step 3: Apply DIP (chữ D trong SOLID)
• Step 4: Implement DI – Dependancy Injection
• Step 5: Sử dụng IoC Container
• Step 6: Chúng ta đạt được Loose Coupling (Vui tại đây)

Step 1 đã giới thiệu xong, bây giờ đến step 2 nhé.

À, 6 step ở trên chắc các bạn đã hiểu được step 1 và step 6 rồi, còn 4 step còn lại, chúng ta sẽ cùng nhau đi qua từng bước một. Các bạn đừng lo, nó thật sự dễ hiểu lắm nếu bạn thật sự tập trung.

IMPLEMENT IOC USING FACTORY PATTERN

TRƯỚC TIÊN CÙNG TÌM HIỂU IOC LÀ GÌ?

Inversion of Control (IoC) là một design principle (mặc dù, một số người gọi nó là design pattern), nhớ nha, là design principle. Như tên gọi, nó được sử dụng để đảo ngược sự điều khiển (control) trong thiết kế hướng đối tượng để đạt được sự kết hợp lỏng lẻo (loose coupling). Ở đây, điều khiển bao gồm điều khiển flow của việc tạo ra một đối tượng (object creation) hoặc tạo đối tượng phụ thuộc (dependency creation) và việc quản lý, cung cấp đối tượng được tạo ra cho ứng dụng trong quá trình ứng dụng running.

Nguyên lý IoC giúp thiết kế các class trở nên lỏng lẻo hơn (loose coupling), giúp chúng có thể unit test, maintain và mở rộng dễ dàng hơn.

IoC hoàn toàn về việc đảo ngược điều khiển. Ái chà, cái “sự giải thích” ở trên khá là khoai và khó hiểu nhỉ?

Để mình giải thích điều này theo ngôn ngữ thông thường. Giả sử bạn lái xe đến nơi làm việc, điều này có nghĩa là bạn điều khiển chiếc xe. Nguyên lý IoC đề xuất đảo ngược điều khiển, có nghĩa là thay vì tự lái xe, bạn thuê một chiếc taxi, nơi một người khác sẽ lái xe. Do đó, điều này được gọi là đảo ngược điều khiển – từ bạn sang tài xế taxi. Bạn không phải tự lái xe và bạn có thể để tài xế lái xe để bạn có thể tập trung vào công việc chính của mình. Cái đích cuối cùng là bạn muốn đến nơi làm việc thôi, việc còn lại không cần quan tâm nữa.

Tới đây có thể bạn có hình dung ra phần nào rồi. Tới đoạn dưới bạn đọc code thì sẽ hiểu 100%.

TIẾP TỤC THÔI!

À xem cái hình trước.

Ở hình trên thì chúng ta có khá nhiều design pattern để có thể implement IoC. Trong phần này, chúng ta sẽ sử dụng Factory pattern để implement IoC. Đằng sau chúng ta sẽ dùng pattern Dependency injection rất là bá :)))

Ok lets go!

Chúng ta sẽ thử sử dụng Factory Pattern để “Invert control” hay gọi là đảo ngược sự điều khiển.

class UserService {
    // (Ở đây còn Tight coupling)
    private MySQLUserRepository $userRepository;

    public function __construct() {
        // Đảo ngược chổ này nè
        // (Ở đây cũng còn một chút Tight coupling)
        $this->userRepository = UserRepositoryFactory::getUserRepository();
    }

    public function getById(int $id): string {
        // Application logic here

        return $this->userRepository->getById($id);
    }
}

public class UserRepositoryFactory
{
    public static function getUserRepository(): MySQLUserRepository
    {
        return new MySQLUserRepository();
    }
}

Ở ví dụ ban đầu, UserService đang điều khiển (control) MySQLUserRepository các việc như tạo, quản lý object bằng từ khoá new đó nhớ không? Nhưng khi chúng ta apply Factory thì việc điều khiển class MySQLUserRepository đã được đẩy về Factory. Nên UserService không còn điều khiển MySQLUserRepository nữa. Đây là concept của IoC. Đảo ngược sự điều khiển. Tới đây hiểu rồi chứ? Không hiểu thì quay lại nha. Quay đi quay lại 10 lần không hiểu thì mình chịu, để lại comment dưới mình sẽ giải thích thắc mắc.

Tuy nhiên, với việc apply IoC sử dụng Factory pattern, đoạn code của chúng ta vẫn chưa hoàn toàn đạt được loose coupling. Bởi vì nhìn dòng số 3, và số 8 ở đoạn code trên, UserService vẫn còn … dính tới MySQLUserRepository và UserRepositoryFactory.

Bây giờ chúng ta sẽ đi tới step tiếp theo?

APPLY DEPENDENCY INVERSION PRINCIPLE (DIP)

DIP LÀ GÌ?

Là nguyên lý D trong SOLID – Dependency Inversion Principle. Mình có viết 1 bài về chữ D này ở đây. Nguyên lý này nói rằng:

• High-level modules should not depend on low-level modules. Both should depend on the abstraction.
• Abstractions should not depend on details. Details should depend on abstractions.

Nghe có vẻ hơi lú thật, nhưng bạn sẽ hiểu ngay thôi. Mình hứa!

Quay lại đoạn code ban đầu, thì một cách rất rất dễ hiểu:

• High-level modules chính là UserService
• Low-level modules chính là MySQLUserRepository

Ở ví dụ trên:

• High-level modules và Low-level modules đang phụ thuộc cứng vào nhau (mặc dù đã dùng Factory implement IoC)
• Và cũng chẳng có cái gì trừu tượng (abstractions) ở đây cả.

Bây giờ chúng ta sẽ làm sao đó, tìm cách implement DIP.

class UserService {
    // Bây giờ dùng interface ở đây
    private UserRepositoryInterface $userRepository;

    public function __construct() {
        $this->userRepository = UserRepositoryFactory::getUserRepository();
    }

    public function getById(int $id): string {
        // Application logic here

        return $this->userRepository->getById($id);
    }
}

public class UserRepositoryFactory
{
    public static function getUserRepository(): UserRepositoryInterface
    {
        return new MySQLUserRepository();
    }
}

// MySQLUserRepository implement UserRepositoryInterface

Chúng ta đã tạo ra UserRepositoryInterface và bây giờ:

• High-level modules và Low-level modules hiện tại chỉ đang phụ thuộc vào 1 interface (UserRepositoryInterface).
• Và MySQLUserRepository phụ thuộc vào interface chứ interface không phụ thuộc vào MySQLUserRepository.

Ghê, đổi có xíu mà thoã mãn luôn cả 2 cái câu trên của DIP, thiệt là quá đỉnh :)))

ĐÃ ĐẠT ĐƯỢC LOOSE COUPLING?

Nhưng chúng ta vẫn còn cấn UserRepositoryFactory::getUserRepository(). Thử tưởng tượng khi chúng ta cần inject động vài depedency vào MySQLUserRepository thì chúng ta phải change UserServicenhư sau:

$this->userRepository 
= UserRepositoryFactory::getUserRepository($dependencyA, $dependencyB);

Hoặc đơn giản là muốn sửa đổi thằng UserRepositoryFactory thì chúng ta vẫn đôi khi phải modify thằng UserService.

Chúng ta vẫn chưa hoàn toàn đạt được LOOSE COUPLING!!

Hummmm, bây giờ phải làm sao nhỉ? Quay lại cái hình nào, chúng ta vẫn còn step 4.

Mình sắp tới đích rồi các bạn. Bây giờ chúng ta sẽ thử implement Dependency Injection.

IMPLEMENT DEPENDENCY INJECTION ĐỂ HOÀN TOÀN ĐẠT ĐƯỢC LOOSE COUPLING

DEPENDENCY INJECTION – DI LÀ GÌ?

DI – Dependency Injection nghĩ đơn giản là inject (tiêm, chích, …) một dependency vào một class. Và có 3 loại inject:

• Constructor injection (cách này hay xài)
• Method injection (cái này cũng hay xài)
• Property injection (cái này ít xài hơn)

Ví dụ:

// UserService.php
// Cái này gọi là inject (tiêm) $repo vào UserService
public function __construct(Repo $repo)

Quay lại ví dụ trên.

Thay vì dùng Factory pattern ở Step 2 (tới đây thì bạn hãy quên đi step 2 là được), bây giờ chúng ta thử dùng … Dependency Injection. Và bạn cần nhớ là DI là một design pattern giúp mềnh hiện thức hoá IoC.

class UserService {
    private UserRepositoryInterface $userRepository;

    // Chổ này là Dependency injection nè
    public function __construct(UserRepositoryInterface $userRepository) {
        $this->userRepository = $userRepository;
    }

    public function getById(int $id): string {
        // Application logic here

        return $this->userRepository->getById($id);
    }
}

Đừng quên là chúng ta inject vào nhưng vẫn kết hợp DIP cùng với Dependency injection ở step 3 (nghĩa là vẫn dùng interface nhé)

Ok done! Giờ chúng ta kiểm tra lại code.

Khi muốn đổi MySQLUserRepository: Ví dụ thay đổi class name, thay đổi constructor params, hay đổi luôn thành MongoUserRepository, hay làm ABC XYZ nào đó, thì class UserService vẫn không thay đổi.

Và khi muốn viết unit test cho UserService, quá đơn giản, UserRepositoryInterface mock mốt phát một là xong! (Ở đây bạn nào chưa biết viết unit test và chưa biết mock là gì thì search google 1 chút nhé)

VẬY LÀ NGON CHƯA?

Với việc Dùng DI, kết hợp với DIP, chúng ta đã hoàn toàn đạt được Loose Coupling. Đây chính là trạng thái LOOUSE COUPLING mà chúng ta cố gắng đạt được từ ban đầu.

Ấy, sẽ có bạn nhắc là ủa, sao từ step 4 nhảy cóc qua step 6 luôn gồi? À đợi mình chút nhé.

Từ đầu đến giờ, chúng ta luôn thao tác với class UserService. Mà chưa 1 lần thực sự xài nó. Bây giờ xài nha. Giả sử chúng ta xài ở UserController nha.

// Giả sử ở đây là UserController
$userService = new UserService(new MySQLUserRepository());

Ở controller, khi chúng ta muốn xài UserService, vì UserService nó cần một đối tượng nào đó phải implement cái interface UserRepositoryInterface để có thể inject vào đúng không. Ở đây chúng ta khởi tạo MySQLUserRepository để inject vào thôi.

Nếu đoạn đó ở controller thì chúng ta cứ tạm gọi là “ổn” đi cho tới khi chúng ta làm thực tế :)))

public function __construct(
        PluginService $plugin_service,
        FileRepositoryInterface $file_repository,
        MemberListService $member_list_service,
        TargetService $target_service,
        ConfigRepositoryInterface $config_repository,
        paramRepositoryInterface $param_repository
    ) {
        $this->pluginService = $plugin_service;
        $this->fileRepository = $file_repository;
        $this->memberListService = $member_list_service;
        $this->targetService = $target_service;
        $this->configRepository = $config_repository;
        $this->paramRepository = $param_repository;
    }

Thực tế thì 1 class nó phụ thuộc vào 5, 7 class hoặc nhiều hơn là chuyện bình thường. Và mỗi class dependency nó lại phụ thuộc vài class nữa

Và đây là controller trong thực tế case trên :))).

$use_case = new ViewPlugin(
            new PluginService(
                new MySQLPluginRepository(), 
                new MySQLUserRepository()),
            new InMemoryFileRepository(),
            new MemberListService(),
            new TargetService(
                new TargetRepository(),
                new MemberListService(new MySQLUserRepository())
            ),
            new ConfigRepository(),
            new ParamRepository()
        );

$use_case->execute($plugin_id);

Nhìn hoảng thật!!!!

Làm sao để giải quyết vấn đề trên? IoC Container sẽ giúp chúng ta giải quyết vấn đề nan giải này.

SỬ DỤNG IOC CONTAINER

IOC CONTAINER LÀ GÌ?

IoC thì hiểu rồi đó, thế nó thêm chữ container vào làm gì nhỉ? Xe container chăng?

Chúng ta hiểu đơn giản, nó là cái hộp (box hay container) thật.

IoC Container (hay còn được gọi là DI Container) là một framework để thực hiện việc tiêm phụ thuộc tự động (automatic dependency injection). Nó quản lý việc tạo đối tượng (object creation) và thời gian sống của đối tượng, cũng như tiêm các phụ thuộc vào lớp khi cần.

Nghĩa là sao?

• IoC —> Đảo ngược sự điều khiển
• Dependency injection —> Implement thằng IoC để đảo ngược sự điều khiển, nhưng ông developer phải làm bằng tay (dùng new ở controller ở trên đó)
• Và IoC Container —> nó vừa đảo ngược sự điều khiển và nó làm luôn nhiệm vụ tạo ra đối tượng và tự inject vào luôn. Chúng ta sẽ không thấy chữ “new” nữa

Nói dài hơn là thế này: IoC container tạo một đối tượng của lớp được chỉ định và cũng tiêm tất cả các đối tượng phụ thuộc thông qua một constructor, một thuộc tính hoặc một phương thức tại thời gian chạy và hủy nó vào thời điểm thích hợp. Điều này được thực hiện để chúng ta không phải tạo và quản lý các đối tượng một cách thủ công.

Cho nên khi chúng ta apply IoC Container, chúng ta hoàn toàn chuyển quyền điều khiển “control“ về framework. Container sẽ quản lý dependency và tiêm nó vào lúc chúng ta cần.

Thử apply 1 vài cái container xem nào :)))

MỘT VÀI VÍ DỤ

Ví dụ khi apply PHP-DI Container:

// binding / mapping, ...
[
    'PluginRepositoryInterface' => MySQLPluginRepository::class,
    'UserRepositoryInterface'   => MySQLUserRepository::class,
    'FileRepositoryInterface'   => InMemoryFileRepository::class,
    ...
];

$container = new DI\Container();
$use_case = $container->get('ViewPlugin'); // Đúng 1 dòng này

Cái ViewPlugin ở trên nó phụ thuộc cả chục dependency nhớ không các bạn? Bây giờ với việc apply PHP-DI container, chúng ta chỉ cần config chỉ định cho container biết là interface nào sẽ được map với class nào trong quá trình running. Còn việc new new new chục cái dependency và tự động inject vào khi cần đã thuộc về container, chúng ta không cần làm gì nữa. Chỉ cần đúng 1 dòng: $use_case = $container->get('ViewPlugin');

Còn đây là ví dụ khi dùng Spring IoC Container:

@Service
public class ViewPlugin {

    private PluginService pluginService;
    private FileRepositoryInterface fileRepository;

    ...
    @Autowired
    public ViewPlugin(
        PluginService pluginService, 
        @Qualifier("InMemoryFileRepository") FileRepositoryInterface fileRepository
    ) {
        this.pluginService = pluginService;
        this.fileRepository = fileRepository;
    }

    public void execute(String pluginId) {
        // ...
    }
}

Tương tự trong Spring IoC Container, chúng ta cần chỉ định class nào sẽ được map với interface bằng Anotation @Qualifier, và dùng @Autowired để thông báo cho container biết rằng chổ này tôi cần tiêm 1 số dependency vào.

Ok tới đây cũng gần kết rồi, bài viết thì cũng dài, bạn nào đọc được dòng này và “wow” lên thì xin chúc mừng bạn đã thấu hiểu được 1 trong những concept quá là đỉnh khi làm việc với OOP và cụ thể hơn là thiết kế backend.

TÚM CÁI VÁY LẠI MỘT XÍU CHO DỄ NHỚ VỀ LOOSE COUPLING

LOOSE COUPLING GIÚP HỆ THỐNG CỦA CHÚNG TA XỊN HƠN!!!!

• IoC: Đảo ngược sự điều khiển, thường là đùn đẩy trách nhiệm điều khiển cho framework làm luôn
• DI: Tiêm đối tượng vào class/module
• DIP: Xem xét xử dụng abstraction (interface)
• IoC Container: Một cái hộp – tạo, quản lý, và tự động inject dependency khi cần

Và một điều cũng quan trọng, loose coupling là trạng thái lỏng lẽo thôi, chứ không phải là hoàn toàn không phụ thuộc nữa. Đó chính là đặc tính của lập trình hướng đổi tượng vì interface thường ít bị thay đổi hơn….

Và không phải lúc nào chúng ta cũng phải sử dụng interface đâu nhé. Việc này là phải cân nhắc, ví dụ interface thường được dùng ở tầng repository và tầng service. Và một số nơi khác khi chúng ta muốn switch qua lại giữa các implementation (giống như lúc thì xài cái này, lúc xài cái kia nhưng cả 2 cái đều có hành vi là giống nhau, chỉ khác nhau phần logic ruột – method body).

KẾT LUẬN

Để quản lý tốt dependency khi thiết kế phần mềm (đạt được loose coupling), chúng ta có thể dùng:

• DIP (hiểu đơn giản là dùng interface hoặc abstract khi cần thiết)
• Dependency injection (DI là 1 design pattern của IoC) để inject dependency vào class.

• Khi đã sử dụng 2 ông trên chúng ta đã đạt được loose coupling. Và để quản lý việc khởi tạo, tự động inject dependency, chúng ta sử dụng thêm IoC Container là mọi thứ … ỔN

VÀ ĐÂY LÀ KIẾN TRÚC CỦA HẦU HẾT BACKEND FRAMEWORK HIỆN TẠI.

Cám ơn các bạn đã đọc bài viết.