Tìm hiểu mô hình AOP

tìm hiểu mô hình AOP

1 Giới thiệu 5

1.1 Mục đích và cấu trúc của tài liệu 5

1.2 Các thuật ngữ 5

1.3 Hạn chế của các phương pháp lập trình hiện tại 6

2 Các đặc điểm của AOP 7

2.1 Quản lý các concern hệ thống 8

2.2 Phương pháp luận của AOP 11

2.2.1 Ưu điểm của AOP 12

2.2.2 Những nhược điểm 12

2.3 Một số công cụ hỗ trợ làm việc với AOP 12

3 Giới thiệu AspectJ 13

3.1 Giới thiệu 13

3.2 Một số khái niệm 13

3.2.1 Join point 13

3.2.2 Pointcut 14

3.2.3 Advice 15

3.2.4 Introduction 16

3.2.5 Aspect 16

3.2.6 Static crosscutting 18

3.3 Một số ứng dựng cơ bản của AOP 19

4 Giải quyết bài toán với AOP 19

4.1 Sử dụng AOP trong bước thiết kế 20

4.2 Sử dụng AOP trong bước thi công 20

4.3 Sử dụng AOP trong bước kiếm tra 21

4.4 Sử dụng AOP trong giai đoạn bảo trì 21

5 Triển khai một số pattern trên AspectJ 22

5.1 Các mẫu thiết kế cho việc tạo đối tượng 22

5.1.1 Singleton pattern 22

5.1.2 Prototype pattern 25

5.1.3 Abstract Factory pattern 27

5.1.4 Factory Method pattern 29

5.1.5 Builder pattern 30

5.2 Các mẫu thiết kế cho cấu trúc của đối tượng 31

5.2.1 Composite pattern 31

5.2.2 Flyweight pattern 35

5.2.3 Bridge Pattern 36

5.2.4 Decorator pattern 37

5.2.5 Adapter pattern 39

5.2.6 Proxy Pattern 39

5.3 Các mẫu thiết kế cho hành vi của đối tượng 42

5.3.1 Observer pattern 42

5.3.2 Command Pattern 45

5.3.3 Iterator pattern 49

5.3.4 Mediator pattern 50

5.3.5 Chain of Responsibility Pattern 52

5.3.6 Memento Pattern 56

5.3.7 Visitor Pattern 58

5.3.8 Strategy pattern 60

5.3.9 State Pattern 62

6 Kết luận 64

7 Tài liệu tham khảo 65

Mục lục hình ảnh

Hình 1: Mô hình các concern mức hệ thống 8

Hình 2: Mô hình ánh xạ yêu cầu người dùng sử dụng AOP 9

Hình 3: Mô hình đa chiều về sự phụ thuộc giữa các module với nhau 9

Hình 4: Mô hình ánh xạ từ các concern hệ thống sang các phương pháp lập trình truyền thống 10

Hình 5: Các module yêu cầu logging đều phải nhúng các đoạn mã để gọi logging API 10

Hình 6: Giải quyết các concern hệ thống bằng phương pháp AOP 11

Hình 7: Các giai đoạn phát triển sử dụng phương pháp AOP 12

Hình 8: Cấu trúc của aspect trừu tượng với interface và các hàm được định nghĩa để hỗ trợ Singleton pattern 23

Hình 9:Một ứng dụng trước và sau khi được tác động bởi Singleton pattern 24

Hình 10: Các bước thực hiện của mẫu thiết kế Singleton trong ứng dụng 24

Hình 11: Cấu trúc của PrototypePattern aspect 25

Hình 12:Một ứng dụng trước và sau khi được tác động bởi Prototype pattern 26

Hình 13: Sử dụng Prototype pattern trong ứng dụng 27

Hình 14: Lược đồ UML của AbstractFactory Pattern 28

Hình 15: Lược đồ UML của factory method pattern 29

Hình 16: Cấu trúc của CompositePattern aspect 32

Hình 17: Mô hình các đối tượng trước khi áp dụng Composite pattern 34

Hình 18: Mô hình các đối tượng sau khi áp dụng Composite pattern 34

Hình 19: Hoạt động của composite pattern trong ứng dụng 34

Hình 20: Cấu trúc của FlyweightPattern aspect 35

Hình 21:Cấu trúc của XWindowBridge aspect 37

Hình 22: Sử dụng các hành vi của lớp Window trong ứng dụng 37

Hình 23: Cấu trúc của DecoratorPattern aspect 38

Hình 24:Lớp TextDisplay trước và sau khi áp dụng DecoratorPattern 38

Hình 25: Áp dụng Adapter pattern 39

Hình 26: Cấu trúc của ProxyPattern aspect 39

Hình 27: Cấu trúc của ObserverPattern aspect 42

Hình 28: Cấu trúc lớp trước khi áp dụng ObserverPattern 44

Hình 29:Cấu trúc lớp sau khi áp dụng ObserverPattern 44

Hình 30:Sử dụng ObserverPattern trong ứng dụng 45

Hình 31: Cấu trúc của CommandPattern và các hàm hỗ trợ pattern 45

Hình 32: Trước khi áp dụng CommandPattern 47

Hình 33:Trước khi áp dụng CommandPattern 48

Hình 34: Sử dụng CommandPattern trong ứng dụng 49

Hình 35: IteratorPatternAspect và interface định nghĩa vài trò của pattern 49

Hình 36: Mô tả sự tương tác của EmployeeIteration với ứng dụng 50

Hình 37: Cấu trúc của MediatorPattern aspect 51

Hình 38: Trước và sau khi áp dụng Mediator pattern 52

Hình 39: Cấu trúc của ChainOfResponsibilityPattern aspect 52

Hình 40: Sau khi áp dụng ChainOfResponsibilityPattern 54

Hình 41:Sử dụng ChainOfResponsibilityPattern trong ứng dụng 56

Hình 42: Cấu trúc của MementoPattern aspect 57

Hình 43: Sử dụng MementoPattern trong ứng dụng 57

Hình 44: Cấu trúc của Visitor pattern aspect 58

Hình 45: Cấu trúc của Computeur 59

Hình 46: Cấu trúc Computeur sau khi áp dụng Visitor pattern 60

Hình 47:Sử dụng VisitorPattern trong ứng dụng 60

Hình 48:Cấu trúc của StrategyPattern aspect 61

Hình 49: Cấu trúc các lớp sắp xếp khi chưa áp dụng StrategyPattern 62

Hình 50: Cấu trúc các lớp sắp xếp sau khi áp dụng StrategyPattern 62

Hình 51: Sử dụng Strategy Pattern trong ứng dụng 62

Hình 52: Sử dụng state pattern trong ứng dụng 63

1 Giới thiệu

Việc chuyển đổi các yêu cầu của người dùng vào trong một hệ thống phần mềmbao giờ cũng rất khó khăn, mặc dù hiện nay đã có rất nhiều phương pháp tiếp cận như lậptrình hướng đối tượng, hướng thành phần, các design pattern Chúng cũng đã giải quyếtđược một số vấn đề nhưng vẫn chưa có một phương pháp nào thoả mãn việc giải quyết cácyêu cầu đan xen ở mức hệ thống, các yêu cầu này được mô tả bằng khái niệm

crosscutting concern Các nhà nghiên cứu lý thuyết đã đưa ra mô hình AOP để giảiquyết các vấn đề mà các mô hình lập trình hiện tại chưa đáp ứng được hoặc đáp ứng đượcnhưng việc thực hiện nó quá phức tạp AOP không phát minh và điều gì mới mà chỉ giảiquyết các vấn đề đã tồn tại theo cách tốt hơn (How to do the bad things in better way)

1.1 Mục đích và cấu trúc của tài liệu

Tài liệu này được tổng hợp từ nhiều nguồn khác nhau (xem phần tài liệu thamkhảo), bao gồm các cuốn sách, các bài báo, các luận văn …về vấn đề nghiên cứu và ứngdụng AOP trong ngành công nghệ phần mềm Tài liệu nhằm mục đích tìm hiểu mô hìnhAOP và đi sâu trình bày một trong những kỹ thuật quan trọng của ngành công nghệ phầnmềm hiện nay là design pattern trên mô hình AOP

Trước khi đọc tài liệu này bạn cần có kiến thức cơ bản về kỹ thuật lập trình hướngđối tượng, các mẫu thiết kế, các kiến trúc của phần mềm, … trong ngành công nghệ phầnmềm hiện nay Đồng thời cũng cần kinh nghiệm thực tế về những khó khăn mà cácphương pháp lập trình hiện tại đang gặp

Tài liệu được chia thành 2 phần chính sau

Phần thứ nhất, từ mục 1 đến 5: Trình bày các vấn đề cơ bản về AOP, giới thiệu mộtphiên bản thi công của nó là AspectJ, cú pháp và các khái niệm của AspectJ Ngoài ratrong phần này, tài liệu cũng đề cập đến các ứng dụng thích hợp cho việc áp dụng AOP

Phần thứ 2, từ mục 6 đến hết: Trình bày cách triển khai các mẫu thiết kế (designpattern) đã được sử dụng trong mô hình OOP sang mô hình AOP, cụ thể là triển khai trên

một hệ thống phần mềm.

nghệ phần mềm mà mã nguồn chươngtrình được cấu trúc lại nhằm đảm bảo tínhmềm dẻo, mở rộng chức năng của chươngtrình đồng thời mã chương trình dễ hiểuhơn cho người đọc

mềm Một số middleware tiêu biểu nhưEJB của Sun, Net Framework củaMicrosoft

ứng dụng nhằm đảm bảo chất lượng, tăngtính mềm dẻo, tính trong sáng của mãchương trình Một số pattern hay được sửdụng như IOC (Inversion of Control),Singleton, Proxy, Abstract Factory Class

1.3 Hạn chế của các phương pháp lập trình hiện tại

Có lẽ khái niệm về AOP hiện nay đã được nhiều người biết đến, vì vậy ở đây ta chỉtrình bày lại ngắn gọn các khái niệm cơ bản và các đặc điểm chính của AOP

Để trả lời được câu hỏi AOP là gì? Tại sao phải có AOP? Chúng ta cần bắt đầu tìm hiểu sựhạn chế của của các phương pháp lập trình hiện tại trong việc đáp ứng các yêu cầu ngàycàng phức tạp của các hệ thống phần mềm

Có lẽ các câu hỏi thường gặp nhất trong ngành công nghệ phần mềm hiện naylà:Thiết kế một phần mềm như thế nào được gọi là đủ? Các hệ thống tốt cần xem xét đếnnhững yêu cầu hiện tại và cả những yêu cầu tiềm tàng trong tương lai Sự lơ là các yêu cầutrong tương lai có thể dẫn đến thay đổi nhiều phần của hệ thống hoặc có thể phải xây dựnglại Hay nói một cách khác, các thiết kế có khả năng đáp ứng nhu cầu cho tương lai kém cóthể dẫn đến hiện tượng “tràn thiết kế”, khó hiểu, hệ thống phình ra không mong muốn Từ

đó hình thành một yêu cầu có một thiết kế có thể đáp ứng được các yêu cầu trong tương lai

mà không ảnh hưởng đến chất lượng

Phương pháp lập trình OOP hiện tại đã tạo ra một cuộc cách mạng lớn trong côngnghệ phần mềm, ảnh hưởng đến tất cả các pha từ xác định yêu cầu, phân tích, thiết kế, càiđặt, kiểm thử đến các hệ quản trị cơ sở dữ liệu Tuy nhiên, người ta nhận thấy OOP

modul hoá yêu cầu theo kiểu mô phỏng một đối tượng (object) trong thế giới thực Nhưng

sự mô phỏng này chỉ dừng ở mức tĩnh Các đối tượng trong OOP hoạt động theo qui trình:Sinh-Hoạt động-Tử, nhưng ở thế giới thực, thường thì một object có một chu kỳ sống:Sinh-Hoạt động-Phát triển-Tử Ở đây, 'Phát triển' là điều quan trọng, giải quyết được nótức bạn đã giải quyết được tính tiến hoá, thay đổi yêu cầu của bài toán phần mềm TheoOOP, bạn phải cân nhắc giữa dự đoán trước các yêu cầu phát triển  Phát triển phần mềmnặng nề, hoặc bỏ qua các yêu cầu phát triển tương lai  hệ thống thiếu tính khả mở, tiếnhoá

Nhược điểm trên của OOP là thấy rõ nhất, nhược điểm thứ hai là: Một hệ thốngthực tế là sự đan xen nhau giữa các yêu cầu Lấy ví dụ: Bạn cần xử lý nghiệp vụ truy xuất

dữ liệu Trong bản thiết kế, bạn có thể phân công trách nhiệm này cho một object cụ thểnào đó và vấn đề này rất bình thường Nhưng cùng với yêu cầu nghiệp vụ trên, thường thìcần bổ sung vào các yêu cầu: Chứng thực, Phân quyền, Bảo mật, Lưu vết Như vậy trongmethod TruyXuatDuLieu() của một đối tượng được chỉ định nào đó, bạn phải bổ sung codecho các yêu cầu nêu trên Tình trạng này, người ta gọi là sự chồng chéo giữa các yêu cầu

Nó làm nên một hệ thống lộn xộn, khó bảo trì, phát triển, tính tiến hoá cũng bị ảnh hưởng

Vì khi cần bổ sung thêm một nghiệp vụ nào khác, bạn phải thay đổi tất cả các yêu cầunghiệp vụ liên quan

2 Các đặc điểm của AOP

AOP được xây dựng trên các phương pháp lập trình hiện tại như OOP và lập trình

có cấu trúc , bổ sung các khái niệm và cấu trúc để module hoá các quan hệ đan xen VớiAOP, các quan hệ cơ bản sử dụng các phương pháp cơ bản, nếu sử dụng OOP sẽ thực thicác quan hệ cơ bản dưới hình thức lớp Các aspect trong hệ thống đóng gói các quan hệđan xen lại với nhau Chúng sẽ qui định cách các module khác nhau gắn kết với nhau đểđịnh hình lên hệ thống cuối cùng

Nền tảng cơ bản AOP khác với OOP là cách quản lý các quan hệ đan xen.Việc thựcthi của từng quan hệ của AOP bỏ qua các hành vi được tích hợp vào nó Ví dụ, bussinessmodule sẽ không quan tâm nó cần được log hoặc xác thực như thế nào Kết quả là việcthực thi của từng concern tiến triển một cách độc lập

Concern được chia làm hai loại

1 Concern thành phần: Thể hiện các chức năng nội tại của một module

2 Concern đan xen: Thể hiện các quan hệ ràng buộc giữa các module trong hệ thốngMột ứng dụng doanh nghiệp điển hình có thể bao gồm các concern đan xen sau:authentication, logging, resource pooling, performance, storage management, datapersistence, security, multithread safety, transaction integrity, error checking…

Các concern được phục vụ cho một vài module Ví dụ, logging tác động tới tất cả moduletrong hệ thống, authencication tác động tới module có yêu cầu kiểm soát truy cập

Hình 1: Mô hình các concern mức hệ thống

Việc xác định được các concern trong hệ thống, chúng ta sẽ tập trung vào các concern mộtcách độc lập và sẽ giảm độ phức tạp của hệ thống

Hình 2: Mô hình ánh xạ yêu cầu người dùng sử dụng AOP

Hình 3: Mô hình đa chiều về sự phụ thuộc giữa các module với nhau

Các concern đan xen nhau giữa các module, các kỹ thuật thi công hiện tại sẽ trộnchúng vào một module Hình sau minh hoạ sự thực hiện này: Với mô hình biểu diễn nhiềuchiều của các concern được ánh xạ trên các ngôn ngữ một chiều như sau

Hình 4: Mô hình ánh xạ từ các concern hệ thống sang các phương pháp lập trình truyền thống

Trong thiết kế phần mềm cách tốt nhất để đơn giản các hệ thống phức tạp là xácđịnh các concern rồi module hoá chúng OOP được thiết kế để phục vụ việc module hoácác concern cơ bản, nhưng khi gặp concern mức hệ thống thì OOP không đáp ứng đượcyêu cầu Hình sau minh hoạ một ví dụ thiết kế dùng phương pháp truyền thống Ngay cảkhi bạn có một bản thiết kế tốt của logging module như: cung cấp các API trừu tượng(Abstract API), giấu cách định dạng log message…Các module còn lại vẫn cần phải nhúngcác đoạn mã để gọi các logging API

Hình 5: Các module yêu cầu logging đều phải nhúng các đoạn mã để gọi logging API

Đây chính là vấn đề sẽ được giải quyết bằng AOP, sử dụng AOP các module kháckhông cần chứa đoạn mã gọi logging API Hình 7 chỉ ra cách thực hiện module logging

dùng AOP có cùng chức năng với cách sử dụng OOP, như đã được chỉ ra trên hình vẽ,cách thực hiện log bây giờ chỉ tồn tại trong logging module và logging aspect Cácmodulek khác không chứa bất kỳ đoạn mã nào gọi đến logging API Như vậy các yêu cầuđan xen giữa logging module và các module khác được thực hiện duy nhất trong mộtmodule hay logging aspect Với phương pháp module hoá này bất cứ sự thay đổi yêu cầunào về logging chỉ ảnh hưởng duy nhất đến logging aspect.

Hình 6: Giải quyết các concern hệ thống bằng phương pháp AOP

2.2 Phương pháp luận của AOP

Việc phát triển các hệ thống sử dụng AOP tương tự như phát triển các hệ thống sửdụng các phương thức khác: xác đinh concern, thực hiện chúng, kết hợp lại để thành hệthống cuối cùng Tuy nhiên cộng đồng nghiên cứu AOP đề xuất ba bước thực hiện sau:

1 Aspectual decomposition: Trong bước này chúng ta phân tách các yêu cầu nhằmxác định các concern lõi và concern đan xen Các concern lõi được tách ra khỏi cácconcern đan xen

2 Concern Implementation: Thực thi các concern một cách độc lập

3 Aspectual Recomposotion: Trong bước này chúng ta chỉ ra các quy lật kết hợpbằng cách tạp ra các aspect Quá trình này còn được gọi là quá trình dệt mã, sửdụng các thông tin trong aspect để cấu thành hệ thống đích

Hình 7: Các giai đoạn phát triển sử dụng phương pháp AOP

2.2.1 Ưu điểm của AOP

Khi sử dụng AOP để giải quyết các bài toán chúng ta cần suy nghĩ về thiết kế và thi công

hệ thống theo một phương thức mới, với AOP ta sẽ có các ưu điểm sau

1 Tách biệt chức năng hơn của các module độc lập

2 Tính module hoá cao hơn

3 Phát triển hệ thống dễ dàng hơn

4 Kết nối muộn thiết kế

5 Tăng khả năng sử dụng lại mã

6 Giảm thời gian thi công hệ thống

7 Giảm giá thành của sản phẩm

2 AOP không là cứu cánh cho các thiết kế cẩu thả

3 AOP phá vỡ tính đóng gói (encapsulation)

2.3 Một số công cụ hỗ trợ làm việc với AOP

AOP hiện nay đã được nghiên cứu và áp dụng vào hầu hết các ngôn ngữ như Java, C, C#,Python, PHP

4 Sping AOP www.spring framework.org

AspectJ là sự mở rộng theo mô hình AOP của ngôn ngữ Java, với sự mở rộng này

mã chương trình viết bằng Java sẽ tương thích với chương trình viết bằng AspectJ

AspectJ bao gồm hai phần: đặc tả ngôn ngữ và phần thực thi Phần đặc tả ngôn ngữ sẽ chỉ

ra cách viết code, với AspectJ các concern cơ bản được viết bằng Java, các concern hệthống được thực hiện bởi AspectJ AspectJ đã được plugin vào công cụ phát triển Eclipse(eclipse.org) và được đánh giá là sản phẩm tốt nhất hiện nay về AOP

2 concern đan xen động (dynamic crosscutting): là sự gắn kết các hành vi mới vàochương trình, hầu hết các concern đan xen trong AspectJ là concern đan xen động AspectJ sử dụng dự mở rộng của Java để chỉ ra các luật gắn kết cho concern tĩnh vàconcern động

3.2.1 Join point

Join point là một khái niệm cở bản của AspectJ, Join point có thể là bất kỳ điểmnào có thể xác định được khi thực hiện chương trình Có thể là lời gọi đến một phươngthức hoặc một lệnh gán cho một biến của đối tượng Trong AspectJ mọi thứ đều xoayquanh join point

public class Account {

void credit(float amount) {

balance + = amount;

}

Join point được phân loại như sau

• join point tại các phương thức

• join point tại hàm dựng (contructor)

• join point tại điểm truy cập các thuộc tính

• join point tại điểm điều khiển ngoại lệ: Được biểu diễn trong khối điều khiển ngoạilệ

• join point tại các advice:

public aspect MannersAspect {

Cú pháp của pointcut được khai báo như sau:

[access specifier] pointcut pointcut-name([args]) : pointcut-definition

Ví dụ:

execution(void Account.creadit(float))

Bảng ánh xạ giữa các join point được chọn cho các point cut

Ghi thu c tính set(FieldSignature)

Thực hiện điều khiển

Advice được chia thành 3 loại sau

1 before: Được thực hiện trước join point

2 after: Được thực hiện sau join point

3 around: Bao quanh sự thực hiện join point, advice này có thể thực hiện vòng, thựchiện tiếp của mã nguồn ban đầu hoặc thực hiện thay đổi ngữ cảnh (tham số củahàm, …)

Giả sử ta có pointcut được khai báo như sau

pointcut connectionOperation(Connection connection)

: call(* Connection.*( ) throws SQLException)&& target(connection);

Ta có thể xây dựng các advice như sau:

before(Connection connection):connectionOperation (connection) {

System.out.println("Performing operation on " + connection);

}

Object around(Connection connection) throws SQLException

: connectionOperation (connection) {

System.out.println("Operation " + thisJoinPoint

+ " on " + connection+ " started at " + System.currentTimeMillis());

Introduction là một lệnh chỉ ra sự thay đổi đến một class, interface, aspect Nó tạo

ra sự thay đổi tĩnh đến các module mà không trực tiếp ảnh hưởng đến các hành vi củamodule đó Ví dụ có thể thêm một phương thức hoặc một trường vào lớp nào đó hoặc sửađổi cấu trúc thừa kế của một đối tượng

Ví dụ khai báo sau sẽ sửa đổi cấu trúc thừa kế của đối tượng Account

declare parents: Account implements BankingEntity;

Introduction là khái niệm sinh ra để can thiệp vào các cấu trúc tĩnh, trong AOP nó đượcdùng để xử lý các quan hệ đan xen tĩnh (static crosscutting) Chúng ta sẽ đề cập đến vấn đềnày trong phần static crosscutting

3.2.5 Aspect

Aspect là phần tử tập trung của AspectJ, giống như class trong Java Aspect chứa

mã thể hiện các luật đan kết cho concern Join point, pointcut, advice, introduction đượckết hợp trong aspect

Aspect được khai báo theo mẫu sau

[access specification] aspect <AspectName>

public aspect ExampleAspect {

before() : execution(void Account.credit(float)) {

System.out.println("About to perform credit operation");

}

declare parents: Account implements BankingEntity;

declare warning : call(void Persistence.save(Object))

: "Consider using Persistence.saveOptimized()";

}

Một số tính chất của khái niệm aspect tương tự khái niệm class

• Aspect có thể chứa các thuộc tính và phương thức

• Aspect chứa các thuộc tính truy cập: private, public, protected

• Aspect có thể khai báo như một aspect trừu tượng:

public abstract aspect AbstractLogging {

public abstract pointcut logPoints();

public abstract Logger getLogger();

before() : logPoints() {

getLogger().log(Level.INFO, "Before: " + thisJoinPoint);

}

}

• Aspect có thể thừa kế class, abstract aspect và thi công các interface

public aspect BankLogging extends AbstractLogging {

public pointcut logPoints()

• Aspect có thể nhúng trong class và interface như một aspect nằm trong

Ngoài các tính chất tương tự class như trên, aspect cũng có một số đặc điểm khác so vớiclass như sau:

• Aspect không thể khởi tạo trực tiếp

• Aspect không thể thừa kế từ một aspect khác (không phải trừu tượng)

• Aspect có thể được đánh dấu như quyền

3.2.6 Static crosscutting

Trong AOP chúng ta thường xuyên can thiệp vào các quan hệ đan xen động sửdụng advice, và cũng cần thiết các hành động can thiệp vào các cấu trúc tĩnh Trong khi cácconcern đan xen động sẽ sửa đổi sự thực hiện các thủ tục của chương trình thì sự đan xentĩnh sẽ sửa đổi các cấu trúc như class, interface, các aspect khác và các hành vi tại điểmdịch chương trình

3.2.6.1 Giới thiệu thành viên

Aspect thường xuyên giới thiệu các thành viên hoặc các phương thức vào trongmột lớp aspect AspectJ cung cấp một có chế được gọi là introduction để giới thiệu cácthành viên vào trong các class hoặc interface Đoạn mã dưới đây mô tả cách giới thiệu 2thành viên là thuộc tính minimumBalance và phương thức getAvailable() vào lớp Account.Các thành viên được giới thiệu vào một lớp cũng có thể được chỉ ra quyền truy nhập nhưkhai báo các thành viên của một lớp Ví dụ từ khoá private chỉ ra thành viên chỉ được truycập từ aspect giới thiệu nó

public aspect MinimumBalanceRuleAspect {

private float Account._minimumBalance;

public float Account.getAvailableBalance() {

return getBalance() - _minimumBalance;

throw new InsufficientBalanceException(

"Insufficient available balance");

} }

3.2.6.2 Sửa đổi cấu trúc thừa kế

Khi thực thi các quan hệ đan xen thường xuyên cần tác động đến tập các class hoặcinterface mà chúng có chung một kiểu cơ sở AspectJ có thể sửa đổi cây thừa kế của một

lớp đã tồn tại để khai báo các lớp cha hoặc các interface của lớp đó miễn là không ảnhhưởng đến qui luật thừa kế của Java.

Mẫu khai báo như sau:

declare parents : [ChildTypePattern] implements [InterfaceList];

declare parents : [ChildTypePattern] extends [Class or InterfaceList];

Ví dụ : Aspect khai báo tất cả các class và interface trong gói entities thực thi Identifiableinterface

aspect AccountTrackingAspect {

declare parents : banking entities.* implements Identifiable;

tracking advices

}

3.3 Một số ứng dựng cơ bản của AOP

Dưới đây là một số ứng dụng điển hình sử dụng các ưu điểm của AOP trong việc thiết kế

và triển khai

1 Các kỹ thuật điều khiển, giám sát (monitor): Các kỹ thuật điều khiển, giám sát nhưlogging, tracing, profiling là những kỹ thuật chung để hiểu được các hành vi xảy ratrong hệ thống Ví dụ trong hệ thống nhà băng người quản trị muốn theo dõi thôngtin mỗi giao dịch trong hệ thống như tên tài khoản, thời gian giao dịch Vì các chứcnăng này xuyên suốt qua các module của ứng dụng nên khi triển khai các kỹ thuậtnày với AOP là một cách tiếp cận tốt nhất có thể

2 Tăng cường chính sách (policy enforcement): Là một cơ chế bảo đảm các thànhphần trong hệ thống phải theo các quy tắc lập trình thực tế, tuân theo một số luật cụthể Ví dụ bạn không thể gọi đến thư viên xử lý giao diện AWT trong mã của EJBđược

3 Tối ưu hóa (resource pooling và caching): Khái niệm resource pooling và cachingchúng ta thường xuyên phải sử dụng trong các tình huống muốn tối ưu hóa ứngdụng

4 Giải quyết bài toán với AOP

Trong phần này chúng ta sẽ xem xét một số bài toán và một số giải pháp thực tiễn

để giúp một ứng dụng triển khai được trên AOP Việc áp dụng một công nghệ mới để giải

quyết bài toán không bao giờ dễ dàng, đặc biệt khi bạn còn chưa nhìn thấy một hệ thốngnào triển khai thành công với công nghệ mới này Chúng ta sẽ tìm hiểu cách sử dụng môhình hướng aspect như thế nào để giải quyết bài toán và các giải pháp về thiết kế.

Một khi thực sự chắc chắn muốn sử dụng AOP trong hệ thống phần mềm nào đó, tacần xác định tính thích hợp cho mỗi vấn đề khác nhau Cần phải xem xét khả năng tối thiểucác rủi ro của hệ thống Chẳng hạn chúng ta có thể áp dụng AOP cho các module con, saukhi chứng minh được khả năng của AOP, chúng ta sẽ tiếp tục triển khai trên các moduletiếp theo

Mỗi pha trong quá trình phát triển phần mềm: thiết kế, thi công, test và bảo trì đều nhấnmạnh tới một số hành động

4.1 Sử dụng AOP trong bước thiết kế

Nếu sử dụng AOP trong bước thiết kế chúng ta sẽ có được nhiều sự thuận lợi màAOP đem lại Từ quan điểm về kiến trúc, sự thuận lợi chính là giúp chúng ta vượt qua sự

bế tắc của các kiến trúc hiện tại

Sau đây là một số bước điển hình sử dụng AOP trong pha thiết kế

1 Nhận biết các concern đan xen: Bước này là một phần trong việc ánh xạ các yêucầu người dùng tới các module Một quy tắc là xem xét các concern được mô tả vớicác tính tù hoặc trạng từ bắt đầu với từ “mọi”, ví dụ như mọi ngày, mọi nơi…Nhậnbiết các concern này ban đầu sẽ giúp chúng ta tránh khỏi việc module hoá cácconcern đan xen theo phương pháp truyền thống

2 Thiết kế các concern lõi trước: Áp dụng các quy tắc và phương pháp truyền thống

để thiết kế các concern lõi Công việc này càng làm tốt thì việc áp dụng các concernđan xen sau này càng dễ

3 Thiết kế các concern đan xen: Xác định các concern đan xen cần thiết, dễ thấy Lênmột bộ khung cho các concern bạn cần và cũng có thể cả các concern bạn chưa cầnngay lập tức

4.2 Sử dụng AOP trong bước thi công

Khi sử dụng AOP trong bước thi công bạn nên nhấn mạnh vào trên một vài thựctiễn có tính chất chung Cũng như cần theo một số chỉ dẫn để việc thi công các concern lõi

và concern đan xen dẽ nhất có thể Cũng có một số phương pháp refactoring theo mô hìnhAOP bạn có thể sử dụng

1 Thực thi các concern lõi

a Viết các concern lõi theo mô hình refactoring tốt nhất.

b Sử dụng cách đặt tên nhất quán xuyên suốt ứng dụng

c Tách biệt các concern đan xen từ các module trong bước đầu tiên

d Xem xét bất kỳ sự rải rác và chồng chéo mã chương trình

2 Thực thi các concern đan xen

a Xác định các join point: Bước này cần xác định các vị trí trong mã chươngtrình cần cho các quan hệ đan xen Tiếp theo cần quyết định cách tốt nhất

để thể hiện các pointcut mà chúng sẽ chọn các join point

b Lựa chọn các kỹ thuật sử dụng ở lớp dưới

c Thiết kế các aspect

3 Thực hiện refactoring các aspect

4.3 Sử dụng AOP trong bước kiếm tra

AspectJ có thể trợ giúp nhiều nhiệm vụ trong bước kiếm tra, Sau đây là một kịchbản điển hình mà chúng ta có thể bắt đầu thực hiện với AspectJ

1 Tạo các test case: Do AspectJ có khả năng sửa đổi các hành vi mà không cần sựthay đổi thực sự nên AspectJ có thể trợ giúp để viết các chương trình kiểm tra

2 Thực hiện kiểm tra hiệu năng hệ thống: Rất nhiều vấn đề chỉ được phát hiện ra vàothời điểm triển khai hệ thống.AspectJ có thể bất chế độ theo dõi hiệu năng cácaspect, do đó chúng ta có thể xác định được kết quả gần với các hệ thống thực, vàchúng ta có thể quyết định sử dụng aspect hay không trên hệ thống triển khai đểtránh tràn bộ nhớ

3 Báo cáo lỗi: Trong quá trình kiểm tra, khi chúng ta phát hiện ra các lỗi thì có thể sửdụng aspect để chỉ ra các ngữ cảnh trong ứng dụng chứ không phải chỉ là ngăn xếpcủa ngoại lệ được ném ra

4.4 Sử dụng AOP trong giai đoạn bảo trì

Giai đoạn bảo trì hệ thống bao gồm hai thao tác chính sau

• Thêm mới tính năng cho các yêu cầu mới

• Sửa các lỗi được tìm thấy

AspectJ có thể điều khiển 2 bước sau trong giai đoạn bảo trì

• Tạo một bức tường an toàn: Thêm các tính năng mới mà không làm đổ vỡ hệthống, Các chế độ tăng cường của aspect bảo đảm rằng các tính năng mới khôngảnh hưởng đến hệ thống cũng như tạo ra các lỗi mới

• Thực thi các tính năng mới: AspectJ có thể thêm các quan hệ đan xen mới màkhông thay đổi trực tiếp trên mã nguồn gốc

5 Triển khai một số pattern trên AspectJ

Mẫu thiết kế (design pattern) được sử dụng rất nhiều khi phát triển một phần mềm,

nó giúp người phát triển giải quyết các vấn đề như điều khiển đối tượng, tái sử dụng mã,tăng hiệu năng chương trình

“Design Patterns: Elements of Reusable Object-Oriented Software” được biên soạnbởi Erich Gamma, Richard Helm, Ralph Johnson, và John Vlissides là một cuốn sách vềdesign pattern đã được công nhận chính thức như một tài liệu thực tiễn cho mô hình lậptrình hướng đối tượng (OOP) Các mẫu thiết kế trong quyển sách này được chia thành 3loại, bao gồm: các mẫu thiết kế về cấu trúc đối tượng, hành vi đối tượng, và tạo lập đốitượng Các mẫu thiết kế được thực thi dựa trên cơ chế của các ngôn ngữ lập trình hướngđối tượng đang có Với mô hình lập trình hướng aspect, các mẫu thiết kế được xây dựngvới một số đặc điểm mới nhằm tận dụng được những ưu điểm của phương pháp mới này

5.1 Các mẫu thiết kế cho việc tạo đối tượng

5.1.1 Singleton pattern

5.1.1.1 Giới thiệu

Singleton pattern là một mẫu thiết kế để đảm bảo trong một phiên làm việc của ứngdụng chỉ có duy nhất một thể hiện ( instance) của đối tượng vào lúc chạy Mẫu thiết kế nàythường được sử dụng để quản lý thông tin của một phiên làm việc của một ứng dụng

Đối tượng không được khởi tạo trực tiếp trong chương trình (các hàm khởi tạo củađối tượng được khai báo với từ khoá private) mà sẽ truy xuất qua một hàm static để trả vềthể hiện duy nhất của đối tượng

public abstract aspect SingletonPattern issingleton( )

{

private Hashtable singletons = new Hashtable( );

public interface Singleton

// of all Classes that extend Singleton

pointcut selectSingletons( ) : call((Singleton +).new ( ));

// Pointcut bảo đảm bất kỳ lớp nào trong cây thừa kế được đánh dấu //là Non Singletons thì không được gộp trong logic của Singleton pointcut excludeNonSingletons( ) : !call((NonSingleton +).new ( ));

Object around() : selectSingletons() && excludeNonSingletons( ) {

Class singleton = thisJoinPoint.getSignature().getDeclaringType( );

synchronized(singletons) {

if (singletons.get(singleton) == null) {

singletons.put(singleton, proceed( ));

} } return (Object) singletons.get(singleton);

}

}

Aspect trừu tượng Singleton định nghĩa 2 vai trò: Singleton và NonSingleton Cácvai trò này được thi công bởi interface nên các aspect trừu tượng có thể làm việc vớisingleton mà không cần lo lắng về cách thi công chi tiết

Hình 8: Cấu trúc của aspect trừu tượng với interface và các hàm được định nghĩa để hỗ trợ Singleton

pattern

5.1.1.2 Sử dụng

Sau đây là ví dụ chỉ ra aspect SingletonPattern được sử dụng trong ứng dụng:

Hình 9:Một ứng dụng trước và sau khi được tác động bởi Singleton pattern

public aspect PrinterSingleton extends SingletonPattern

{

declare parents: Printer implements Singleton;

declare parents: SpecializedPrinter implements NonSingleton;

}

Hình sau minh hoạ hoạt động của ứng dụng khi gọi hàm in 2 lần, lần đầu khiinstance của Printer chưa có, nó sẽ được khởi tạo lần đầu Lần tiếp theo khi instance đã tồntại, hàm in sẽ lấy tham chiếu đến instance đã được khởi tạo ở bước đầu tiên

Hình 10: Các bước thực hiện của mẫu thiết kế Singleton trong ứng dụng

5.1.2 Prototype pattern

5.1.2.1 Giới thiệu

Prototype pattern được sử dụng hỗ trợ sao chép một đối tượng dựa trên đối tượng gốc

public abstract aspect PrototypePattern

Hình 11: Cấu trúc của PrototypePattern aspect

5.1.2.2 Sử dụng

public aspect GraphicPrototypes extends PrototypePattern

{

declare parents : Graphic implements Prototype;

declare parents : MusicalNote implements Prototype;

declare parents : Staff implements Prototype;

protected Object createCloneFor(Prototype object)

return new Staff(((Staff) object).getX(), ((Staff) object).getY( ));

} else {

return null;

} }

}

Hình 12:Một ứng dụng trước và sau khi được tác động bởi Prototype pattern

Hình 13: Sử dụng Prototype pattern trong ứng dụng

5.1.3 Abstract Factory pattern

Mẫu thiết kế này được sử dụng khi thao tác trên nhóm các lớp có quan hệ với nhautrong khi nó che giấu sự thực thi các lớp này đối với client Theo mô hình lập trình OOPthì factory pattern cung cấp các lợi ích sau:

1 Client không cần phải quan tâm đến việc chọn một concrete class để tạo object màmình muốn

2 Client không cần phải liên hệ trực tiếp với lớp thực thi cụ thể (concrete class) màthông qua interface hoặc abstract class

3 Client không cần phải biết quá trình tạo object như thế nào

Mô hình của pattern được mô tả trong hình sau

Hình 14: Lược đồ UML của AbstractFactory Pattern

Tạo một factory sử dụng aspect không mang ý nghĩa lắm bởi vì factory chứa cácphương thức cụ thể đến các đối tượng có thể được tạo Ưu điểm duy nhất của AOP đối vớipattern này là khả năng loại bỏ sự nương tựa vào một lớp abstract cơ sở cho các abstractfactory và thay thế chúng với một interface đơn giản Điều này có nghĩa là các factory cụthể có thể thừa kế từ lớp thích hợp khác hơn là sử dụng một quan hệ thừa kế được phép để

hỗ trợ mẫu thiết kế

Đoạn mã AspectJ sau đây chỉ ra cách thực hiện pattern này

public interface ComputerFactory

{

public Computer createPentiumProcessorComputer( );

public Computer createComputerWithHardDisk(HardDisk hardDisk); }

public aspect DefaultComputerFactoryImplementation

{

public Computer ComputerFactory.createPentiumProcessorComputer( )

{

Processor processor = new Processor("Pentium 4 : 9089085043"); Motherboard motherboard = new Motherboard("019283", processor); HardDisk hardDisk = new HardDisk("738947");

FloppyDisk floppyDisk = new FloppyDisk("93746");

Computer computer = new Computer("12345", motherboard, hardDisk, floppyDisk);

Computer computer = new Computer("56789", motherboard, hardDisk, floppyDisk);

return computer;

}

}

5.1.4 Factory Method pattern

Factory method pattern tương tự abstract factory khi nó cung cấp cơ chế mà sự thicông cụ thể của các đối tượng được tách riêng từ các client của factory Một phương thứctrừu tượng (Factory method ) cung cấp một phương thức để khởi tạo các instance khácnhau của một interface

Hình 15: Lược đồ UML của factory method pattern

Đoạn mã AspectJ sau mô tả cách thực hiện pattern này:

public interface ComputerCreator

{

public Computer createComputer(String serial);

5.1.5 Builder pattern

5.1.5.1 Giới thiệu

Builder pattern được sử dụng để tạo một đối tượng cần đến một tập các bước thựchiện phức tạp Các bước này được thi công như những phương thức của lớp builder, saukhi hoàn tất mỗi bước builder có thể được gọi để tạo đối tượng

Builder pattern có các lợi ích sau:

1 Tách quá trình tạo một object ra bên ngoài bản thân class của object đó

2 Tạo khả năng mềm dẻo trong việc đưa ra các implementation khác nhau cho qúatrình tạo object

Để thực hiện Builder pattern trong AspectJ, cần tạo một aspect mà nó thêm vào lớpcao nhất của lớp builder

Ví dụ:

public interface TextPhraseBuilder

{

public void buildHeader(String title);

public void buildBody(String content);

public void buildFooter(String closingContent);

public String getResult( );

}

public aspect TextPhraseBuilderDefaultImplementation

{

public StringBuffer TextPhraseBuilder.result = new StringBuffer( );

public String TextPhraseBuilder.getResult( )

{

return result.toString( );

}

/**

* Declares a compiler error that gets reported if other classes

* (except Builders or this aspect) try to access the result variable.

*/

declare error : (

set(public StringBuffer TextPhraseBuilder +.result)

|| get(public StringBuffer TextPhraseBuilder +.result))

5.2 Các mẫu thiết kế cho cấu trúc của đối tượng

5.2.1 Composite pattern

Composite pattern cung cấp khả năng nhóm các đối tượng cùng nhau trong một tậphợp và tương tác với nhóm tương tự như cách thao tác với một đối tượng thành viên độclập của nhóm

Composite pattern aspect định nghĩa giao diện Composite và Leaf để áp dụng vàocác ứng dụng cần sử dụng vai trò của 2 giao diện này Aspect sử dụng Visitor pattern đểduyệt đệ quy và làm việc với các thành phần của composite

Hình 16: Cấu trúc của CompositePattern aspect

public abstract aspect CompositePattern

private WeakHashMap perComponentChildren = new WeakHashMap( );

private Vector getChildren(Component s)