Phân tích nội dung, những nguyên lý sáng tạo có trong các mẫu thiết kế hướng đối tượng thông dụng

Phân tích nội dung, những nguyên lý sáng tạo có trong các mẫu thiết kế hướng đối tượng thông dụng

Tp.Hồ Chí Minh, tháng 12 năm 2012

Mục lục

Mục lục 1

Lời mở đầu: 2

A Tổng quan về Design pattern 3

I Lịch sử design pattern 3

II Design pattern là gì ? 4

B Hệ thống các mẫu design pattern 5

I Hệ thống các mẫu 5

1 Nhóm Creational 5

2 Nhóm Structural 5

3 Nhóm Behavioral 5

4 Các mẫu thiết kế thông dụng, có tần suất sử dụng cao: 6

Các mẫu để tạo mới - Creational patterns 6

Các mẫu cấu trúc - Structural patterns 6

Các mẫu ứng xử - Behavioral patterns 6

II Phân tích nội dung và tính sáng tạo trong các mẫu Design pattern 6

 Nhóm Creational 6

1 Abstract factory: 6

2. Builder: 8

3. Factory Method: 9

4. Prototype: 13

5. Singleton: 14

 Nhóm Structural 16

6. Adapter: 16

7. Composite: 17

8. Proxy: 19

 Nhóm Behavioral 21

9. Command: 21

10. Observer: 23

11. Strategy: 24

Lời mở đầu:

Một dân tộc không sáng tạo sẽ trở nên hủ bại - GS Tom Cannon

Câu chuyện ngủ quên và tự hài lòng của người Anh suốt 70 năm sau Thế chiến II

trong khi một phần khác của thế giới đang không ngừng sáng tạo và sáng tạo lại để giành

những vị thế hàng đầu trong nền kinh tế toàn cầu mà GS Tom Cannon đã từng chia sẻ tại

buổi bàn tròn trực tuyến “Tương lai Việt Nam – con đường của sự sáng tạo” rất đáng để

chúng ta suy ngẫm

Mỗi một con người, mỗi một dân tộc, thậm chí mỗi một cỗ máy nếu không có sự sáng

tạo liên tục và kế tiếp sẽ rơi vào tình trạng bất động Trong tình trạng bất động ấy, chúng

ta có thể nói một cách văn chương hay một cách thực tế rằng nó đồng nghĩa với cái chết

Sáng tạo, đó là nguồn lực cơ bản với tiềm năng bất tận của con người, là cốt lõi của sự

phát triển, là tất yếu cho sự cải tạo thế giới, giúp sự tiến bộ của khoa học kỹ thuật

Với những kiến thức, câu chuyện được thầy Hoàng Kiếm truyền thụ trong thời gian

học, em lại càng hiểu và thấy rõ sự kỳ diệu của sáng tạo, trở nên yêu thích và muốn áp

dụng những phương pháp sáng tạo vào thực tiễn Chân thành cám ơn thầy Hoàng Kiếm,

thầy đã dạy rất nhiệt tình, chân thành, tạo cho học viên tâm lý thoải mái khi học, tiếp thu

những kiến thức quý báu

Trong ngành công nghệ thông tin ngày nay, môi trường tin học là môi trường sự sáng

tạo được nảy sinh, phát triển rất đa dạng phong phú Trong chủ đề này em xin phân tích

nội dung, sự xuất hiện của 40 nguyên tắc sáng tạo trong các mẫu thiết kế thông dụng

thường được áp dụng trong công nghệ phần mềm

A Tổng quan về Design pattern

I Lịch sử design pattern

Ý tưởng dùng mẫu xuất phát từ ngành kiến trúc, Alexander, Ishikawa, Silverstein,

Jacobson, Fiksdahl-King và Angel (1977) lần đầu tiên đưa ra ý tưởng dùng các mẫu

chuẩn trong thiết kế xây dựng và truyền thông Họ đã xác định và lập sưu liệu các mẫu có

liên quan để có thể dùng để giải quyết các vấn đề thường xảy ra trong thiết kế các cao ốc

Mỗi mẫu này là một cách thiết kế, chúng đã được phát triển hàng trăm năm như là các

giải pháp cho các vấn đề mà người ta làm trong lĩnh vực xây dựng thường gặp Các giải

pháp tốt nhất có được ngày hôm nay là qua một quá trình sàng lọc tự nhiên Mặc dù

nghành công nghệ phần mềm không có lịch sử phát triển lâu dài như nghành kiến trúc,

xây dựng nhưng Công nghệ phần mềm là một ngành công nghiệp tiên tiến, tiếp thu tất cả

những gì tốt đẹp nhất từ các ngành khác Mẫu được xem là giải pháp tốt để giải quyết

vấn đề xây dựng hệ thống phần mềm Suốt những năm đầu 1990, thiết kế mẫu được thảo

luận ở các hội thảo workshop, sau đó người ta nổ lực để đưa ra danh sách các mẫu và lập

sưu liệu về chúng Những người tham gia bị dồn vào việc cần thiết phải cung cấp một số

kiểu cấu trúc ở một mức quan niệm cao hơn đối tượng và lớp để cấu trúc này có thể được

dùng để tổ chức các lớp Đây là kết quả của sự nhận thức đựơc rằng việc dùng các kỹ

thuật hướng đối tượng độc lập sẽ không mang lại những cải tiến đáng kể đối với chất

lượng cũng như hiệu quả của công việc phát triển phần mềm Mẫu được xem là cách tổ

chức việc phát triển hướng đối tượng, cách đóng gói các kinh nghiệm của những ngưòi đi

trước và rất hiệu quả trong thực hành

Năm 1994 tại hội nghị PLoP( Pattern Language of Programming Design) đã được tổ

chức Cũng trong năm này quyển sách Design patterns: Elements of Reusable Object

Oriented Software (Gamma, Johnson,Helm và Vhissdes,1995) đã được xuất bản đúng

vào thời điểm diễn ra hội nghị OOPSLA’94 Đây là một tài liệu còn phôi thai trong việc

làm nỗi bật ảnh hưởng của mẫu đối với việc phát triển phần mềm, sự đóng góp của nó là

xây dựng các mẫu thành các danh mục (catalogue) với định dạng chuẩn được dùng làm

được gọi là các mẫu Gang of Four Còn rất nhiều các cuốn sách khác xuất hiện trong 2

năm sau, và các định dạng chuẩn khác được đưa ra

Năm 2000 Evitts có tổng kết về cách các mẫu xâm nhập vào thế giới phần mềm (sách của

ông lúc bấy giờ chỉ nói về những mẫu có thể được sử dụng trong UML chứ chưa đưa ra

khái niệm những mẫu thiết kế một cách tổng quát) Ông công nhận Kent Beck và Ward

Cunningham là những người phát triển những mẫu đầu tiên với SmallTalk trong công

việc của họ được báo cáo tại hội nghị OOPSLA’87 Có 5 mẫu mà Kent Beck và Ward

Cunningham đã tìm ra trong việc kết hợp các người dùng của một hệ thống mà họ đang

thiết kế Năm mẫu này đều được áp dụng để thiết kế giao diện người dùng trong môi

trường Windows

II Design pattern là gì ?

Design patterns là tập các giải pháp cho cho vấn đề phổ biến trong thiết kế các hệ

thống máy tính Đây là tập các giải pháp đã được công nhận là tài liệu có giá trị, những

người phát triển có thể áp dụng giải pháp này để giải quyết các vấn đề tương tự Giống

như với các yêu cầu của thiết kế và phân tích hướng đối tượng (nhằm đạt được khả năng

sử dụng các thành phần và thư viện lớp), việc sử dụng các mẫu cũng cần phải đạt được

khả năng tái sử dụng các giải pháp chuẩn đối với vấn đề thường xuyên xảy ra

Christopher Alexander nói rằng: ”Mỗi một mẫu mô tả một vấn đề xảy ra lặp đi lặp lại

trong môi trường và mô tả cái cốt lõi của giải pháp để cho vấn đề đó Bằng cách nào đó

bạn đã dùng nó cả triệu lần mà không làm giống nhau 2 lần”

Design pattern không phải là một phần của UML cốt lõi,nhưng nó lại đựơc sử dụng

rộng rãi trong thiết kế hệ thống hướng đối tượng và UML cung cấp các cơ chế biểu diễn

mẫu dưới dạng đồ hoạ

B Hệ thống các mẫu design pattern

I Hệ thống các mẫu

Hệ thống các mẫu design pattern hiện có 23 mẫu được định nghĩa trong cuốn “Design

patterns Elements of Reusable Object Oriented Software” Hệ thống các mẫu này có thể

nói là đủ và tối ưu cho việc giải quyết hết các vấn đề của bài toán phân tích thiết kế và

xây dựng phần mềm trong thời điểm hiện tại.Hệ thống các mẫu design pattern được chia

thành 3 nhóm: Creational, nhóm Structural,nhóm behavioral

1 Nhóm Creational

Gồm có 5 pattern: AbstractFactory, Abstract Method, Builder, Prototype, và

Singleton Nhóm này liên quan tới việc tạo ra các thể nghiệm (instance) của đối tượng,

tách biệt với cách được thực hiện từ ứng dụng Muốn xem xét thông tin của các mẫu

trong nhóm này thì phải dựa vào biểu đồ nào phụ thuộc vào chính mẫu đó, mẫu thiên về

hành vi hay cấu trúc

2 Nhóm Structural

Gồm có 7 mẫu: Adapter, Bridge, Composite, Decorator, Facade, Proxy, và Flyweight

Nhóm này liên quan tới các quan hệ cấu trúc giữa các thể nghiệm, dùng kế thừa,kết tập,

tương tác Để xem thông tin về mẫu này phải dựa vào biểu đồ lớp của mẫu

3 Nhóm Behavioral

Gồm có 11 mẫu : Interpreter, Template Method, Chain of Responsibility, Command,

Iterator, Mediator, Memento, Observer, State, Strategy và Visitor.Nhóm này liên quan đến các quan hệ gán trách nhiệm để cung cấp các chức năng giữa các đối tượng trong hệ

thống Đối với các mẫu thuộc nhóm này ta có thể dựa vào biểu đồ cộng tác và biểu đồ

diễn tiến Biểu đồ cộng tác và biểu đồ diễn tiến sẽ giải thích cho ta cách chuyển giao của

các chức năng

4 Các mẫu thiết kế thông dụng, có tần suất sử dụng cao:

Trong tiểu luận này em xin trình bày nội dung, phân tích tính sáng tạo trong 12 mẫu

thiết kế thông dụng nhất, được sử dụng nhiều nhất trong công nghệ phần mềm sau:

Các mẫu để tạo mới - Creational patterns

 Abstract factory pattern

Chúng ta có thể để ý thấy trong các hệ điều hành giao diện đồ hoạ, một bộ công cụ

muốn cung cấp một giao diện người dùng dựa trên chuẩn look-and-feel, chẳng hạn như

chương trình trình diễn tài liệu power point Có rất nhiều kiểu giao diện look-and-feel và

cả những hành vi giao diện người dùng khác nhau được thể hiện ở đây như thanh cuộn tài

liệu (scroll bar), cửa sổ (window), nút bấm (button), hộp soạn thảo (editbox), Nếu xem

chúng là các đối tượng thì chúng ta thấy chúng có một số đặc điểm và hành vi khá

giống nhau về mặt hình thức nhưng lại khác nhau về cách thực hiện Chẳng hạn đối

tượng button và window, editbox có cùng các thuộc tính là chiều rộng, chiều cao,toạ độ,… Có các phương thức là Resize(), SetPosition(), Tuy nhiên các đối tượng này

không thể gộp chung vào một lớp được vì theo nguyên lý xây dựng lớp thì các đối tượng

thuộc lớp phải có các phương thức hoạt động giống nhau Trong khi ở đây tuy rằng các

đối tượng có cùng giao diện nhưng cách thực hiện các hành vi tương ứng lại hoàn toàn

khác nhau

Vấn đề đặt ra là phải xây dựng một lớp tổng quát, có thể chứa hết được những điểm

chung của các đối tượng này để từ đó có thể dễ dàng sử dụng lại, ta gọi lớp này là

WidgetFactory.Các lớp của các đối tượng window, button,editbox kế thừa từ lớp

này.Trong thiết kế hướng đối tượng, xây dựng một mô hình các lớp như thế được tối ưu

hoá như sau:

lớp WidgetFactory chính là 1 AbstractFactory

b) Định nghĩa:

Mẫu AbstractFactory là một mẫu thiết kế mà cung cấp cho trình khách một giao diện

cho một họ hoặc một tập các đối tượng thuộc các lớp khác nhau nhưng có cùng chung

giao diện với nhau mà không phải trực tiếp làm việc với từng lớp con cụ thể

c) Nguyên lý sáng tạo trong mẫu:

Ta thấy rõ nét mẫu AbstractFactory hoạt động dựa trên nguyên lý sáng tạo nguyên lý

kết hợp, lớp Abstract Factory đã kết hợp các đối tượng tương tự lại với nhau, dẫn đến một

sự nhất thống, dễ quản lý, và tính hình tượng rất cao

2 Builder:

a) Vấn đề đặt ra:

Trong những ứng dụng lớn, với nhiều các chức năng phức tạp và mô hình giao diện

đồ sộ.Việc khởi tạo ứng dụng thường gặp nhiều khó khăn Chúng ta không thể dồn tất cả

công việc khởi tạo này cho một hàm khởi tạo Vì như thế sẽ rất khó kiểm soát hết, và hơn

nữa không phải lúc nào các thành phần của ứng dụng cũng được khởi tạo một cách đồng

bộ Có thành phần được tạo ra vào lúc dịch chương trình nhưng cũng có thành phần tuỳ

theo từng yêu cầu của người dùng, tuỳ vào hoàn cảnh của ứng dụng, mà nó sẽ được tạo

ra Do vậy người ta giao công việc này cho một đối tượng chịu trách nhiêm khởi tạo, và

chia việc khởi tạo ứng dụng riêng rẽ, để có thể tiến hành khởi tạo riêng biệt ở các hoàn

cảnh khác nhau Hãy tưởng tượng việc tạo ra đối tượng của ta giống như như việc chúng

ta tạo ra chiếc xe đạp Đầu tiên ta tạo ra khung xe, sau đó tạo ra bánh xe, chúng ta tạo ra

buđông xe, xích, líp, Việc tạo ra các bộ phận này không nhất thiết phải đựơc thực hiện

một cách đồng thời hay theo một trật tự nào cả, và nó có thể được tạo ra một cách độc lập

bởi nhiều người Nhưng trong một mô hình sản xuất như vậy, bao giờ việc tạo ra chiếc xe

cũng được khép kín để tạo ra chiếc xe hoàn chỉnh, đó là nhà máy sản xuất xe đạp.Ta gọi

đối tượng nhà máy sản xuất xe đạp này là builder ( người xây dựng)

b) Định nghĩa:

Builder là mẫu thiết kế hướng đối tượng được tạo ra để chia một công việc khởi tạo

phức tạp của một đối tượng ra riêng rẽ từ đó có thể tiến hành khởi tạo đối tượng ở các

hoàn cảnh khác nhau

c) Sơ đồ UML:

Builder (VehicleBuilder): chỉ ra một giao diện trừu tượng cho việc tạo ra các phần của

một đối tượng Product

ConcreteBuilder (MotorCycleBuilder, CarBuilder, ScooterBuilder): xây dựng và lắp

ráp các phần của dẫn xuất bằng việc cài đặt bổ sung giao diện Builder Định nghĩa và giữ

liên kết đến đại diện mà nó tạo ra Cung cấp một giao diện cho việc gọi dẫn xuất ra

Director (Shop): xây dựng một đối tượng sử dụng giao diện Builder

Product (Vehicle): biểu diễn các đối tượng phức tạp.ConcreteBuilder dựng nên các đại diện bên trong của dẫn xuất và định nghĩa quá trình xử lý bằng các thành phần lắp ráp

của nó Gộp các lớp mà định nghĩa các bộ phận cấu thành, bao gồm các giao diện cho

việc lắp ráp các bộ phận trong kết quả cuối cùng

d) Nguyên lý sáng tạo trong mẫu:

Nguyên lý phân nhỏ đã được áp dụng trong mẫu Builder, công việc phức tạp khi khởi

tạo một đối tượng được chia ra riêng rẽ để dễ quản lý, điều khiển theo ý người lập trình

3 Factory Method:

a) Vấn đề đặt ra:

Các Framework thường sử dụng các lớp trừu tượng để định nghĩa và duy trì mối quan

hệ giữa các đối tượng Một framework thường đảm nhiệm việc tạo ra các đối tượng hoàn

chỉnh Việc xây dựng một framework cho ứng dụng mà có thể đại diện cho nhiều đối

tượng tài liệu cho người dùng Có 2 loại lớp trừu tượng chủ chốt trong framework này là

lớp ứng dụng và tài liệu Cả 2 lớp đều là lớp trừu tượng, và trình khách phải xây dựng các

dẫn xuất, các lớp con để hiện thực hoá, tạo ra đối tượng phù hợp với yêu cầu của ứng

dụng Chẳng hạn để tạo ra một ứng dụng drawing, chúng ta định nghĩa một lớp

DrawingApplication và một lớp DrawingDocument Lớp ứng dụng chịu trách nhiệm

quản lý tài liệu và chúng ta sẽ tạo ra chúng khi có nhu cầu ( chẳng hạn khi người dùng

chọn Open hoặc New từ menu) Bởi vì một lớp Document cá biệt như thế này được tạo ra

từ các dẫn xuất của lớp Abstract Document (trong framework) để đưa ra các thể nghiệm

cho một ứng dụng Drawing, lớp ứng dụng không thể biết trước được lớp dẫn xuất của

Abstract Document nào sẽ được tạo ra để trình bày, mà nó chỉ biết khi nào một đối tượng

tài liệu nào nên được tạo chứ không biết loại đối tượng tài liệu nào để tạo Điều này tạo ra

một sự tiến thoái lưỡng nan: framework phải thể nghiệm một lớp, nhưng nó chỉ biết về

lớp trừu tượng của nó, mà lớp trừu tượng này lại không thể thể nghiệm trực tiếp

được.Nếu ai từng làm việc với giao diện ứng dụng đơn tài liệu và đa tài liệu trong ngôn

ngữ Visual C++, chúng ta cũng sẽ bắt gặp một vấn đề tương tự Đối tượng MainFrame có

thể tạo ra một dối tượng view mỗi khi người dùng nhấn chuột vào menu View hay Open,

nhưng MainFrame hoàn toàn không hề biết một chút thông tin nào trước đó về View vì

nó không chứa bất cứ một thể nghiệm nào của View

Tóm lại Factory method gói gọn lại việc tạo đối tượng Điều này hữu dụng nếu quá

trình tạo phức tạp Ví dụ như nó phụ thuộc vào những điều chỉnh trong tập tin cấu hình

hay phụ thuộc vào thông tin của người dùng nhập vào

Ví dụ: một chương trình đọc tập tin ảnh và tạo ảnh thumbnail của nó Chương trình hỗ

trợ nhiều định dạng ảnh khác nhau, và mỗi định dạng ảnh sẽ có một lớp hỗ trợ việc đọc

Mỗi khi chương trình đọc một ảnh, nó cần phải tạo một đối tượng phù hợp để đọc ảnh

đó dựa vào những thông tin trong tập tin Việc này có thể gói gọn trong factory method:

public class ImageReaderFactory

b) Định nghĩa:

Factory Method là một giao diện cho việc tạo ra một đối tượng, nhưng để cho lớp

dẫn xuất quyết định lớp nào sẽ được tạo.Factory method để cho một lớp trì hoãn sự thể

nghiệm một lớp con

c) Sơ đồ UML:

Product (Page): định nghĩa giao diện của các đối tượng mà Factory Method tạo ra

ConcreteProduct (SkillsPage, EducationPage, ExperiencePage): cài đặt giao diện

Product

Creator (Document): khai báo Factory Method mà trả về một đối tượng của kiểu

Product Sự kiến tạo này cũng có thể định nghĩa một cài đặt mặc định của Factory

Method trả về một đối tượng ConcreteProduct mặc định Có thể gọi Factory Method để

tạo ra một đối tượng Product

ConcreteCreator (Report, Resume): chồng lên Factory Method để trả về một thể

nghiệm của một ConcreteProduct

d) Nguyên lý sáng tạo trong mẫu:

Nguyên lý năng động được thấy trong mẫu Factory method, Phân chia đối tượng

thành từng phần, có khả năng dịch chuyển với nhau, chọn lựa phương thức cần thiết dựa

vào thông tin đầu vào

4 Prototype:

a) Vấn đề đặt ra:

Ta hãy xem xét trường hợp phát triển game, chúng ta có một nhà lính, người chơi có

thể mua lính từ nhà lính này, trong nhà lính có ba loại lính đó là lính kiếm, lính cung, lính

ngựa, mỗi khi người dùng nhấp mua một loại lính trong ba loại này, một đối tượng lính

mới sẽ được tạo mới với các thuộc tính, phương thức đặc thù Vấn đề xảy ra khi lập trình

tới trường hợp người dùng chọn mua một loại lính mới chung ta sẽ làm thế nào? Tạo một

đối tượng lính và gán các thuộc tính đặc trưng của loại lính đã được chọn? Làm như vậy

sẽ rất tốn thời gian và dễ gây nhầm lẫn trong công việc gán Mẫu prototype phát huy tác

dụng trong trường hợp này, ta sẽ tạo mảng prototype chứa ba loại lính, gán tất cả các tính

chất, phương thức thích hợp cho mỗi loại lính, viết hàm clone(nhân bản) cho mỗi loại

lính và khi cần tạo một loại lính mới ta chỉ việc gọi hàm clone với đầu vào là loại lính

nào

b) Định nghĩa:

Prototype là mẫu thiết kế chỉ định ra một đối tượng đặc biệt để khởi tạo, nó sử dụng

một thể nghiệm sơ khai rồi sau đó sao chép ra các đối tượng khác từ mẫu đối tượng

này

c) Sơ đồ UML: