Luôn phải có chiến lược

Khi làm bất cứ việc gì chúng ta cũng phải có kế hoạch và chiến lược cụ thể thì mới có được thành công và trong lập trình cũng vậy, đối với những nghiệp vụ xử lý phức tạp, chúng ta cũng cần xây dựng thành những chiến lược cụ thể để đảm bảo tính chính xác và khả năng mở rộng về sau này.

Giới thiệu

Strategy có lẽ là thú vị nhất trong tất cả các design pattern. Nó giống như việc chúng ta đang được đặt trong trận chiến và chúng ta là người chỉ huy, chúng ta phải thay đổi chiến thuật đề phù hợp với tình thế đang diễn ra vậy.

Mục tiêu

Với sự phức tạp của những bài toán đòi hỏi sự thay đổi liên tục như vậy, strategy pattern ra đời với các mục tiêu:

  1. Định nghĩa ra một tập hợp các đối tượng đại diện cho các hành động cần thực hiện, các đối tượng này thường là những đối tượng xử lý thuật toán phức tạp
  2. Cho phép thay đổi liên tục các hành động mà không cần tác động đến lớp sử dụng
  3. Cho phép dễ dàng thay đổi và mở rộng các lớp hành động mà không cần phải thay đổi lớp sử dụng

Strategy rất phù hợp cho các dự án phía client side, các dự án game server hay các dự án thương mại điện tử.

Ví dụ

Chúng ta cần phát triển trò chơi điều khiển robot, tất cả robot sẽ đều có thể chuyển động liên tục và mỗi một robot sẽ có 3 chiến thuật:

  1. Tấn công
  2. Phòng ngự
  3. Tiếp tục di chuyển

Chúng ta sẽ có sơ đồ thiết kế lớp như sau:

  1. IBehaviour: là interface chứa hàm chuyển động (moveCommand) sử dụng chung
  2. Robot: là lớp sẽ sử dụng các IBehaviour để thay đổi chiến thuật liên tục
  3. AgressiveBehaviour: là lớp đại diện cho chiến thuật tấn công
  4. DefensiveBehaviour: là lớp đại diện cho chiến thuật phòng ngự
  5. NormalBehaviour: là lớp đại diện cho chiến thuật tiếp tục di chuyển

Mã nguồn của chúng ta sẽ thế này:

interface IBehaviour {
        public void moveCommand();
}

class AgressiveBehaviour implements IBehaviour {

    @Override
    public void moveCommand() {
        System.out.println("\tTấn công: nếu tìm thấy bất cứ mục tiêu nào");
    }

}

class DefensiveBehaviour implements IBehaviour {

    @Override
    public void moveCommand() {
        System.out.println("\tPhòng thủ: Nếu có bất kì mối nguy hiểm nào");
    }
}

class NormalBehaviour implements IBehaviour {

    @Override
    public void moveCommand() {
        System.out.println("\tTiếp tục di chuyển: nếu không có bất kì mối nguy hiểm nào");
    }
}

class Robot {
    private IBehaviour behaviour;
    private String name;

    public Robot(String name) {
        this.name = name;
    }

    public void setBehaviour(IBehaviour behaviour) {
        this.behaviour = behaviour;
    }

    public void move() {
        System.out.println(
                this.name + ": Dựa trên hoàn cảnh hiện tại," + 
                " chiến thuật tiếp theo sẽ là:"
        );

        behaviour.moveCommand();

        System.out.println("\tDành cho robot: '" + this.name + "'");
    }
}

Nào, bây giờ mới đến phần thú vị, chúng ta hãy tạo ra 3 robot: r1, r2, r3 như sau:

Robot r1 = new Robot("Big Robot");
Robot r2 = new Robot("George v.2.1");
Robot r3 = new Robot("R2");

Chiến thuật ban đầu cho 3 robot lần lượt là:

  • r1: Tấn công
  • r2: Phòng ngự
  • r3: Di chuyển bình thường
r1.setBehaviour(new AgressiveBehaviour());
r2.setBehaviour(new DefensiveBehaviour());
r3.setBehaviour(new NormalBehaviour());

Tiếp theo cho cả 3 robot cùng di chuyển:

r1.move();
r2.move();
r3.move();

Lúc này xuất hiện một hoàn cảnh mới:

  • Big Robot đã cảm thấy sợ hãi vì nó yếu hơn và không đủ sức tấn công nữa
  • George v.2.1 cảm thấy phát điên sau khi nạp đủ năng lượng
  • R2 ở một vị trí rất xa nên không vấn đề gì

Dựa trên hoàn cảnh thực tế này chúng ta cần điều chính chiến thuật như sau:

  • r1: Chuyển từ tấn công sang phòng ngự
  • r2: Chuyển từ phòng ngự sang tấn công
  • r3: Di chuyển bình thường
r1.setBehaviour(new DefensiveBehaviour());
r2.setBehaviour(new AgressiveBehaviour());

r1.move();
r2.move();
r3.move();

Output của cả quá trình này như sau:

Big Robot: Dựa trên hoàn cảnh hiện tại, chiến thuật tiếp theo sẽ là:
    Tấn công: nếu tìm thấy bất cứ mục tiêu nào
    Dành cho robot: 'Big Robot'
George v.2.1: Dựa trên hoàn cảnh hiện tại, chiến thuật tiếp theo sẽ là:
    Phòng thủ: Nếu có bất kì mối nguy hiểm nào
    Dành cho robot: 'George v.2.1'
R2: Dựa trên hoàn cảnh hiện tại, chiến thuật tiếp theo sẽ là:
    Tiếp tục di chuyển: nếu không có bất kì mối nguy hiểm nào
    Dành cho robot: 'R2'

Các hành động tiếp theo: 
    'Big Robot' đã cảm thấy sợ hãi vì nó yếu hơn và không đủ sức tấn công nữa
    'George v.2.1' cảm thấy phát điên sau khi nạp đủ năng lượng
    và 'R2' ở một vị trí rất xa nên không vấn đề gì

Big Robot: Dựa trên hoàn cảnh hiện tại, chiến thuật tiếp theo sẽ là:
    Phòng thủ: Nếu có bất kì mối nguy hiểm nào
    Dành cho robot: 'Big Robot'
George v.2.1: Dựa trên hoàn cảnh hiện tại, chiến thuật tiếp theo sẽ là:
    Tấn công: nếu tìm thấy bất cứ mục tiêu nào
    Dành cho robot: 'George v.2.1'
R2: Dựa trên hoàn cảnh hiện tại, chiến thuật tiếp theo sẽ là:
    Tiếp tục di chuyển: nếu không có bất kì mối nguy hiểm nào
    Dành cho robot: 'R2'

Bạn thấy không, chúng ta giống như đang đọc lại một cuốn sách lịch sử kể chi tiết về một trận đánh của một binh đoàn robot vậy, :)

So sánh

Strategy desgin pattern có phần nào đó giống với command design pattern, tuy nhiên sự khác nhau nằm ở chỗ strateger pattern thường đi cùng với lớp sử dụng (ở đây là lớp robot) và có thể thay đổi liên tục, trong khi command pattern thường được gọi trong hàm xử lý hay hàm callback của Observer pattern, nó bị gắn chặt với loại command (command type) và không thay đổi được ở Runtime

Kết luận

Strategy thực sự là một design pattern thú vị, lúc mà dùng nó chính mình cũng cảm thấy một nguồn năng lượng rất mạnh vậy, nên code rất là thích. Nó rất phù hợp với các dự án game client/server, nếu bạn đang là một game developer, hãy xem xét việc sử dụng nó nhé.

Tham khảo:

  1. Lý thuyết
  2. Code ví dụ