Thông não Java Design Pattern – Dependency Injection

Bài viết được sự cho phép của tác giả Nguyễn Hữu Khanh

Với lập trình hướng đối tượng, chúng ta thường xuyên làm việc với rất nhiều class trong một chương trình, các class được liên kết với nhau theo một mối quan hệ nào đó. Dependency là một loại quan hệ giữa 2 class mà trong đó một class hoạt động độc lập và class còn lại phụ thuộc bởi class kia. Sự phụ thuộc chặt chẽ này gây rất nhiều khó khăn khi hệ thống cần thay đổi, nâng cấp. Để giải quyết vấn đề này chúng ta có thể sử dụng Dependency Injection (DI), một dạng design pattern được thiết kế nhằm ngăn chặn sự phụ thuộc nêu trên.

DI – Dependency Injection

Dependency Inversion Principle (DIP), Inversion of Control (IoC), Dependency Injection (DI) là gì

Trước khi bắt đầu với Dependency Injection, các bạn hãy dành chút thời gian xem lại nguyên lý SOLID trong OOP. Nguyên lý cuối cùng, tương ứng với chữ D trong SOLID chính là DIP – Dependency Inversion Principle (nguyên lý đảo ngược sự phụ thuộc). Nội dung của nguyên lý này như sau :

• Các module cấp cao không nên phụ thuộc vào các module cấp thấp. Cả 2 nên phụ thuộc vào abstraction.
• Interface (abstraction) không nên phụ thuộc vào chi tiết, mà ngược lại, chi tiết nên phụ thuộc vào abstraction. Các class giao tiếp với nhau thông qua interface, không phải thông qua implementation.

Chúng ta thường hay lẫn lộn giữa các khái niệm Dependency Inversion Principle (DIP), Inversion of Control (IoC), Dependency Injection (DI). Ba khái niệm này tương tự nhau, tất cả đều hướng đến một mục đích duy nhất là tạo ra ứng dụng ít kết dính (loosely coupling), dễ mở rộng (flexibility) cũng như giúp lập trình viên tập trung chủ yếu vào công việc business flow.

>>> Xem thêm: Các phần mềm giả lập Java dành cho máy tính tốt nhất

Sự khác biệt giữa 3 khái niệm trên như sau:

• Dependency Inversion Principle (DIP): là một nguyên lý để thiết kế và viết code.
• Inversion of Control (IoC): là một design pattern được tạo ra để code có thể tuân thủ nguyên lý Dependency Inversion. Có nhiều cách hiện thực Pattern này như ServiceLocator, Event, Delegate, … và Dependency Injection là một trong các cách đó.
• Dependency Injection (DI): là một Design Pattern, một cách để hiện thực Inversion of Control Pattern. DI chính là khả năng liên kết giữa các thành phần lại với nhau, các module phụ thuộc (dependency) sẽ được inject vào module cấp cao.

Đơn giản chúng ta chỉ cần ghi nhớ:

DI is about wiring, IoC is about direction, and DIP is about shape.

IoC là hướng đi, DIP là định hình cụ thể của hướng đi, còn DI là một hiện thực cụ thể.

https://martinfowler.com/articles/dipInTheWild.html

Định nghĩa và khái niệm Dependency Injection

Dependency Injection (DI) là một design pattern, một kỹ thuật cho phép xóa bỏ sự phụ thuộc giữa các module, làm cho ứng dụng dễ dàng hơn trong việc thay đổi module, bảo trì code và testing.

DI cung cấp cho một đối tượng các thể hiện phụ thuộc (dependencies) của nó từ bên ngoài truyền vào mà không phải khởi tạo trực tiếp từ trong class sử dụng.

Nhiệm vụ của dependency injection:

• Tạo các đối tượng.
• Quản lý sự phụ thuộc (dependencies) giữa các đối tượng.
• Cung cấp (inject) các phụ thuộc được yêu cầu cho đối tượng (được truyền từ bên ngoài đối tượng).

Nguyên tắc hoạt động của DI:

• Các module không giao tiếp trực tiếp với nhau, mà thông qua interface. Module cấp thấp sẽ implement interface, module cấp cao sẽ gọi module cấp thấp thông qua interface.
• Việc khởi tạo các module cấp thấp sẽ do DI Container/ IoC Container thực hiện.
• Việc Module nào gắn với interface nào sẽ được config trong file properties, trong file XML hoặc thông qua Annotation. Annotation là một cách thường được sử dụng trong các Framework, chẳng hạn như @Inject với CDI, @Autowired với Spring hay @ManagedProperty với JSF.

Tham khảo việc làm Java Fresher HOT trên Station D!

Cài đặt Dependency Injection như thế nào?

Các thành phần tham gia Dependency Injection Pattern:

• Client : là một class cần sử dụng Service.
• Service : là một class/ interface cung cấp service/ dependency cho Client.
• ServiceImpl: cài đặt các phương thực cụ thể của Service.
• Injector: là một lớp chịu trách nhiệm khởi tạo các service và inject các thể hiện này cho Client.

Các dạng Dependency Injection

• Constructor Injection: Các dependency sẽ được container truyền vào (inject vào) 1 class thông qua constructor của class đó. Đây là cách thông dụng nhất.
• Setter Injection: Các dependency sẽ được truyền vào 1 class thông qua các hàm Setter.
• Fields/ properties: Các dependency sẽ được truyền vào 1 class một cách trực tiếp vào các field.
• Interface Injection: Class cần inject sẽ implement 1 interface. Interface này chứa 1 hàm tên Inject. Container sẽ injection dependency vào 1 class thông qua việc gọi hàm Inject của interface đó. Đây là cách rườm rà và cũng ít được sử dụng.
• Service Locator: nó hoạt động như một mapper, cho phép thay đổi code tại thời điểm run-time mà không cần biên dịch lại ứng dụng hoặc phải khởi động lại.

>>> Xem thêm: Java Reflection là gì? Hướng dẫn Java Reflection API

Ví dụ sử dụng Dependency Injection

Ví dụ chúng ta có một class cho phép User có thể gửi message.

EmailService.java

package com.gpcoder.patterns.creational.dependencyinjection.message.simple;

public class EmailService {

    public void sendEmail(String message) {
        System.out.println("Message: " + message);
    }
}

UserController.java

package com.gpcoder.patterns.creational.dependencyinjection.message.simple;

public class UserController {

    private EmailService emailService = new EmailService();

    public void send() {
        emailService.sendEmail("Hello Dependency injection pattern");
    }
}

Chương trình trên rất đơn giản, chỉ gồm có 2 class. Tuy nhiên, nó có một vài giới hạn như sau:

• Lớp UserController phụ thuộc trực tiếp vào class EmailService. Mỗi khi có thay đổi trong lớp EmailService, chẳng hạn thêm tham số cho constructor của class này lên sẽ ảnh hưởng trực tiếp đến class UserController.
• Một User khác không muốn sử dụng cách gửi message thông qua email, chẳng hạn qua sms, facebook, …
• Khó khăn khi viết Unit Test cho UserController do phụ thuộc trực tiếp vào EmailService.

Bây giờ chúng ta sẽ áp dụng Dependency Injection để giải quyết các giới hạn trên.

MessageService.java

package com.gpcoder.patterns.creational.dependencyinjection.message.di;

public interface MessageService {

    void sendMessage(String message);
}

EmailService.java

package com.gpcoder.patterns.creational.dependencyinjection.message.di;

public class EmailService implements MessageService {

    @Override
    public void sendMessage(String message) {
        System.out.println("Email message: " + message);
    }
}

MessageService.java

package com.gpcoder.patterns.creational.dependencyinjection.message.di;

public class SmsService implements MessageService {

    @Override
    public void sendMessage(String message) {
        System.out.println("Sms message: " + message);
    }
}

UserController.java

package com.gpcoder.patterns.creational.dependencyinjection.message.di;

public class UserController {

    private MessageService messageService;

    public UserController(MessageService messageService) {
        this.messageService = messageService;
    }

    public void send() {
        messageService.sendMessage("Hello Dependency injection pattern");
    }
}

DependencyInjectionPatternExample.java

package com.gpcoder.patterns.creational.dependencyinjection.message.di;

public class DependencyInjectionPatternExample {

    public static void main(String[] args) {
        MessageService messageService = new EmailService();
        UserController userController = new UserController(messageService);
        userController.send();
    }
}

Như bạn thấy, thay vì sử dụng trực tiếp lớp EmailService chúng ta sử dụng interface. Lớp UserController không trực tiếp khởi tạo message service mà nó được truyền từ bên ngoài vào. Chính vì vậy mà các lớp không còn phụ thuộc vào nhau, chúng ta có thể dễ dàng sử đổi hay thêm bất kỳ service nào khác mà không ảnh hưởng đến UserController. Đây chính là dạng Constructor Injection của Dependency Injection Pattern.

Tuy nhiên, chương trình trên vẫn còn một hạn chế là chúng ta phải khởi tạo một thể hiện cụ thể cho MessageService ở rất nhiều nơi, chương trình cũng rất khó khăn khi cần thay thế một service cho toàn bộ hệ thống. Để giải quyết vấn đề này, chúng ta có thể áp dụng Inversion of Control Container (IoC container), một nơi để quản lý các thành phần phụ thuộc này và cung cấp thể hiện cụ thể khi cần sử dụng.

Ưu điểm và khuyết điểm của Dependency Injection

Ưu điểm:

• Reduced dependencies: giảm sự kết dính giữa các module.
• Reusable: code dễ bảo trì, dễ tái sử dụng, thay thế module. Giảm boiler-plate code do việc tạo các biến phụ thuộc đã được injector thực hiện.
• Testable: rất dễ test và viết Unit Test.
• Readable: dễ dàng thấy quan hệ giữa các module vì các dependecy đều được inject vào constructor.

Khuyết điểm:

• Khái niệm DI khá khó hiểu đối với người mới tìm hiểu.
• Sử dụng interface nên đôi khi sẽ khó debug, do không biết chính xác module nào được gọi.
• Các object được khởi tạo toàn bộ ngay từ đầu, có thể làm giảm performance.
• Có thể gặp lỗi ở run-time thay vì compile-time.

Sử dụng Dependency Injection khi nào?

Một số trường hợp sử dụng DI:

• Khi cần inject các giá trị từ một cấu hình cho một hoặc nhiều module khác nhau.
• Khi cần inject một dependency cho nhiều module khác nhau.
• Khi cần một vài service được cung cấp bởi container.
• Khi cần tách biệt các dependency giữa các môi trường phát triển khác nhau. Chẳng hạn, với môi trường dev chỉ cần log việc gửi mail, trong môi trường product cần gởi mail thông qua một API thật sự.

Một số thư viện thư viện và Framework triển khai DI: Spring, Inject, JSF, Google Guice, Dagger.

IoC – Inversion of Control

Inversion of Control (IoC) là gì?

Inversion of Control (IoC) là pattern tuân theo Dependency inversion principle.

Inversion of Control (IoC) dịch là đảo ngược điều khiển. Ý của nó là làm thay đổi luồng điều khiển của ứng dụng, giúp tăng tính mở rộng của một hệ thống.

IoC được chia thành 2 loại:

• Dependency Lookup : sẽ tìm kiếm đối tượng phụ thuộc trong khung chứa IoC và sau đó chúng ta có thể dùng code để đưa đối tượng phụ thuộc vào trong đối tượng bị phụ thuộc. Dependency Lookup được chia thành hai loại khác nhau đó là:
  • Dependency Pull: các đối tượng phụ thuộc sẽ được lấy ra từ một nơi mà các đối tượng phụ thuộc đã được đăng ký chứ không phải lấy trực tiếp từ khung chứa.
  • Contextualized Dependency Lookup (CDL): việc lấy đối tượng phụ thuộc xảy ra trực tiếp với khung chứa luôn chứ không thông qua nơi mà đối tượng phụ thuộc đã đăng ký.
• Dependency Injection : sẽ đưa luôn đối tượng phụ thuộc vào đối tượng bị phụ thuộc.

Hollywood principle cũng thường được gọi là một IoC hay DI:

Don’t call me, I’ll call you.

Đừng gọi cho chúng tôi, chúng tôi sẽ gọi cho bạn.

http://wiki.c2.com/?HollywoodPrinciple

Inversion of Control Container (IoC container) là gì?

Khi áp dụng kỹ thuật Dependency Injection, thì một vấn đề khác nảy sinh là làm thế nào chúng ta biết được một lớp sẽ phụ thuộc vào những lớp nào để khởi tạo nó. Để giải quyết điều này, người ta nghĩ ra Dependency Injection Container hay còn gọi là Inversion of Control Container (IoC container).

IoC Container được xây dựng dựa trên ý tưởng của IoC, nó có nhiệm vụ quản lý các thành phần khác nhau, cung cấp tài nguyên cho các thành phần khi chúng đòi hỏi tài nguyên dựa vào thông tin từ các file cấu hình. Nhờ đó việc quản ý sẽ dễ dàng hơn, tập trung hơn và đơn giản, hiệu quả hơn rất nhiều so với việc phải phân tán tài nguyên cho từng thành phần tự xử lý.

Về bản chất thì IoC Conainter như một tấm bản đồ, nó cho ta biết một lớp phụ thuộc vào những lớp nào khác bằng kỹ thuật Reflection, hoặc từ danh sách đã được đăng ký trước.

Sức mạnh của IoC Container được thể hiện thông qua việc nó được áp dụng trong các Framework. Một đặc điểm quan trọng của Framework là các phương thức được định nghĩa bởi người dùng thông thường được gọi từ trong bản thân Framework chứ không phải từ code ứng dụng của người dùng. Framework đóng vai trò của chương trình chính trong việc điều phối và sắp xếp hoạt động ứng dụng. Sự đảo ngược điều khiển này tạo ra cho Framework sức mạnh thông qua việc mở rộng. Chính IoC mang đến sự khác biệt giữa một Framework và một thư viện.

• Thư viện là tập hợp các tính năng mà chúng ta có thể sử dụng, nó được tổ chức thành các class. Sau mỗi lần gọi một phương thức, thư viện sẽ làm một số việc và sau đó trả quyền điều khiển về cho người dùng.
• Framework là một biểu hiện của thiết kế trừu tượng với nhiều hành vi được xây dựng sẵn bên trong, để sử dụng nó chúng ta cần chèn các hành vi của mình vào các nơi khác nhau trong Framework bằng các class hoặc plugin. Code của Framework sẽ gọi đến code của chúng ta tại những điểm cần thiết.

Tự xây dựng 1 framework đảo ngược điều khiển (IoC)

Chúng ta tiếp tục với ví dụ trên bằng cách áp dụng IoC để quản lý việc khởi tạo đối tượng.

Để xây dựng một framework đảo ngược điều khiển, ta dùng kỹ thuật Reflection để khởi tạo đối tượng động. Trước tiên ta cần đọc file cấu hình để lấy ra thông tin về tên lớp hiện thực cần được dùng.

ioc.properties

messageService=com.gpcoder.patterns.creational.dependencyinjection.message.di.EmailService

Tạo file một Injector để đọc thông tin cấu hình và khởi tạo đối tượng cho ứng dụng.

Injector.java

package com.gpcoder.patterns.creational.dependencyinjection.ioc;

import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;

import javax.management.InstanceNotFoundException;

public class Injector {

    private static final String IOC_CONFIGURATION_FILE_NAME = "ioc.properties";

    private Injector() {
        throw new UnsupportedOperationException();
    }

    public static Object getInstance(String key) throws InstanceNotFoundException {
        try (InputStream input = new FileInputStream(IOC_CONFIGURATION_FILE_NAME)) {
            // load a properties file
            Properties prop = new Properties();
            prop.load(input);

            // get the property value
            String className = prop.getProperty(key);
            return Class.forName(className).newInstance();
        } catch (IOException | InstantiationException | IllegalAccessException | ClassNotFoundException e) {
            e.printStackTrace();
            throw new InstanceNotFoundException(
                    "Can't create instance of " + key + " base on the configuration of " + IOC_CONFIGURATION_FILE_NAME);
        }
    }
}

Chương trình của chúng ta được viết lại như sau:

package com.gpcoder.patterns.creational.dependencyinjection.ioc;

import javax.management.InstanceNotFoundException;

import com.gpcoder.patterns.creational.dependencyinjection.di.MessageService;
import com.gpcoder.patterns.creational.dependencyinjection.di.UserController;

public class DependencyInjectionPatternExample {

    public static void main(String[] args) throws InstanceNotFoundException {

        MessageService messageService = (MessageService) Injector.getInstance("messageService");
        UserController userController = new UserController(messageService);
        userController.send();
    }
}

Như bạn thấy, bây giờ chương trình của chúng ta chỉ còn một nơi để khởi tạo và inject đối tượng, khi muốn thay đổi message service chỉ cần thay đổi trong file properties.

So sánh Dependency Injection Pattern với các Pattern khác

So sánh Dependency Injection Pattern với Singleton Pattern

Dependency Injection (DI) có nhiều ưu điểm hơn Singleton, ở một số ý sau:

• Dễ dàng thay thế: Singleton thì lúc nào cũng chỉ có thể truy xuất 1 Object duy nhất, không thay thể bằng cái khác được. Với DI có thể thay thế bằng object khác tại thời điểm run-time.
• Linh hoạt: Singleton thì luôn chỉ có một Object. Với DI có thể dùng riêng từng thể hiện cho mỗi Object hoặc một thể hiện dùng chung cho nhiều Object.
• Kế thừa: Singleton thì không thể thừa kế. Với DI thì không giới hạn.

Một nhược điểm của DI so với Singleton là chi phí khởi tạo lớn hơn, do sử dụng Reflection để truy xuất các property trong object.

Với các hệ thống lớn, phức tạp, có khả năng thay đổi, mở rộng thì nên dùng DI. Với những trường hợp object muốn truy xuất được sử dụng ở khắp mọi nơi trong dự án, ở khắp các tầng trong hệ thống có thể sử dụng Singleton.

So sánh Dependency Injection Pattern với Factory Pattern

Cả hai Dependency Injection (DI) và Factory đều nhằm mục đích cung cấp một cách tiện lợi cho việc tạo một thể hiện của một class. Hai Pattern này đều dựa trên quy tắc “lập trình cho interface chứ không phải để implement interface đó”.

Một vài khác biệt chủ yếu giữa DI và Factory Pattern là:

• DI giúp chúng ta tạo ra ứng dụng ít kết dính, với Factory Pattern mỗi class có một dependency với Factory method.
• Sử dụng Factory Pattern khó khăn khi viết Unit test do phụ thuộc vào các dependency. Ngược lại với DI thì dễ dàng viết Unit do không phụ thuộc vào dependency.

Hạn chế của DI so với Factory Pattenr là cần phải cấu hình và cần một container để inject các dependency.

So sánh Dependency Injection Pattern với Service Locator Pattern

Cả hai Dependency Injection (DI) và Service Locator (SL) đều tuân theo DIP principle. Nó giúp chúng ta tạo ra ứng dụng ít kết dính, dễ hiểu, dễ viết test, dễ mở rộng, bảo trì.

Sự khác biệt giữa DI và SL:

• Sự khác biệt chủ yếu giữa DI và SL là cách cài đặt (implement) để cung cấp một thể hiện cho các lớp của ứng dụng. DI sử dụng một builder object để khởi tạo các đối tượng và cung cấp (inject) các phụ thuộc được yêu cầu cho đối tượng từ lớp bên ngoài. SL sử dụng một locator object để giải quyết (resolve) sự phụ thuộc trong một lớp.
• Khi sử dụng SL, các đối tượng được yêu cầu một cách rõ ràng để nhận một thể hiện của đối tượng và mỗi class có một dependency với SL. Trong khi sử dụng DI không có yêu cầu rõ ràng, dependency injector chỉ được gọi một lần dựa vào config tại thời điểm startup để inject các dependency vào main class.
• SL có thể ẩn các dependency với class client, nhưng client cần phải thấy được Locator. Với DI, client không thấy được class Injector.
• SL cần cung cấp ít nhất một tham số để nhận về thể hiện của một đối tượng do đó gây khó khăn khi viết unit test hơn. Với DI, chúng ta có thể pass một mock object để test.

Hạn chế của DI so với SL là cần phải cấu hình và cần một container để inject các dependency.

SL dễ code, dễ hiểu hơn so với DI. Tuy nhiên, nó thích hợp với các dụng nhỏ. DI thích hợp với các ứng dụng lớn, có nhiều class phụ thuộc.

Lời kết

Dependency Injection và IoC container là những khái niệm rất quan trọng, hầu hết các ứng dụng, framework hiện tại đều sử dụng nó. Chúng ta cần tìm hiểu để biết rõ DI và IoC được ứng dụng trong trường hợp nào. Nếu áp dụng hợp lý code của chúng ta sẽ ít kết dính hơn (loose coupling), dễ bảo trì, dễ test hơn, tổ chức ứng dụng hợp lý và gọn gàng hơn.

Hy vọng bài viết này đã giúp bạn hiểu hơn về Dependency Injection (DI) cũng như những ưu điểm

Bài viết gốc được đăng tải tại huongdanjava.com

Có thể bạn quan tâm:

• Cài đặt transaction in memory cho Java
• Factory Method Pattern – Giải thích đơn giản, dễ hiểu
• Adapter Pattern – Xoá nhoà khác biệt

Xem thêm Việc làm Developer hấp dẫn trên Station D