Các mẫu thiết kế hướng đối tượng (P.4)

Structural Pattern

Các mẫu Structural diễn tả một cách có hiệu quả cả việc phân chia hoặc kết hợp các phần tử trong một ứng dụng. Những cách mà các mẫu Structural áp dụng vào ứng dụng rất rộng: ví dụ, mẫu Adapter có thể làm cho hai hệ thống không tương thích có thể giao tiếp với nhau, trong khi mẫu Façade cho phép bạn làm đơn giản hóa một giao tiếp để sử dụng mà không cần gỡ bỏ tất cả các tùy biến đã có trong hệ thống

3.1. Adapter Pattern

- Ý nghĩa
Tạo một giao diện trung gian để gắn kết vào hệ thống một lớp đối tượng mong muốn nào đó.

- Cấu trúc mẫu

Trong đó:
o Tagret là một interface định nghĩa chức năng, yêu cầu mà Client cần sử dụng
o Adaptee là lớp chức các chức năng mà Target cần sử dụng để tạo ra được chức năng mà Target cần cung cấp cho Client
o Adapter thực thi từ Target và sử dụng đối tượng lớp Adaptee, Apdater có nhiệm vụ gắn kết Adaptee vào Target để có được chức năng mà Client mong muốn

- Trường hợp ứng dụng
o Muốn sử dụng 1 lớp có sẵn nhưng giao tiếp của nó không tương thích với yêu cầu hiện tại
o Muốn tạo 1 lớp có thể sử dụng lại mà lớp này có thể làm việc được với những lớp khác không liên hệ gì với nó, và là những lớp không cần thiết tương thích trong giao diện.


- Ví dụ mẫu
- Xét ví dụ: ta có một hệ thống PhoneTarget cần thực hiện một chức năng gì đó, trong đó có một phương thức trả về số điện thoại trong một chuỗi đầu vào
- Trước đó ta đã có một lớp có một chức năng là lấy các kí tự số trong một chuỗi
- Giờ ta muốn sử dụng chức năng lấy kí tự số vào hệ thống lấy số điện thoại

public interface PhoneTarget{

public String getPhoneNumber(String message);//lấy số điện thoại trong 1 chuỗi 

}

public GetNumberAdaptee{

public String getNumber(String str){

//lấy ra dạng số trong 1 chuỗi

<…get number>

}

…

}

public Adapter implements PhoneTarget{

public String getPhoneNumber(String message){

GetNumberAdaptee obj = new GetNumberAdaptee;

String str = obj.getNumber(message);

return “84”+str;

}

}

3.2. Bridge Pattern
- Ý nghĩa
Một thành phần trong OOP thường có 2 phần: phần ảo – định nghĩa các chức năng và phần thực thi – thực thi các chức năng được định nghĩa trong phần ảo. Hai phần này liên hệ với nhau qua quan hệ kế thừa. Những thay đổi trong phần ảo dẫn đến các thay đổi trong phần thực thi.
Mẫu Bridge được sử dụng để tách thành phần ảo và thành phần thực thi riêng biệt, do đó các thành phần này có thể thay đổi độc lập và linh động. Thay vì liên hệ với nhau bằng quan hệ kế thừa hai thành phần này liên hệ với nhau thông qua quan hệ “chứa trong”.

- Cấu trúc mẫu

Trong đó:
o Abstraction: là lớp trừu tượng khai báo các chức năng và cấu trúc cơ bản, trong lớp này có 1 thuộc tính là 1 thể hiện của giao tiếp Implementation, thể hiện này bằng các phương thức của mình sẽ thực hiện các chức năng abstractionOp() của lớp Abstraction
o Implementation: là giao tiếp thực thi của lớp các chức năng nào đó của Abstraction
o RefineAbstraction: là định nghĩa các chức năng mới hoặc các chức năng đã có trong Absrtaction.
o ConcreteImplement: là các lớp định nghĩa tường minh các thực thi trong lớp giao tiếp Implementation

- Trường hợp ứng dụng
o Khi bạn muốn tạo ra sự mềm dẻo giữa 2 thành phần ảo và thực thi của một thành phần, và tránh đi mối quan hệ tĩnh giữa chúng
o Khi bạn muốn những thay đổi của phần thực thi sẽ không ảnh hưởng đến client
o Bạn định nghĩa nhiều thành phần ảo và thực thi.
o Phân lớp con một cách thích hợp, nhưng bạn muốn quản lý 2 thành phần của hệ thống một các riêng biệt

- Ví dụ mẫu

class  MyAbstraction{

private MyImplementation myImp;

public void method01(){

myImp.doMethod1();

}

public String method2(){

myImp.doMethod2();

}

}

interface class MyImplementation{

public void doMethod1();

public String doMethod2();

}

class RefineAbstraction1 extends MyAbstraction{

//các định nghĩa riêng, tường minh

}

class ConcreteImpleA extend MyImplement{

//các định nghĩa riêng, tường minh

}

class RefineAbstraction2 extends MyAbstraction{

//các định nghĩa riêng, tường minh

}

class ConcreteImpleB extend MyImplement{

//các định nghĩa riêng, tường minh

}

3.3. Composite Pattern
- Ý nghĩa
Mẫu này nhằm gom các đối tượng vào trong một cấu trúc cây để thể hiện được cấu trúc tổng quát của nó. Trong khi đó cho phép mỗi phần tử của cấu trúc cây có thể thực hiện một chức năng theo một giao tiếp chung
- Mô hình mẫu

Trong đó:

o Component: là một giao tiếp định nghĩa các phương thức cho tất cả các phần của cấu trúc cây. Component có thể được thực thi như một lớp trừu tượng khi bạn cần cung cấp các hành vi cho tất cả các kiểu con. Bình thường, các Component không có các thể hiện, các lớp con hoặc các lớp thực thi của nó, gọi là các nốt, có thể có thể hiện và được sử dụng để tạo nên cấu trúc cây
o Composite: là lớp được định nghĩa bởi các thành phần mà nó chứa. Composite chứa một nhóm động các Component, vì vậy nó có các phương thức để thêm vào hoặc loại bổ các thể hiện của Component trong tập các Component của nó. Những phương thức được định nghĩa trong Component được thực thi để thực hiện các hành vi đặc tả cho lớp Composite và để gọi lại phương thức đó trong các nốt của nó. Lớp Composite được gọi là lớp nhánh hay lớp chứa
o Leaf: là lớp thực thi từ giao tiếp Component. Sự khác nhau giữa lớp Leaf và Composite là lớp Leaf không chứa các tham chiếu đến các Component khác, lớp Leaf đại diện cho mức thấp nhất của cấu trúc cây
- Trường hợp ứng dụng
o Khi có một mô hình thành phần với cấu trúc nhánh - lá, toàn bộ - bộ phận, ...
o Khi cấu trúc có thể có vài mức phức tạp và động
o Bạn muốn thăm cấu trúc thành phần theo một cách qui chuẩn, sử dụng các thao tác chung thông qua mối quan hệ kế thừa
- Ví dụ mẫu
Trở lại ví dụ về dự án, một Project(Composite) có nhiều tác vụ Task(Leaf), ta cần tính tổng thời gian của dự án thông qua thời gian của tất cả các tác vụ

public interface TaskItem{

public double getTime();

}

public class Project implements TaskItem{

private String name;

private ArrayList subtask = new ArrayList();

public Project(){ }

public Project(String newName){

name = newName;

}    

public String getName(){ return name; }

public ArrayList getSubtasks(){ return subtask; }

public double getTime(){

double totalTime = 0;

Iterator items = subtask.iterator();

while(items.hasNext()){

TaskItem item = (TaskItem)items.next();

totalTime += item.getTime();

}

return totalTime;

}

public void setName(String newName){ name = newName; }

public void addTaskItem(TaskItem element){

if (!subtask.contains(element)){

subtask.add(element);

}

}

public void removeTaskItem(TaskItem element){

subtask.remove(element);

}

}

public class Task implements TaskItem{

private String name;

private double time;

public Task(){ }

public Task(String newName, double newTimeRequired){

name = newName;

time = newTimeRequired;

}

public String getName(){ return name; }

public double getTime(){

return time;

}

public void setName(String newName){ name = newName; }

public void setTime(double newTimeRequired){ time = newTimeRequired; }

}

3.4. Decorator Pattern
- Ý nghĩa
Bổ sung trách nhiệm cho đối tượng tại thời điểm thực thi. Đây được xem là sự thay thế hiệu quả cho phương pháp kế thừa trong việc bổ sung trách nhiệm cho đối tượng và mức tác động là ở mức đối tượng thay vì ở mức lớp như phương pháp kế thừa.

- Mô hình mẫu

Trong đó:
o Component: là một interface chứa các phương thức ảo (ở đây là defaultMethod)
o ConcreteComponent: là một lớp kế thừa từ Component, cài đặt các phương thức cụ thể (defaultMethod được cài đặt tường minh)
o Decorator: là một lớp ảo kế thừa từ Component đồng thời cũng chứa 1 thể hiện của Component, phương thức defaultMethod trong Decorator sẽ được thực hiện thông qua thể hiện này.
o ConcreteDecoratorX: là các lớp kế thừa từ Decorator, khai báo tường minh các phương thức, đặc biệt trong các lớp này khai báo tường minh các “trách nhiệm” cần thêm vào khi run-time

- Trường hợp ứng dụng
o Khi bạn muốn thay đổi động mà không ảnh hưởng đến người dùng, không phụ thuộc vào giới hạn các lớp con
o Khi bạn muốn thành phần có thể thêm vào hoặc rút bỏ đi khi hệ thống đang chạy
o Có một số đặc tính phụ thuộc mà bạn muốn ứng dụng một cách động và bạn muốn kết hợp chúng vào trong một thành phần

- Ví dụ
Gỉa sử trong thư viện có các tài liệu: sách, video... Các loại tài liệu này có các thuộc tính khác nhau, phương thức hiển thị của giao tiếp LibraryItem sẽ hiển thị các thông tin này. Giả sử , ngoài các thông tin thuộc tính trên, đôi khi ta muốn hiển thị độc giả mượn một cuốn sách (chức năng hiển thị độc giả này không phải lúc nào cũng muốn hiển thị), hoặc muốn xem đoạn video(không thường xuyên).

Giao tiếp LibraryItem định nghĩa phương thức display() cho tất cả các tài liệu của thư viện

public interface LibraryItem{

public void display();   // đây là defaultMethod

}

Các lớp tài liệu

public class Book implements LibraryItem{

private String title;

private int page;

public Book(String s, int p){

title = s;

page = p;

}

public void display(){

System.out.println("Title: " + title);

System.out.println("Page number: " + page);

}

}

public class Video implements LibraryItem{

private String title;

private int minutes;

public Video(String s, int m){

title = s;

minutes = m;

}

public void display(){

System.out.println("Title: " + title);

System.out.println("Time: " + minutes);

}

}

Lớp ảo Decorator thư viện

public abstract class LibDecorator implements LibraryItem{

private LibraryItem libraryitem;

public LibDecorator(LibraryItem li){

libraryitem = li;

}

public void display(){

libraryitem.display();

}

}

Các lớp Decorator cho mỗi tài liệu thư viện cần bổ sung trách nhiệm ở thời điểm run-time

public class BookDecorator extends LibDecorator{

private String borrower;

public BookDecorator(LibraryItem li, String b){

super(li);

borrower = b;

}

public void display(){

super.display();

System.out.println("Borrower: " + borrower);

}

}

public class VideoDecorator extends LibDecorator{

public VideoDecorator(LibraryItem li){

super(li);

}

public void display(){

super.display();

play(); //phương thức play video

}

}

3.5. Facade Pattern
- Ý nghĩa
Cung cấp một giao tiếp hợp nhất của một tập các giao tiếp trong hệ thống con. Façade định nghĩa một giao tiếp mức cao hơn để làm cho hệ thống con dễ sử dụng

- Mô hình mẫu

Trong đó
o Class1 và Class2 là các lớp đã có trong hệ thống
o Façade là lớp sử dụng các phương thức của Class1 và Class2 để tạo ra một giao diện mới, thường được sử dụng, đỡ phức tạp hơn khi sử dụng riêng Class1 và Class2

- Trường hợp ứng dụng
o Làm cho một hệ thống phức tạp dễ sử dụng hơn bằng cách cung cấp một giao tiếp đơn gian mà không cần loại bỏ các lựa chọn phức tạp
o Giảm bớt sự ràng buộc giữa client và các hệ thống con
- Ví dụ mẫu
Giả sử hệ thống cũ đã có các lớp: Địa chỉ, Số điện thoại, Tên tuổi về thông tin của một người, giờ ta muốn quản lý các thông tin trên của một người, ta tận dụng lại hệ thống cũ, xây một lớp Người sử dụng lại các lớp ở trên.

3.6. Flyweight Pattern
- Ý nghĩa
Làm phương tiện dùng chung để quản lý một cách hiệu quả một số lượng lớn các đối tượng nhỏ có các đặc điểm chung, mà các đối tượng nhỏ này lại được sử dụng tuỳ thuộc vào hoàn cảnh, điều kiện ngoài.

- Mô hình mẫu

Trong đó:
o FlyweightFactory: tạo ra và quản lý các đối tượng Flyweight
o Flyweight là một giao tiếp định nghĩa các phương thức chuẩn
o ConcreteFlyweightX: là các lớp thực thi của Flyweight, các thể hiện của các lớp này sẽ được sử dụng tuỳ thuộc vào điều kiện ngoài.

- Trường hợp sử dụng
o Ứng dụng sử dụng nhiều đối tượng giống hoặc gần giống nhau
o Với các đối tượng gần giống nhau, những phần không giống nhau có thể tách rời với các phần giống nhau để cho phép các phần giống nhau có thể chia sẻ
o Nhóm các đối tượng gần giống nhau có thể được thay thế bởi một đối tượng chia sẻ mà các phần không giống nhau đã được loại bỏ
o Nếu ứng dụng cần phân biệt các đối tương gần giống nhau trong trạng thái gốc của chúng

- Ví dụ mẫu
Một ví dụ cổ điển của mẫu flyweight là các kí tự được lưu trong một bộ xử lí văn bản (word processor). Mỗi kí tự đại diện cho một đối tượng mà có dữ liệu là loại font (font face), kích thước font, và các dữ liệu định dạng khác. Bạn có thể tưởng tượng là, với một tài liệu (document) lớn với cấu trúc dữ liệu như thế này thì sẽ bộ xử lí văn bản sẽ khó mà có thể xử lí được. Hơn nữa, vì hầu hết dữ liệu dạng này là lặp lại, phải có một cách để giảm việc lưu giữ này - đó chính là mẫu Flyweight. Mỗi đối tượng kí tự sẽ chứa một tham chiếu đến một đối tượng định dạng riêng rẽ mà chính đối tượng này sẽ chứa các thuộc tính cần thiết. Điều này sẽ giảm một lượng lớn sự lưu giữ bằng cách kết hợp mọi kí tự có định dạng giống nhau trở thành các đối tượng đơn chỉ chứa tham chiếu đến cùng một đối tượng đơn chứa định dạng chung đó.

Giao tiếp Character định nghĩa phương thức vẽ một kí tự

public interface Character {

public void draw();

}

Lớp kí tự thực thi từ giao tiếp Character
Sở dĩ ta định nghĩa Character và ConcreteCharacter riêng là vì trong cấu trúc sẽ có một phần nữa: phần không giống nhau giữa các đối tượng Character (mà ta không bàn tới)

public class ConcreteCharacter implements Character{

private String symbol;

private String font;

public ConcreteCharacter(String s, String f){

this.symbol = s;

this.font = f;

}

public void draw() {

System.out.println("Symbol " + this.symbol + " with font " + this.font );

}

}

Lớp khởi tạo các kí tự theo symbol và font, mỗi lần khởi tạo nó sẽ lưu các đối tượng này vào vùng nhớ riêng của nó, nếu đối tượng ký tự symbol + font đã có thì nó sẽ lấy ra chứ không khởi tạo lại

import java.util.*;

public class CharacterFactory {

private Hashtable pool = new Hashtable();

public int getNum() {

return pool.size();

}

public Character get(String symbol, String fontFace) {

Character c;

String key = symbol + fontFace;

if ((c = (Character)pool.get(key)) != null) {

return c;

} else {

c = new ConcreteCharacter(symbol, fontFace);

pool.put(key, c);

return c;

}

}

}

Lớp Test

import java.util.*;

public class Test {

public static void main(String[] agrs) {

CharacterFactory characterfactory = new CharacterFactory();

ArrayList text = new ArrayList();

text.add(0, characterfactory.get("a", "arial"));

text.add(1, characterfactory.get("b", "time"));

text.add(2, characterfactory.get("a", "arial"));

text.add(0, characterfactory.get("c", "arial"));

for (int i = 0; i <>
Character c = (Character)text.get(i);
c.draw();
}
}
}

Như vậy 'a' + 'arial' gọi 2 lần như chỉ khởi tạo có 1 lần mà thôi

3.7. Proxy Pattern
- Ý nghĩa
Đại diện một đối tượng phức tạp bằng một đối tượng đơn giản, vì các mục đích truy xuất, tốc độ và bảo mật

- Mô hình mẫu

Trong đó:
o Service: là giao tiếp định nghĩa các phương thức chuẩn cho một dịch vụ nào đó
o RealService: là một thực thi của giao tiếp Service, lớp này sẽ khai báo tường minh các phương thức của Service, lớp này xem như thực hiện tốt tất cả các yêu cầu từ Service
o Proxy: kế thừa Service và sử dụng đối tượng của RealService

- Trường hợp ứng dụng
o Sử dụng mẫu Proxy khi bạn cần một tham chiếu phức tạp đến một đối tượng thay vì chỉ một cách bình thường
o Remote proxy – sử dụng khi bạn cần một tham chiếu định vị cho một đối tượng trong không gian địa chỉ(JVM)
o Virtual proxy – lưu giữ các thông tin thêm vào về một dịch vụ thực vì vậy chúng có thể hoãn lại sự truy xuất vào dịch vụ này
o Protection proxy – xác thực quyền truy xuất vào một đối tượng thực

- Ví dụ mẫu
Ví dụ lớp Image là một interface định nghĩa các phương thức xử lý ảnh, nó có các lớp con là GIFImage và JPGImage.
Theo hướng đối tượng thì thiết kế như thế có vẻ hợp lý, Client chỉ cần sử dụng lớp Image là đủ, còn tuỳ thuộc vào loại ảnh sẽ có các phương thức khác nhau
Nhưng trong trường hợp, trên ứng dụng web chẳng hạn, một lúc ta đọc lên hàng trăm ảnh các loại và ta còn muốn xử lý tuỳ vào một điều kiện nào đó (ví dụ chỉ xử lý khi là ảnh JPG hoặc GIF). Nếu ta đặt điều kiện IF Image (sau đó sẽ tùy điều kiện này rồi xử lý riêng) thì không hợp lý, nếu đặt trong Client, nếu mỗi lần cần thay đổi IF ta lại sửa Client => không hợp lý khi Client là một ứng dụng lớn.

Ta sử dụng Proxy, lớp ImageProxy chỉ là lớp đại diện cho Image, kế thừa từ Image và sử dụng các lớp GIFImage hay JPGImage. Khi cần thay đổi ta chỉ cần thay đổi trên Proxy mà không cần tác động đến Client và Image.

public interface Image {

public void process();

}

public class JPGImage implements Image {

public void process() {

System.out.print("JPG Image");

}

}

public class GIFImage implements Image {

public void process() {

System.out.print("GIF Image");

}

}

public class ImageProxy implements Image {

private Image image;

public void process() {

if (image == null)

image = new JPGImage();//tạo đối tượng ảnh JPG, chỉ mang tính minh họa

image.process();

}

}

Ở đây ta sẽ xử lý khi Image là ảnh JPG trong trường hợp muốn thay đổi ta sẽ thay đổi ở ImageProxy và client sẽ không bị ảnh hưởng
* Đây là ví dụ cho trường hợp Virtual Proxy

Các mẫu thiết kế hướng đối tượng (P.3)

BEHAVIORAL PATTERNS



Mẫu Behavioral có liên quan đến luồng điều khiển của hệ thống. Một vài cách của tổ chức điều khiển bên trong một hệ thống để có thể nâng mang lại các lợi ích cả về hiệu suất lẫn khả năng bảo trì hệ thống đó

2.1.Chain of Responsibility

- Ý nghĩa
Mẫu này thiết lập một chuỗi bên trong một hệ thống, nơi mà các thông điệp hoặc có thể được thực hiện ở tại một mức nơi mà nó được nhận lần đầu hoặc là được chuyển đến một đối tượng mà có thể thực hiện điều đó
- Mô hình mẫu

Trong đó:
o Handler: là một giao tiếp định nghĩa phương thức sử dụng để chuyển thông điệp qua các lần thực hiện tiếp theo.
o ConcreteHandler: là một thực thi của giao tiếp Handler. Nó giữ một tham chiếu đến một Handler tiếp theo. Việc thực thi phương thức handleMessage có thể xác định làm thế nào để thực hiện phương thức và gọi một handlerMethod, chuyển tiếp thông điệp đến cho Handler tiếp theo hoặc kết hợp cả hai

- Trường hợp ứng dụng
o Có một nhóm các đối tượng trong một hệ thống có thể đáp ứng tất cả các loại thông điệp giống nhau
o Các thông điệp phải được thực hiện bởi một vài các đối tượng trong hệ thống
o Các thông điệp đi theo mô hình “thực hiện – chuyển tiếp”, một vài sự kiện có thể được thực hiện tại mức mà chúng được nhận hoặc tại ra, trong khi số khác phải được chuyển tiếp đến một vìa đối tượng khác

- Ví dụ mãu

Hệ thống quản lý thông tin các nhân có thể được sử dụng để quản lý các dự án như là các liên hệ.
Ta hình dung một cấu trúc cây như sau; đỉnh là một dự án, các đỉnh con là các tác vụ của dự án đó, và cứ như vậy, mỗi đỉnh con tác vụ lại có một tập các đỉnh con tác vụ khác.

Để quản lý cấu trúc này ta thực hiện như sau:
-Ở mỗi đỉnh ta lưu các thông tin như sau: tên tác vụ, đỉnh cha, tập các đỉnh con
-Ta xét thông điệp sau: duyệt từ đỉnh gốc (project cở sở) in ra các thông tin
-Như vậy với thông điệp này, việc in thông tin ở một đỉnh là chưa đủ, ta phải chuyển tiếp đến in thông tin các đỉnh con của đỉnh gốc và chuyển tiếp cho đến khi không còn đỉnh con thì mới dừng

Giao tiếp TaskItem định nghĩa các phương thức cho project cơ sở và các tác vụ

public interface TaskItem{
public TaskItem getParent();
public String getDetails();
public ArrayList getProjectItems();
}

Lớp Project thực thi giao tiếp TaskItem, nó là lớp đại diện cho các đỉnh gốc trên cùng của cây

public class Project implements TaskItem {
private String name;
private String details;
private ArrayList subtask = new ArrayList();

public Project(){ }
public Project(String newName, String newDetails){
name = newName;
details = newDetails;
}

public String getName(){
return name;
}
public String getDetails(){
return details;
}
public ProjectItem getParent(){
return null;
//vì project là ở mức cơ sở, đỉnh gốc trên cùng nên không có cha
}
public ArrayList getSubTask(){
return subtask;
}

public void setName(String newName){
name = newName;
}
public void setDetails(String newDetails){
details = newDetails;
}

public void addTask(TaskItem element){
if (!subtask.contains(element)){
subtask.add(element);
}
}

public void removeProjectItem(TaskItem element){
subtask.remove(element);
}
} 

Lớp Task thực thi giao tiếp TaskItem, nó đại diện cho các tác vụ, các đỉnh không phải ở gốc của cây

public class Task implements TaskItem {
private String name;
private ArrayList subtask = new ArrayList();
private String details;
private TaskItem parent;

public Task(TaskItem newParent){
this(newParent, "", "");
}
public Task(TaskItem newParent, String newName, String newDetails,){
parent = newParent;
name = newName;
details = newDetails;
}

public String getDetails(){
if (primaryTask){
return details;
}
else{
return parent.getDetails() + EOL_STRING + "\t" + details;
}
}

public String getName(){
return name;
}
public ArrayList getSubTask(){ return subtask; }
public ProjectItem getParent(){
return parent;
}

public void setName(String newName){
name = newName;
}
public void setParent(TaskItem newParent){
parent = newParent;
}
public void setDetails(String newDetails){
details = newDetails;
}

public void addSubTask(TaskItem element){
if (!subtask.contains(element)){
subtask.add(element);
}
}

public void removeSubTask(TaskItem element){
subtask.remove(element);
}
}

Lớp thực thi test mẫu

public class RunPattern{
public static void main(String [] arguments){
Project project = new Project(“Project 01”, “Detail of Project 01”);
//Khởi tạo, thiết lập các tác vụ con …
detailInfor(project);
}

private static void detailInfor (TaskItem item){
System.out.println("TaskItem: " + item);
System.out.println("  Details: " + item.getDetails());
System.out.println();
if (item.getSubTask() != null){
Iterator subElements = item.getSubTask().iterator();
while (subElements.hasNext()){
detailInfor ((TaskItem)subElements.next());
}
}
}
} 

Gọi thông điệp detailInfor(item) và thông điệp này được chuyển tiếp nhiều lần qua nhiều đối tượng thực thi

2.2.Command Pattern
- Ý nghĩa
Gói một mệnh lệnh vào trong một đối tượng mà nó có thể được lưu trữ, chuyển vào các phương thức và trả về một vài đối tượng khác

- Cấu trúc mẫu

Trong đó:
o Command: là một giao tiếp định nghĩa các phương thức cho Invoker sử dụng
o Invoker: lớp này thực hiện các phương thức của đối tượng Command
o Receiver: là đích đến của Command và là đối tượng thực hiện hoàn tất yêu cầu, nó có tất cả các thông tin cần thiết để thực hiện điều này
o ConcreteCommand: là một thực thi của giao tiếp Command. Nó lưu giữa một tham chiếu Receiver mong muốn

Luồng thực thi của mẫu Command như sau:

o Client gửi yêu cầu đến GUI của ứng dụng
o Ứng dụng khởi tạo một đối tượng Command thích hợp cho yêu cầu đó (đối tượng này sẽ là các ConcreteCommand)
o Sau đó ứng dụng gọi phương thức executeCommand() với tham số là đối tượng Command vừa khởi tạo
o Invoker khi được gọi thông qua phương thức executeCommand() sẽ thực hiện gọi phương thức execute() của đối tượng Command tham số
o Đối tượng Command này sẽ gọi tiếp phương thức doAction() của thành phần Receiver của nó, được khởi tạo từ đầu, doAction() chính là phương thức chính để hoàn tất yêu cầu của Client

- Trường hợp áp dụng
o Hỗ trợ undo, logging hoặc transaction
o Thực hiện hàng đợi lệnh và thực hiện lệnh tại các thời điểm khác nhau
o Hạn chế sự chặt chẽ của yêu cầu với đối tượng thực hiện hoàn tất yêu cầu đó

- Ví dụ mẫu

public interface Command{
public void execute();
}

public class ConcreteCommand implements Command{
private Receiver receiver;
public void setReceiver(Receiver receiver){
this.receiver = receiver;
}
public Receiver getReceiver(){
return this.receiver;
}

public void execute (){
receiver.doAction();
}
}

public class Receiver{
private String name;
public Receiver(String name){
this.name = namel
}
public void doAction(){
System.out.print(this.name + “ fulfill request!”);
}
}

public class Invoker{
public void executeCommand(Command command){
command.execute();
}
}

public class Run{
public static void main(String[] agrs){
Command command = new ConcreteCommand();
command.setReceiver(new Receiver(“NguyenD”));
Invoker invoker = new Invoker();
Invoker.executeCommand(command);
}
}

2.3.Interpreter Pattern
- Ý nghĩa
o Ý tưởng chính của Interpreter là triển khai ngôn ngữ máy tính đặc tả để giải quyết nhanh một lớp vấn đề được định nghĩa. Ngôn ngữ đặc tả thường làm cho vấn đề được giải quyết nhanh hơn ngôn ngữ thông thường từ một cho đến vài trăm lần
o Ý tưởng tương tự như vậy biểu diễn các biểu thức tính toán theo cú pháp Ba Lan

- Mô hình mẫu

Trong đó:
o Expression: là một giao tiếp mà thông qua nó, client tương tác với các biểu thức
o TerminalExpression: là một thực thi của giao tiếp Expression, đại diện cho các nốt cuối trong cây cú pháp
o NonterminalExpression: là một thực thi khác của giao tiếp Expression, đại diện cho các nút chưa kết thúc trong cấu trúc của cây cú pháp. Nó lưu trữ một tham chiếu đến Expression và triệu gọi phương thức diễn giải cho mỗi phần tử con
o Context: chứa thông tin cần thiết cho một vài vị trí trong khi diễn giải. Nó có thể phục vụ như một kênh truyền thông cho các thể hiện của Expression
o Client: hoặc là xây dựng hoặc là nhận một thể hiện của cây cú pháp ảo. Cây cú pháp này bao gồm các thể hiện của TerminalExpression và NoterminalExpression để tạo nên câu đặc tả. Client triệu gọi các phương thức diễn giải với ngữ cảnh thích hợp khi cần thiết

- Trường hợp ứng dụng
o Có một ngôn ngữ đơn giản để diễn giải vấn đề
o Các vấn đề lặp lại có thể được diễn giải nhanh bằng ngôn ngữ đó

- Ví dụ mẫu
Xét biểu thức 5 + 3 x 3 + 6, với bài tóan này ta có thể chia thành các bài các bài tóan nhỏ hơn
-Tính 3 x 3 = a
-Sau đó tính 5 + a = b
-Sau đó tính b + 6
Ta biểu diễn bài tóan thành cấu trúc cây và duyệt cây theo Ba Lan (hay Ba Lan đảo gì đó không còn nhớ nữa)

Mã nguồn cho ví dụ này như sau

import java.util.Stack;
public class Context extends Stack {
}

public interface Expression {
public void interpret(Context context);
}

public class TerminalExpressionNumber implements Expression {
private int number;

public TerminalExpressionNumber(int number){
this.number = number;
}
public void interpret(Context context) {
context.push(this.number);
}
}

public class TerminalExpressionPlus implements Expression {

public void interpret(Context context) {
//Cong 2 phan tu phia tren dinh Stack
context.push(context.pop() + context.pop());
}
}

public class TerminalExpressionMutil implements Expression{
public void interpret(Context context) {
//Nhan 2 phan tu phia tren dinh Stack
context.push(context.pop() * context.pop());
}
}

import java.util.ArrayList;
public class NonterminalExpression implements Expression {

private ArrayList expressions;//tham chieu den mang Exoression con

public ArrayList getExpressions() {
return expressions;
}

public void setExpressions(ArrayList expressions) {
this.expressions = expressions;
}

public void interpret(Context context) {
if (expressions != null){
int size = expressions.size();
for (Expression e : expressions){
e.interpret(context);
}
}
}
}

import java.util.*;
public class Client {
public static void main(String[] agrs){
Context context = new Context();

// 3 3 *
ArrayList treeLevel1 = new ArrayList ();
treeLevel1.add(new TerminalExpressionNumber(3));
treeLevel1.add(new TerminalExpressionNumber(3));
treeLevel1.add(new TerminalExpressionMutil());

// 5 (3 3 *) +
ArrayList treeLevel2 = new ArrayList ();
treeLevel2.add(new TerminalExpressionNumber(5));
Expression nonexpLevel1 = new NonterminalExpression();
((NonterminalExpression)nonexpLevel1).setExpressions(treeLevel1);
treeLevel2.add(nonexpLevel1);
treeLevel2.add(new TerminalExpressionPlus());

// (5 (3 3 *) +) 6 +
ArrayList treeLevel3 = new ArrayList ();
Expression nonexpLevel2 = new NonterminalExpression();
((NonterminalExpression)nonexpLevel2).setExpressions(treeLevel2);
treeLevel3.add(nonexpLevel2);
treeLevel3.add(new TerminalExpressionNumber(6));
treeLevel3.add(new TerminalExpressionPlus());

for(Expression e : treeLevel3){
e.interpret(context);
}

if (context != null)
System.out.print("Ket qua: " + context.pop());
}
}