Showing posts with label Design Pattern. Show all posts
Showing posts with label Design Pattern. Show all posts

Monday, September 24, 2007

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());
}
}


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

Trong phần này ta sẽ tìm hiểu về các mẫu thiết kế trong nhóm mẫu kiến tạo (Creational Pattern)


1.Mẫu kiến tạo(Creational Pattern)

Những mẫu này hỗ trợ cho một trong những nhiệm vụ của lập trình hướng đối tượng – khởi tạo đối tượng trong hệ thống. Hầu hết các hệ thống hướng đối tượng phức tạp yêu cầu nhiều đối tượng được thể hiện theo thời gian, và các mẫu này hỗ trợ cho việc tạo các tiến trình bằng việc cung cấp các khả năng:
- Sự thể hiện chung – Điều này cho phép các đối tượng được tạo ra trong hệ thống không cần phải định nghĩa một đặc tả kiểu lớp trong mã nguồn
- Đơn giản – Một vài mẫu làm cho việc khởi tạo đối tượng trở nên dễ dàng, vì vậy lớp “gọi” khởi tạo đối tượng không phải viết mã nhiều cũng như phức tạp



1.1.Abstract Factory Method Pattern

- Ý nghĩa
Đóng gói một nhóm những lớp đóng vai trò “sản xuất” (Factory) trong ứng dụng, đây là những lớp được dùng để tạo lập các đối tượng. Các lớp sản xuất này có chung một giao diện lập trình được kế thừa từ một lớp cha thuần ảo gọi là “lớp sản xuất ảo”

- Cấu trúc mẫu




Trong đó:
o AbstractFactory: là lớp trừu tượng, tạo ra các đối tượng thuộc 2 lớp trừu tượng là: AbstractProductA và AbstractProductB
o ConcreteFactoryX: là lớp kế thừa từ AbstractFatory, lớp này sẽ tạo ra một đối tượng cụ thể
o AbstractProduct: là các lớp trừu tượng, các đối tượng cụ thể sẽ là các thể hiện của các lớp dẫn xuất từ lớp này.

- Tình huống áp dụng
o Phía trình khách sẽ không phụ thuộc vào việc những sản phẩm được tạo ra như thế nào.
o Ứng dụng sẽ được cấu hình với một hoặc nhiều họ sản phẩm.
o Các đối tượng cần phải được tạo ra như một tập hợp để có thể tương thích với nhau.
o Chúng ta muốn cung cấp một tập các lớp và chúng ta muốn thể hiện các ràng buộc, các mối quan hệ giữa chúng mà không phải là các thực thi của chúng(interface).


- Ví dụ
Giả sử ta cần viết một ứng dụng quản lý địa chỉ và số điện thoại cho các quốc gia trên thế giới. Điạ chỉ và số địa thoại của mỗi quốc gia sẽ có 1 số điểm giống nhau và 1 số điểm khác nhau. Ta xây dựng sơ đồ lớp như sau:




Ta sẽ xây dựng các phương thức tạo Address, và PhoneNumber cụ thể trong các lớp USAAddressPhoneFactory, FrechAddressPhoneFactory.
Với phương thực createProductAddress() của lớp USAAddressPhoneFactory sẽ trả về đối tượng của lớp USAAddress
Với phương thực createProductAddress() của lớp FrechAddressPhoneFactory sẽ trả về đối tượng của lớp FrechAddress
Tương tự với PhoneNumber.

AddressFactory.java

public interface AddressFactory {
public Address createAddress();
public PhoneNumber createPhoneNumber();
}

Address.java

public abstract class Address {
private String street;
private String city;
private String region;
private String postalCode;

public static final String EOL_STRING =
System.getProperty("line.separator");
public static final String SPACE = " ";

public String getStreet() {
return street;
}
public String getCity() {
return city;
}
public String getPostalCode() {
return postalCode;
}
public String getRegion() {
return region;
}
public abstract String getCountry();
public String getFullAddress() {
return street + EOL_STRING + city + SPACE + postalCode + EOL_STRING;
}
public void setStreet(String newStreet) {
street = newStreet;
}
public void setCity(String newCity) {
city = newCity;
}
public void setRegion(String newRegion) {
region = newRegion;
}
public void setPostalCode(String newPostalCode) {
postalCode = newPostalCode;
}
}

USAddressFactory.java

public class USAddressFactory implements AddressFactory{
public Address createAddress(){
return new USAddress();
}
public PhoneNumber createPhoneNumber(){
return new USPhoneNumber();
}
}

USAddress.java

public class USAddress extends Address{
private static final String COUNTRY = "UNITED STATES";
private static final String COMMA = ",";
public String getCountry(){
return COUNTRY;
}
public String getFullAddress(){
return getStreet() + EOL_STRING + getCity() + COMMA + SPACE + getRegion() + SPACE + getPostalCode() + EOL_STRING + COUNTRY + EOL_STRING;
}
}

Tương tự cho lớp PhoneNumber và USAPhoneNumber



1.2.Builder Pattern

- Ý nghĩa
Phân tách những khởi tạo các thành phần của một đối tượng phức hợp, để có thể cùng một khởi tạo mà có thể tạo nên nhiều định dạng khác nhau.

- Cấu trúc mẫu




Trong đó:
o Director: là lớp điều khiển tạo ra một đối tượng Product
o Builder: là lớp trừu tượng cho phép tạo ra đối tượng Product từ các phương thức nhỏ khởi tạo từng thành phần của Product
o ConcreteBuilder: là lớp dẫn xuất của Builder, khởi tạo từng đối tượng cụ thể, lớp này sẽ khởi tạo đối tượng.

- Tình huống áp dụng

o Có cấu trúc bên trong phức tạp (đặc biệt là một biến là một tập các đối tượng liên quan với nhau)
o Có các thuộc tính phụ thuộc vào các thuộc tính khác
o Sử dụng các đối tượng khác trong hệ thống mà có thể khó khởi tạo hoặc khởi tạo phức tạp

- Ví dụ
Ta lại xét đối tượng Address, có các thành phần sau: Street, City và Region. Ta phân tách việc khởi tạo 1 đối tượng Address thành các phần : buildStreet, buildCity và buildRegion.




Trong đó:
o AddressDirector: là lớp tạo ra đối tượng Address
o AddressBuilder: là lớp trừu tượng cho phép tạo ra 1 đối tượng Address bằng các phương thức khởi tạo từng thành phần của Address
o USAddressBuilder: là lớp tạo ra các Address. USAddressBuilder sẽ tạo ra địa chỉ theo chuẩn của USA


Address.java

class Address(){
private String street;
private String city;
private String region;
/**
* @return the city
*/
public String getCity() {
return city;
}
/**
* @param city the city to set
*/
public void setCity(String city) {
this.city = city;
}
/**
* @return the region
*/
public String getRegion() {
return region;
}
/**
* @param region the region to set
*/
public void setRegion(String region) {
this.region = region;
}
/**
* @return the street
*/
public String getStreet() {
return street;
}
/**
* @param street the street to set
*/
public void setStreet(String street) {
this.street = street;
}
}
AddressBuilder.java

abstract class AddressBuilder{
abstract public void buildStreet(String street){}
abstract public void buildCity(String city){}
abstract public void buildRegion(String region){}
}

USAddressBuilder.java

class USAddressBuilder extends AddressBuilder {
private Address add;
public void buildStreet(String street){
add.setStreet(street);
}
public void buildCity(String city){
add.setCity(city);
}
public void buildRegion(String region){
add.setRegion(region);
}
public Address getAddress(){
return add;
}
}

AddressDirector.java

class AddressDirector{
public void Contruct(AddressBuilder builder, String street, String city, String region){
builder.buildStreet(street);
builder.buildCity(city);
builder.buildRegion(region);
}
}

Client.java

class Client{
AddressDirector director = new AddressDirector();
USAddressBuilder b = new USAddressBuilder();
director.Contruct(b. “Street 01”, “City 01”, “Region 01”);
Address add = b.getAddress();
}




1.3.Factory Method
- Ý nghĩa
Định nghĩa một phương thức chuẩn để khởi tạo đối tượng, như là một phần của phương thức tạo, nhưng việc quyết định kiểu đối tượng nào được tạo ra thì phụ thuộc vào các lớp con

- Cấu trúc mẫu


Trong đó:
o Creator là lớp trừu tượng, khai báo phương thức factoryMethod() nhưng không cài đặt
o Product cũng là lớp trừu tượng
o ConcreteCreatorAConcreteCreatorB là 2 lớp kế thừa từ lớp Creator để tạo ra các đối tượng riêng biệt
o ConcreteProductAConcreteProductB là các lớp kế thừa của lớp Product, các đối tượng của 2 lớp này sẽ do 2 lớp ConcreteCreatorA và ConcreteCreatorB tạo ra


- Tình huống áp dụng
o Khi bạn muốn tạo ra một framework có thể mở rộng, có nghĩa là nó cho phép tính mềm dẻo trong một số quyết định như chỉ ra loại đối tượng nào được tạo ra
o Khi bạn muốn 1 lớp con, mở rộng từ 1 lớp cha, quyết định lại đối tượng được khởi tạo
o Khi bạn biết khi nào thì khởi tạo một đối tượng nhưng không biết loại đối tượng nào được khởi tạo
o Bạn cần một vài khai báo chồng phương thức tạo với danh sách các tham số như nhau, điều mà Java không cho phép. Thay vì điều đó ta sử dụng các Factory Method với các tên khác nhau

- Ví dụ
Ta xét lại ví dụ về các địa chỉ ở phần Abstract Pattern



1.4.Prototype
- Ý nghĩa
Giúp khởi tạo đối tượng bằng cách copy một đối tượng khác đã tồn tại (đối tượng này là “prototype” – nguyên mẫu).

- Cấu trúc mẫu


Trong đó:
o Prototype là lớp trừu tượng cài đặt phương thức myClone() là phương thức copy bản thân đối tượng đã tồn tại.
o ConcretePrototype1ConcretePrototype2 là các lớp kế thừa lớp Prototype.

- Tình huống áp dụng
o Khi bạn muốn khởi tạo một đối tượng bằng cách sao chép từ một đối tượng đã tồn tại

- Ví dụ



1.5.Singleton
- Ý nghĩa
Mẫu này được thiết kế để đảm bảo cho một lớp chỉ có thể tạo ra duy nhất một thể hiện của nó

- Cấu trúc mẫu


Trong đó:
o Singleton cung cấp một phương thức tạo private, duy trì một thuộc tính tĩnh để tham chiếu đến một thể hiện của lớp Singleton này, và nó cung cấp thêm một phương thức tĩnh trả về thuộc tính tĩnh này

- Tình huống áp dụng
o Khi bạn muốn lớp chỉ có 1 thể hiện duy nhất và nó có hiệu lực ở mọi nơi

- Ví dụ


public class Singleton {

private String _strName;

private static Singleton instance;

private Singleton(String name){
_strName = name;
}

public static Singleton getInstance(String name){
if (instance == null)
instance = new Singleton(name);
return instance;
}

public void printName(){
System.out.println(this._strName);
}
}


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

1.Vai trò của thiết kế

Thiết kế là 1 công đoạn quan trọng trong qui trình phát triển phần mềm.
Thiết kế là bước chuyển tiếp của giai đoạn phân tích và là bước chuẩn bị trước khi chúng ta tiến hành xây dựng phần mềm.
Thiết kế là tiến trình mà ở đó xuất hiện mô hình các kiểu mẫu của phần mềm. Các mô hình này chính là những nét phác thảo nên phần mềm. Nó cho chúng ta biết phần mềm chúng ta đang xây dựng là gì, đã có, đang có và sẽ có những gì.
Thiết kế là nơi mà ta có thể trả lời câu hỏi “Liệu phần mềm này có thể chạy được không?” , “Phần mềm có thể đáp ứng được các yêu cầu của khách hàng hay không?” mà không cần đợi đến công đoạn phát triển.

2.Các nguyên lý thiết kế hướng đối tượng

- Nguyên lý 'đóng mở': một moudle cần “mở” đối với việc phát triển thêm tính năng nhưng phải “đóng” đối với việc sửa đổi mã nguồn
- Nguyên lý thay thế Liskov: Các chức năng của hệ thống vẫn thực hiện đúng đắn nếu ta htay bất kì một lớp đối tượng nào bằng đối tượng kế thừa.
- Nguyên lý nghịch đảo phụ thuộc: phụ thuộc vào mức trừu tượng, không phụ thuộc vào mức chi tiết.
- Nguyên lý phân tách giao diện: nên có nhiều giao diện đặc thù với bên ngoài hơn là chỉ có một giao diện dùng chung cho một mục đích.


3.Các mẫu thiết kế (Design Pattern)

Khái niệm:
Mẫu thiết kế (Design Pattern) là vấn đề thông dụng cần giải quyết và là cách giải quyết vấn đề đó trong một ngữ cảnh cụ thể, Mẫu thiết kế tuân thủ nghiêm ngặt các nguyên lý thiết kế hướng đối tượng ở trên.
Mẫu thiết kế không đơn thuần là một bước nào đó trong các giai đoạn phát triển phần mềm mà nó đóng vai trò là sáng kiến để giải quyết một vấn đề thông dụng nào đó. Mẫu thiết kế sẽ giúp cho việc giải quyết vấn đề nhanh, gọn và hợp lý hơn.
Mẫu thiết kế còn được sử dụng nhằm cô lập các thay đổi trong mã nguồn, từ đó làm cho hệ thống có khả năng tái sử dụng cao.
Chúng ta sẽ tìm hiểu một số mẫu thiết kế kinh điển (GOF- Gang of Four:confused:)


Creational Patterns

  • Abstract Factory
  • Builder
  • Factory Method
  • Prototype
  • Singleton


Behavioral Patterns
  • Chain of Responsibility
  • Command
  • Interpreter
  • Iterator
  • Mediator
  • Memento
  • State
  • Strategy
  • Visitor
  • Template Method


Structural Patterns
  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Facade
  • Flyweight
  • Proxy


System Patterns
  • Model-View-Controller (MVC)
  • Session
  • Worker Thread
  • Callback
  • Successive Update
  • Transaction
Cấu trúc trình bày:
- Ý nghĩa của mẫu
- Mô hình cấu trúc mẫu và mô tả
- Trường hợp áp dụng
- Ví dụ